Anti-Censorship Measures

Head peers are the entry points for user requests into consensus — only a head peer can assign a request ID and broadcast the request to the other peers. Coil peers can act as intermediaries, forwarding requests to head peers on a user’s behalf, but the head peer still ultimately decides whether to assign an ID. A malicious or colluding head peer could silently discard a request — no ID assigned, no broadcast, no inclusion — leaving the user with no evidence and no immediate recourse.

This article describes a layered set of mechanisms to address this threat. Each layer narrows the censorship surface further; together they make sustained, targeted censorship either impossible or economically self-defeating.

Request ID as a Commitment

The first line of defense is the request ID itself. Once a head peer assigns a request ID (i, n) to a user’s request and broadcasts it to the other head and coil peers, that assignment enters the peer’s replicated log as an irrevocable fact. Every peer eventually receives peer i’s requests in consecutive order, with no gaps.

This ordering guarantee carries a strong consequence for the fast-consensus leader. The follower verification rules require that each block brief’s requests form a consecutive sequence from each head peer — a block brief cannot mention request (i, n+1) without first mentioning (i, n). Therefore, once peer i has broadcast request (i, n), no block brief can advance past it without including it. The head peer can either include the request in the next appropriate block brief, or stall consensus entirely. Silent exclusion is not an option.

The Lying-Peer Proof

A subtler attack is possible: head peer i assigns ID (i, n) to request R and tells the user, but broadcasts a different request R’ at position (i, n) in her log. When R’ eventually appears in a block brief, it occupies the slot the user was promised for R. This is a lie.

Because every peer holds a copy of peer i’s replicated log, the discrepancy between what the user was told and what actually appeared at position (i, n) is immediately visible to any observer who compares the user’s signed request ID assignment against the block brief. This constitutes a lying-peer proof.

On Cardano, enforcing a lying-peer proof requires a Plutus script that can accept the proof as input and transition the head from the multisig regime to the rules-based regime. This makes lying directly detrimental to the head’s operation: the head is shut down rather than allowed to proceed normally. Implementing this enforcement requires either a CIP-112 Plutus guard branch in the head’s native script, or full Plutus control of the head as enabled by CIP-118.

Shutting down the head punishes the head peers collectively but does not specifically punish the individual peer responsible for the lie. To address this, head peers can be required to post a bond as a condition of operating. A successfully verified lying-peer proof would forfeit the bond of the peer who lied, creating a direct economic disincentive for any individual head peer to attempt the attack.

Multi-Peer Submission

A head peer who never assigns a request ID cannot be caught in a lie — there is nothing to prove. To counter this, users can submit their request to all head peers simultaneously rather than just one.

If any single head peer is honest, she will assign the request an ID and broadcast it. From that point forward, the sequential ordering guarantee ensures the request will be included in a block brief before consensus can advance past it.

Multi-peer submission is sufficient to defeat censorship as long as at least one head peer remains honest. It provides no protection against full collusion among all head peers.

Coil as Submission Witness

If a user has reason to believe all head peers are colluding to censor her request, she can route the submission through coil peers. Coil peers forward the request to the head on the user’s behalf.

The coil’s leverage comes from slow consensus: a coalition of coil peers large enough to prevent a quorum (i.e., at least N−M+1 peers) can withhold their hard acknowledgements, stalling the block stack confirmation process. If the head refuses to assign a request ID to a request submitted by such a coalition, those coil peers can refuse to participate in slow consensus until the request is processed. A head that cannot hard-confirm block stacks cannot absorb deposits, remit payouts, or settle with the L1.

To compensate coil peers for this service and prevent abuse, the user’s request can include a small fee — for example, by including a transfer of funds to the participating coil peers in the L2 payload.

TDX Payload Encryption

The mechanisms above address censorship after a request arrives at a head peer. A complementary approach removes the motivation for targeted censorship in the first place.

In heads running inside a Trusted Execution Environment — such as Sugar Rush running inside Intel TDX — users encrypt their L2 payloads to a key held within the enclave. The head peers process requests as opaque ciphertexts; they cannot read the transaction content, the recipient, or the amounts involved until the enclave executes the request.

Without visibility into request contents, a head peer has no reliable basis for targeted censorship. Any attempt to selectively exclude requests would have to rely on coarse external signals such as connection timing or source address, which are weak and unreliable. Blanket exclusion of all requests would be immediately obvious and would stall the head entirely.

Layered Defense

These mechanisms address different points in the censorship surface:

• TDX encryption removes the motivation for content-based targeting.
• Multi-peer submission ensures one honest head peer is sufficient to get a request into the replicated log.
• Request ID commitment and sequential ordering ensure that once a request is in the log, it cannot be skipped.
• Lying-peer proof with Plutus enforcement and bond forfeiture make it economically irrational for a head peer to misrepresent which request was assigned a given ID.
• Coil submission provides a backstop when all head peers collude, with the coil’s slow-consensus veto as the enforcement mechanism.

A sustained, targeted censorship attack against all of these layers simultaneously would require all head peers and a quorum of coil peers to collude — at which point the fallback mechanism triggers and the user’s funds can be safely evacuated from the head.