Replicated state machine overview

Each peer in a Gummiworm head runs the same replicated state machine. This section describes that machine: its state, how it transitions, and what it outputs.

State

The machine’s state is the joint ledger: a prospective L1 ledger and a black-box L2 ledger. The two ledgers are kept in sync via the custody compartments they share — the main compartment and the deposit compartments. The compartments managed exclusively by one ledger (equity, exit, and fallback contingency on the L1 side) do not require synchronization with the other.

The L2 ledger also maintains an evacuation map — a record of how each user’s funds should be paid out on L1 if consensus fails. It is updated as a direct output of state transitions.

State transitions

State transitions occur as Gummiworm processes user requests by issuing commands to the black-box L2 ledger. Only valid requests cause state transitions; invalid requests leave the state unchanged. Each request can only be valid once; resubmitting the same request will always be rejected.

The two request types differ in how their transitions occur:

• Transaction requests cause a single state transition upon processing.
• Deposit requests cause state transitions in two stages: first upon registration, and again when the head peers decide to absorb or reject the deposit.

Outputs

At each block boundary, the machine emits effects — the outputs that represent the block’s impact on the L1 blockchain. Effects are batched into blocks and deterministically derived from the sequence of state transitions. Because of this determinism, any peer can rederive the effects independently by replaying the same commands in the same order — this is what allows coil peers to verify the head’s work.

Single-peer head

The state machine can be operated by a single peer, without any multi-party consensus. In this degenerate case, block boundaries are triggered by whatever logic the operator chooses rather than by the consensus protocol.

This is a surprisingly useful architecture. A single-peer head can accept a sequence of L2 ledger interactions — using any ledger model — and compress them into an efficient sequence of L1 transactions, with the L1 footprint determined entirely by when the operator chooses to close each block. This makes the single-peer head an attractive building block for user wallets and certain decentralized applications that need a structured, auditable bridge between a private ledger and a public blockchain, without requiring multiple parties to coordinate.