One canonical history. No privileged L2 sequencer.
Following my earlier discussion on based EVM architectures for CKB, I’ve taken this direction forward as an independent project: Tactus O1.
Tactus O1 is an experimental EVM validity rollup designed around CKB’s PoW consensus and Cell model. The central idea is to allow independent builders to propose EVM batches, while CKB determines their canonical succession and eventually verifies the resulting execution through validity proofs.
I’m developing this as a solo research and engineering project for now. The repository already contains working components and reproducible experiments, although the complete rollup and its security guarantees are still under development.
1. The direction
Godwoken established an important precedent for running Ethereum-compatible applications on CKB. With Tactus O1, I’m interested in taking a different approach to sequencing and settlement.
The goal is to combine:
- Permissionless batch proposals, with CKB rather than a privileged L2 sequencer determining canonical history.
- Ethereum-compatible execution, built around Reth/revm and familiar Solidity tooling.
- CKB data availability, so accepted transaction inputs can be independently retrieved and replayed.
- Validity-enforced settlement, with execution proofs verified on CKB.
- Independent recovery and exits, without relying indefinitely on the original operator.
The intended architecture is:
flowchart TB
U["Ethereum wallets and applications"]
B["Independent batch builders"]
C["CKB PoW + Cell-based ordering"]
D["CKB batch-data publication"]
E["Independent EVM replay"]
P["ZK validity proving"]
S["CKB settlement and withdrawals"]
U --> B
B --> C
B --> D
C --> E
D --> E
E -. "Planned" .-> P
P -. "Planned" .-> S
The important distinction is that builders still determine transaction order within their candidate batches. CKB determines which batch succession becomes canonical.
The proposal therefore removes the need for an exclusive L2 sequencing authority, but it does not automatically eliminate censorship or guarantee fast confirmations.
Those properties need to be established separately.
2. Why O1?
The previous thread explored the broader design space. Here is the short version of where I’ve landed:
| Settlement model | CKB data availability | External data availability |
|---|---|---|
| ZK validity | O1 — Selected baseline | O2 — Future Validium domain |
| Optimistic | O3 — CKB-VM Court research | O4 — Parked |
I’ve chosen O1: CKB-based sequencing, CKB data availability and ZK validity settlement as the initial development path.
It offers a relatively clear security model: CKB establishes the accepted batch history, the necessary execution data is published on CKB, and validity proofs are intended to secure the resulting state transitions.
External DA may eventually be useful for higher-throughput applications, but it introduces different recovery assumptions. I would rather establish the O1 guarantees first than introduce those assumptions prematurely.
O3 remains an interesting research direction, particularly for CKB-VM-based adjudication, but it is not part of the initial implementation.
3. What exists today?
I’ve been working on the protocol’s basic execution, ordering and recovery boundaries.
The repository now includes:
- CKB ordering experiments, exercised on isolated CKB devnets with competing transactions and controlled reorganisations.
- EVM execution and differential tests, comparing a pinned Shanghai-profile revm implementation against Geth on a limited set of workloads.
- Authenticated batch-data publication, followed by independent EVM state reconstruction from canonical CKB history.
- Priority-inclusion experiments, testing how CKB Cell dependencies behave under competing and uncooperative builders.
One result has been particularly instructive.
A priority message can be legitimately admitted on CKB, and a challenge against its omission can mature successfully, while a builder continues producing valid batches without processing that message.
flowchart TB
A["User submits a priority message"]
B["Message is admitted on CKB"]
C["Challenge becomes valid"]
D["Builder continues producing batches"]
E["Message remains unprocessed"]
F["Enforceable processing rule"]
A --> B --> C --> D --> E
E -. "Still required" .-> F
This illustrates the difference between being allowed to submit a transaction and having an enforceable right to its processing.
It is also why I don’t consider permissionless batch construction alone sufficient evidence of censorship resistance.
The experiments are making progress, but G2 — enforceable forced inclusion — remains open.
4. What comes next?
The immediate objective is to complete one coherent, independently verifiable rollup path:
Ethereum execution → CKB ordering and data publication → validity proof → CKB settlement → independent withdrawal.
There are three main questions I want to resolve:
Enforceable inclusion. Can CKB’s existing Cell and Script primitives require the processing of admitted priority messages without introducing a privileged sequencer or an unacceptable contention bottleneck?
Settlement liveness. How can the protocol ensure that a canonically accepted batch cannot permanently block later settlement because its execution is unprovable?
Independent recovery. Can another operator reconstruct the necessary state and proving inputs, settle valid execution, and support withdrawals after the original operator disappears?
The project has reproducible local evidence for several underlying mechanisms, but not yet for these complete guarantees. End-to-end ZK settlement, production custody and independent exits remain unfinished.
I’m deliberately keeping more elaborate fast-preconfirmation schemes, execution DAGs and external DA outside the initial implementation until the core security path is established.