Back to Blog
Education

Kernel-Witnessed Admission: Censorship Resistance at the OS Level

By DEOS Team

Here's a question nobody asks about shared sequencers: what happens between the moment your transaction arrives at the server and the moment it enters the mempool?

The answer is: nobody knows. And that's the problem.

The gap in every proof system

Shared sequencers like Espresso, Astria, and Radius prove execution correctness. Given transactions A, B, C in that order, they can prove the resulting state root is valid. Some use BFT consensus to distribute trust across a committee. These are genuine improvements over single-operator sequencers.

But every one of them starts the proof surface at the mempool. The mempool is user-space software controlled by the sequencer operator. The window between a transaction hitting the server and that transaction appearing in the mempool is completely unwitnessed.

That window is where the problems live. Selective acceptance, hidden fast lanes for preferred traders, silent drops of inconvenient transactions. None of it shows up in any proof, because the proof system doesn't start recording until after the manipulation already happened.

This is not a cryptography failure. It's a boundary problem. The proof starts too late.

Moving the boundary into the kernel

DEOS Tessera introduces Kernel-Witnessed Admission, a mechanism that pushes the accountable boundary from user-space mempool admission down to the operating system kernel.

The sequence works like this. A transaction arrives at the sequencer's HTTP endpoint. The web server (dhttpd) stores the transaction blob in content-addressed storage via a cas_index_put system call. That syscall is handled by the DEOS kernel. Before the syscall returns to user space, the kernel does two things atomically, under the same lock:

First, it writes a receipt mirror: seq-rx-N mapped to the transaction hash, where N is the sequence number. Second, it emits a SEQT event into the per-CPU kernel event ring, carrying the sequence number, transaction hash, and a hardware timestamp from the CPU's time-stamp counter.

Both actions complete before the sequencer process regains control. By the time user-space code can make any decision about this transaction, the kernel has already created an immutable record of its arrival.

There is no race window. There is no gap between "arrived" and "witnessed." The canonical ingest point is the SEQT event. If the kernel committed it, the transaction was seen. Period.

What the sequencer must commit to

Each sealed batch carries five cryptographic roots committed on-chain:

  • txRoot: Merkle root of included transaction hashes. Proves what was executed.
  • stateRoot: Poseidon hash of the execution trace. Proves correct execution.
  • eventLogHash: keccak256 of the raw kernel event log. Binds the batch to the kernel's record.
  • seenRoot: Merkle root of every transaction the kernel witnessed arriving. This is the KWA commitment.
  • decisionRoot: Merkle root of inclusion/exclusion decisions with reason codes. Proves the declared fate of every witnessed transaction.

The key pair is seenRoot and decisionRoot. Together, they force the sequencer to account for every single transaction the kernel saw. Include it, or explain why you didn't. There is no third option.

The exclusion taxonomy

Not every transaction should be included. Some are malformed. Some have bad signatures or stale nonces. Some arrive after the slot is full. KWA accounts for all of this with a closed set of valid exclusion codes:

  • INCLUDED: present in the executed batch
  • INVALID_ENCODING: not parseable as a valid transaction
  • INVALID_SIGNATURE: ECDSA verification failed
  • BAD_NONCE: nonce doesn't match account state
  • INSUFFICIENT_BALANCE: sender can't cover gas costs
  • DUPLICATE: same transaction already seen
  • EXPIRED: deadline field exceeded
  • CAPACITY_DEFERRED: slot was full, transaction moves to next slot
  • POLICY_REJECTED: operator policy exclusion (requires a pre-registered, time-delayed policy rule)

Every KWA-seen transaction gets exactly one of these codes, committed into decisionRoot at batch-seal time. A transaction that appears in seenRoot but has no entry in either txRoot or decisionRoot is censorship evidence, verifiable on-chain from the committed roots alone.

The dispute protocol

KWA censorship isn't just detectable. It's disputable on Ethereum L1 with real economic consequences.

Step 1: Challenge. Anyone can submit a Merkle inclusion proof showing that a transaction hash is a leaf in seenRoot. The on-chain contract verifies the proof, opens a challenge record, and gives the operator one hour to respond.

Step 2: Refute. The operator proves the transaction was handled properly, either by showing it's included in txRoot, or by providing a decisionRoot inclusion proof with a valid reason code. If the reason is POLICY_REJECTED, the policy rule must have been registered on-chain at least two hours before the batch, preventing after-the-fact justifications.

Step 3: Slash. If the operator doesn't respond within the window, anyone can claim 25% of the operator's stake. The challenger gets the reward.

There's a critical detail here: KWA is monotonic. Once an operator commits a batch with a non-zero seenRoot for a given chain, that chain is KWA-active. If a subsequent batch omits seenRoot, it's reportable and triggers a 10% slash. Operators cannot selectively turn off KWA when it's inconvenient. It's a commitment, not an optional annotation.

What KWA does not claim

KWA is honest about its boundary. It does not claim to solve network-level fairness. Upstream infrastructure (reverse proxies, load balancers, NIC firmware, ISP routing) sits outside the kernel boundary and therefore outside the proof surface.

The precise claim is narrower and stronger: any transaction that reaches the DEOS kernel's CAS ingest path is witnessed before the sequencer has discretion over it. Exclusion after that point requires a declared, verifiable reason.

This moves the manipulation surface from application-layer mempool admission to kernel-witnessed ingest. It doesn't eliminate all possible manipulation vectors. But it pushes the boundary substantially lower than any conventional shared sequencer design, into territory where exploitation requires hardware-level attacks rather than software configuration changes.

KWA and forced inclusion

L1 forced inclusion and KWA solve related problems at different timescales.

Forced inclusion resolves censorship after the fact. If a sequencer ignores your transaction, you can submit it directly to Ethereum L1, and the sequencer must include it within a 16-slot window or face penalties.

KWA makes censorship disputable within the current slot. The operator is slashable from the very next batch commitment. Instead of "user notices after several blocks and submits a forced inclusion transaction," the accountability model becomes "operator is economically punished the moment they commit a batch that doesn't account for a witnessed transaction."

They're complementary. Forced inclusion is the backstop. KWA is the front line.

DEOS Tessera is the verifiable shared sequencer for Ethereum L2s. Read the full whitepaper or follow us on X for updates.