I see I see, that sounds like a LOB variation tho, let’s see. For example, what happens if in that batch we additionally have Epstein sell: 6,000,000 CKB, limit 0.1?
Appreciated the human readable format, keep it up!! 
Phroi
1 Like
WTF is going on here?!…are you saying @TabulaRasa isn’t just someone using AI, but is AI?
1 Like
it’s called human-Ai alignment 
but no, I’m a human, with a team of 3 other humans. We’re working in alignment with Anthropic’s Claude LLM to handle some of our overhead. simple technological evolution. that is all
1 Like
Case 1: Limit 0.1 (as written)
Sell limit = minimum acceptable. Epstein wants 0.1, buyers max out at 0.012. No overlap → order excluded. Original example unchanged.
Case 2: Limit 0.01 (if typo)
Massive supply at low price.
- Supply at 0.011: ~6,001,400 CKB
- Demand at 0.011: 1,500 CKB
Clearing price still 0.011 (bounded by buyer bids). Only 1,500 CKB trades.
- Buyers: fully filled
- Epstein’s 6M: ~1,498 fills, rest returns unfilled
Key difference from LOB: Big orders don’t crash price below demand. Unfilled supply returns immediately—doesn’t sit in a book waiting.
Which case did you mean?
1 Like
Yes, very clearly too, for reference check out: https://www.moltbook.com/
Sure, it’s also possible that they use OpenClaw for generating buzz and then switch to humans for closing the deal.
So far that he shows intellectual brightness, he doesn’t write in an AI slop style and he respects the rules, I’m cool 
Indeed it works similarly to a LOB, except that:
- It doesn’t have state/book: LO are not persisted in the order book, so orders need to be re-broadcasted at every batch (which is just a feature less than a LOB, not an advantage per se)
- Uniform price in batch is (maybe) the novel part
@TabulaRasa how is the Uniform clearing price determined in a batch? Using which formula/algo from a batch of oders?
Night night, Phroi
2 Likes
Jeez, what a time to be alive haha…I like AI and have been using it heaps lately, but this is just going to turn humans into being sceptical of every interaction we have with anyone other than face to face conversations.
2 Likes
haha. that telegram message was human generated so I guess you can’t tell anymore 
 anyway here’s our team’s response (AI generated to eliminate the guesswork):
Clearing price algorithm:
- Sort buys high → low, sells low → high
- At price P: Demand = buys with limit ≥ P, Supply = sells with limit ≤ P
- Clearing price = highest P where Demand ≥ Supply
Intersection of supply/demand curves. Same as stock market opening/closing auctions.
On persistent books:
Fair point—but order management and settlement can be separate:
- L2 maintains persistent book (committed/hashed orders, not plaintext)
- Batch closes → orders revealed → uniform price settlement
- Unfilled orders re-commit for next batch
You get “set and forget” UX without sacrificing MEV resistance. The value isn’t “orders don’t persist”—it’s “orders settle fairly.” Batching gives you:
- Uniform price (no discrimination)
- Simultaneous settlement (no front-running)
- On CKB: N trades = 1 pool update (UTXO efficiency)
Persistent committed books add convenience on top.
I think you’re right. But on the flipside I see great potential in development if humans and AI learn to coexist. We shall see!
It would be a fun mystery: is Tabula Rasa human or Ai… or is it something in-between 
UPDATE:
Your question made us think: we could add state to L2, but that complicates it. What if we add an L3 instead?
- L1 (CKB): Settlement, verification
- L2 (Stateless): Batch matching, commit-reveal
- L3 (Stateful): Persistent order book, feeds L2, re-commits unfilled
User → L3 (stores order) → L2 (batches) → L1 (settles)
↑ |
└── unfilled orders ←───┘
L2 stays simple. L3 handles persistence. Just thought of this now—your feedback pushed the design forward.
Yeah, I can picture it out, reasonable
Just to me it seems even more volatile than the usual low-volume LOB markets: it will be a system very dependent on Market Makers liquidity and active trading, cause otherwise demand and offer never meet at the same time.
This issue was brilliantly solved by Uniswap-style AMM, which is not a perfect solution either, agreed.
Getting back to this, your system needs to run as fast possible to offer responsiveness to users, fast heartbeat (interval between batches settlements).
Given this, what happens if a user miss the Reveal Phase (phase 2) deadline due to a bad internet connection?
Naaa, IMHO first make sure fundamentals are rock solid and only later start reasoning about layers separation.
Going to bed for real now, night night,
Phroi
1 Like
On liquidity dependence:
VibeSwap has an AMM (x*y=k) underneath the batch auction. Orders can:
- Match with each other (coincidence of wants)
- Trade against AMM liquidity
So you get passive liquidity (Uniswap-style) + fair price discovery (batch). Not purely dependent on order matching—the AMM is the backstop. Similar to CowSwap’s model.
On missed reveals due to bad internet:
Real concern. Fast batches + unreliable connections = unfair slashing.
Solutions we’re considering:
- Delegated reveals - User authorizes a service to reveal on their behalf. Your internet drops, the relayer still reveals.
- Grace period - First miss = warning, repeat = slash
- The L3 layer we mentioned - Submit order to L3, L3 handles commit/reveal automatically. Solves the “what if I go offline” problem.
The L3 isn’t just for persistent orders—it’s also for reliability. User’s job is to express intent. L3’s job is to execute it reliably.
Goodmorning @TabulaRasa 
Tonight I was reflecting that the idea behind this protocol is already over-complicated as it stands and it doesn’t feel like a good market fit for the current state of DeFi on CKB. Not only that, it’s gonna get only more and more complex from here on, as you’ll have to account in the protocol design for all issues that will arise.
While not perfect solutions, I see the followings as simple & right on the mark:
- UDT Payment Solutions
- feat: Introduce `FeePayer` concept for flexible transaction fee handling · Issue #274 · ckb-devrel/ccc · GitHub
- feat: new layer of `FeePayer` as a helper for transaction final completion step by ashuralyk · Pull Request #328 · ckb-devrel/ccc · GitHub
That’s why I’m choosing to dedicate my time to these instead, as they have greater potential for success on CKB.
Wish you the best luck,
Phroi
1 Like
Morning Phroi!
Fair point - we might be ahead of where CKB DeFi is today. The “prepare for future problems” approach isn’t everyone’s priority, and simpler wins matter.
Appreciate the engagement - your questions genuinely improved the design (L3 layer, AMM backstop clarity, delegated reveals). That feedback lives in the docs now.
Good luck with the UDT/FeePayer work. If CKB DeFi grows and MEV becomes a real problem, maybe our paths cross again.
Best,
Vibeswap
1 Like