For full context, see the original proposal. This version reflects my understanding after stress-testing each concept.
What We’re Building
A MEV-resistant DEX on CKB using batch auctions. Not fighting the UTXO model - leveraging it.
The Core Insight
Traditional DEXs on UTXO fail because every trade competes for the same pool cell. N traders = N-1 failed transactions.
VibeSwap flips this: users create independent commitment cells (no shared dependencies), then one settlement transaction updates the pool once. N trades = 1 pool update. The “limitation” of UTXO becomes irrelevant.
Architecture
L1 (CKB): The referee - checks the rules. Passive verification.
L2 (Coordinator): The player - does the work. Monitors, collects, computes, builds, submits.
L1 can verify a clearing price is correct. It can’t find it. That’s why L2 exists.
How MEV Dies
Commit phase: Orders hidden as hash(order || secret). Can’t frontrun what you can’t see.
Reveal phase: Orders visible, but commit window closed. Can’t add new orders.
Settlement: Everyone gets the same clearing price. No ordering advantage.
Intent hidden + ordering nullified = no MEV.
Timing Without “Current Block”
CKB doesn’t have a current block concept - only provable recent blocks via header_deps.
Solution: Each commitment cell carries its own batch_start_block. Verification computes elapsed time from a reference block. Objective timing, fuzzy by a few blocks. Design windows with tolerance.
No global phase-tracker cell. Every transaction verifies timing independently, in parallel. Scales without bottleneck.
Intuition: Every order carries its own timestamp. To check timing, you do local math against a recent block - no shared clock to crowd around. That’s why it scales: everyone’s independent, no one waits in line.
Fair Shuffle via XOR
All secrets XORed together = shuffle seed.
No single party can control the outcome - you’d need to know everyone else’s secret before committing yours, which is impossible. Interdependent secrecy.
Why this matters: If we used one user’s secret, they could grind it for favorable ordering. If we let the coordinator pick, they could manipulate it. XOR means everyone contributes, no one controls. Fair randomness without
a trusted party.
Settlement Guarantees
One atomic transaction: all commitment cells + pool cell in, all user balances + new pool cell out.
Atomic = all or nothing. 50 users either all get their trade or none do. No partial outcomes.
Why this matters: Fairness isn’t just about price - it’s about certainty. Users are never left in limbo. You either get your trade at the fair clearing price, or you keep your committed funds. No scenario where half the
batch executes and half gets stuck. The same philosophy that eliminates MEV also eliminates uncertainty.
CKB Script Responsibilities
Lock Script (Bouncer): Who gets in? Valid reveal? Valid reclaim? Owner authorized?
Type Script (Referee): Playing fair? Commitment format correct? Clearing price valid? Pool math correct?
Authorization vs validation.
What We Need From Nervos
Not funding. Collaboration.
- Technical review of this architecture
- Introductions to RGB++ teams
- Guidance on CKB-VM cycle optimization
- Partners who believe MEV-resistant infrastructure should be a public good
All code will be open source.
Status
I’ve stress-tested my understanding of these concepts with Claude. The table in my previous post shows both my intuitive framings and the technical translations. Happy to go deep on any of them.
Looking forward to building.