Ohrex Protocol: Decentralized Token Launchpad with Auto-DEX Deployment on CKB

English
,
1

:waving_hand: Hello Nervos community,

I’m excited to share Ohrex Protocol — a decentralized token launchpad built natively on Nervos CKB that automates the entire token launch flow: from bonding curve fundraising → automatic DEX deployment → live AMM trading.

:test_tube: Status: Core contracts + SDK complete on devnet | UI development in progress

:bullseye: The Problem We’re Solving

Launching a token on-chain today still requires multiple manual steps: deploy token → seed liquidity → create pool → list on DEX. This creates friction for creators and risks for early contributors.

Ohrex automates this end-to-end:

  1. Creator configures a token sale with bonding curve parameters (soft cap, hard cap, duration)

  2. Contributors deposit CKB; price adjusts dynamically via curve

  3. :white_check_mark: If soft cap reached → DEX instance + AMM pool auto-deploy + LP tokens distributed

  4. :cross_mark: If curve expires unfilled → contributors claim refunds via Merkle proofs

:wrench: Technical Highlights

  • On-chain: 5 RISC-V contracts in Rust (Factory, DEX, Pool, Registry, Launchpad) with byte-level SDK compatibility

  • Off-chain: JavaScript SDK for tx building, fee estimation, Merkle proofs, and RBF retry logic

  • Design principle: Every SDK-encoded struct is directly decodable by on-chain contracts — trustless validation by design

:light_bulb: Why This Matters for CKB

For Creators For Contributors For Ecosystem
Launch without upfront liquidity Enter at curve price + earn LP fees More on-chain activity = stronger CKB demand
No manual pool setup needed Full refund protection if launch fails Native CKB capacity usage + tx fees
Instant DEX listing on success Transparent, on-chain price discovery Composable infrastructure for future DeFi

:construction: Current Status & What’s Next

  • :white_check_mark: Core contracts audited internally + tested on CKB devnet

  • :white_check_mark: SDK with full tx-building + Merkle proof support

  • :white_check_mark: Automation CLI for end-to-end protocol flows

  • :construction: UI/UX layer currently in development (Vite + Typescript + offckb integration)

  • :construction: Planning testnet deployment + community testing phase

:folded_hands: We’d Love Your Feedback

Before we move forward, we’re seeking honest input from the Nervos community:

  1. Does this solve a real pain point you’ve experienced when launching or participating in token projects on CKB?

  2. Any concerns about the bonding curve + auto-deploy model? (Security, UX, economic design?)

  3. What features would make you more likely to use or build on Ohrex?

  4. Suggestions for testnet testing strategy or community onboarding?

No question is too small — we’re building this with the community, not just for it.

You can find the code at GitHub: Radiiplus/ohrex

Looking forward to your thoughts! :raising_hands:

2 Likes
2

Hi there, thanks for sharing the Ohrex Protocol overview!

Just a quick note: this post is tagged with Spark-Program, which is the tag we use for grant applications to the Spark Program. If you’re intending to apply for a Spark grant, you’d want to check our guidelines post and make sure your submission includes the required proposal elements (budget breakdown, timeline, to-do list, etc.), and rename the title to the format Spark Program | Ohrex Protocol. If this post is meant as a general project introduction rather than a Spark application, it might be worth removing the Spark-Program tag to avoid confusion.

Either way, welcome to the forum!

你好，感谢分享 Ohrex Protocol 的介绍！

提醒一下：这个帖子带了 Spark-Program 标签，这是我们用于 Spark Program 正式资助申请的标签。如果你打算申请 Spark 资助，请参考我们的规则帖，确保提交内容包含所需的提案要素（预算明细、时间线、to-do list 等），并将标题改为 Spark Program | Ohrex Protocol 的格式。如果这个帖子只是项目的一般性介绍而非 Spark 申请，建议去掉 Spark-Program 标签以免混淆。

欢迎来到论坛！

3 Likes
3

@zz_tovarishch Thanks so much for the heads-up — and my apologies for the tag mix-up! :folded_hands:
You’re absolutely right: this post is intended as a general project introduction to gather early feedback from the community, not a formal Spark Program submission. I do plan to apply to Spark down the line (once the UI is complete and we’re ready for testnet), but I’ll make sure to follow the official guidelines and formatting when that time comes.
I’ve removed the Spark-Program tag from this post to avoid any confusion.
In the meantime, I’d still love to hear thoughts from the community on the core concept, architecture, or UX flow — any feedback is super valuable as we wrap up the frontend. :blush:
Thanks again for the warm welcome!

3 Likes