Security argument

This article makes a structured argument for why Gummiworm’s construction is secure against the adversaries it is designed to resist. It is not a formal proof. Its aim is to spell out, with enough rigor to be reviewable, what properties the protocol claims to provide, what assumptions those properties rest on, and why each property holds. Where the argument depends on mechanisms described elsewhere in the whitepaper, we cite the relevant article rather than restate the mechanism.

The comparative analysis frames Gummiworm against other scaling approaches at a higher level. This article is its more disciplined counterpart: assumptions stated up front, three core claims, then justifications.

Adversary model and trust assumptions

We describe a single Gummiworm head with K head peers and a coil network of N peers that requires an M-of-N threshold of coil signatures to ratify L1 effects (M ≤ N).

Cryptographic assumptions. We assume standard hardness for the elliptic-curve signature schemes used by the head and coil for transaction signing, and collision resistance for the hash functions in use. The integrity of the KZG trusted setup requires that at least one participant in the Powers of Tau ceremony deleted their toxic private data after contributing. Gummiworm reuses the Ethereum ceremony, which gathered approximately 141,000 contributions through a diversity of independent client software implementations — robust both against broad attacker capture of contributors and against software bugs in any single client.

Network model. Within the head and coil networks, we assume eventual delivery of messages between honest peers. The Raft-inspired replicated log retransmits on absence of acknowledgement, so transient drops are absorbed without protocol-level intervention. User-to-peer connectivity is best-effort: users can submit to multiple head peers and to coil peers as fallbacks, and they do not need to maintain a connection through any single peer.

L1 trust. We treat the underlying L1 (Cardano in the worked-out case) as a black box that satisfies each of these security guarantees:

Transactions enter the chain in finite time once submitted.
Native scripts and Plutus scripts execute deterministically.
Multi-signature predicates are correctly enforced.

TEEs are not load-bearing for soundness. Where Gummiworm uses Trusted Execution Environments — for example, Sugar Rush running inside Intel TDX — the enclave defends against MEV and provides confidentiality for L2 payloads. The protocol’s safety properties for user funds do not depend on TEE integrity. If the enclave is fully compromised, the worst case is loss of MEV resistance and payload confidentiality — not loss of user funds.

Honesty conventions. We use “honest” to mean “follows the protocol exactly”. An honest head peer signs only block briefs and block stacks that derive deterministically from the replicated log; an honest coil peer signs only block stacks consistent with the head’s hard-confirmed evidence. We use “offline” to mean “produces no signatures in the relevant window”, and treat it as honest-by-abstention for ratification purposes — an offline peer cannot be coerced into participating in a malicious quorum.

Claims and justifications

Soundness

Claim. Assume at least one head peer is honest, or at least (N − M) + 1 coil peers are honest. Then any disbursement of user funds from the head’s L1 treasury must come from a valid and authorized chain of user requests leading back to the funds’ entry into the head’s custody — either via initialization or via deposit requests.

Justification. Disbursement happens through L1 effects under the multisig regime — settlements, rollouts, and finalizations. Each is a transaction signed by all K head peers and an M-of-N coil quorum, with the signature predicate enforced by the head’s native script on Cardano. No transaction can leave that script’s custody without satisfying both signature requirements simultaneously; the L1 itself enforces this, not the protocol.

The two disjunctive cases each suffice to block any adversary that has not compromised both the head and the coil:

One honest head peer is sufficient because settlement requires unanimous head signatures. The honest head peer signs only block stacks that derive deterministically from the replicated log — that is, from the sequence of user requests that the consensus protocol has already committed to via request IDs and the follower-verification rules. Because the L2 ledger is deterministic, the effects in any signed block stack trace exclusively to prior requests, and recursively to the source of those funds (initialization and/or deposit requests).
(N − M) + 1 honest coil peers leave at most M − 1 malicious coil signatures available, which is below the slow-consensus threshold. An honest coil peer signs only block stacks that pass its independent verification of the same deterministic L2 execution. Without the coil’s threshold signature, no settlement reaches L1.

The lying-peer proof provides an additional layer of accountability against individual head-peer misbehavior. A head peer who assigns different requests to the same (peerId, seqNum) slot produces a slashing artifact that any observer can submit on-chain, transitioning the head out of the multisig regime and (where bonds are configured) forfeiting the lying peer’s bond.

Liveness

Claim. Assume all K head peers and at least M coil peers are online and follow the protocol. Then the head remains open: fast consensus produces soft-confirmed blocks, slow consensus produces hard-confirmed block stacks, and settlement effects can be ratified and submitted to L1.

Justification. Fast consensus requires that all K head peers each produce block briefs in their leader turns and acknowledge each other’s briefs. With all K online and following protocol, each leader turn produces a soft-confirmed block. Slow consensus further requires that each block stack be signed by all head peers and by an M-of-N coil quorum; with M coil peers online and following protocol, hard-confirmation also proceeds. Submission of ratified effects to L1 is permissionless (R9): any peer that holds the signed transaction can submit it.

While these conditions are met, the fallback transaction does not fire. Each fallback’s validity_start_time is deferred far enough that a timely subsequent settlement supersedes it before maturity, so as long as the head produces settlements at the cadence required by the configured silence duration, no fallback reaches its trigger.

Recovery from short outages. A brief loss of availability — fewer than K head peers or fewer than M coil peers online for some interval — does not immediately force the head into the rules-based regime. As long as availability is restored before the next pre-signed fallback transaction’s validity start time, the head can in principle resume multisig-regime progress by replaying the replicated log from each peer’s latest hard-confirmed state. Each peer needs to persist enough message history and ledger state to recover after a crash without losing the prefix of the log already shared with other peers. Persistence and crash-recovery mechanisms are underspecified at present; this property is contingent on their eventual concrete design.

Evacuation

The evacuation guarantee decomposes into four claims:

Funds always evacuate eventually if multisig consensus stalls without recovery.
Funds only ever evacuate to the right owners.
Dispute resolution selects the latest hard-confirmed evacuation commitment compatible with the rules-based-regime treasury, if at least one honest party participates.
Every payout in the resolved evacuation commitment is fully backed by the rules-based-regime treasury, regardless of which settlement’s state fallback handed over.

Funds always evacuate

Claim. User funds in the head are never permanently stranded. Either the head produces a settlement that disburses them on the happy path, or the head transitions to the rules-based regime, after which any user can permissionlessly recover their share.

Justification. Each settlement and finalization effect ships with a paired post-dated fallback transaction. If the head fails to produce a superseding settlement before the fallback’s validity start time, any peer (or any user with the signed fallback) can submit it to L1, transitioning custody to the rules-based regime. Once in that regime, evacuation is permissionless: each user constructs a KZG membership proof against the resolved evacuation commitment and submits an evacuation transaction that pays them their share. Proof verification is a single bilinear pairing check on-chain, and its correctness depends only on the trusted-setup assumption stated above.

Funds go only to the right owners

Claim. Funds evacuated from the head can only be claimed by the owners enumerated in the evacuation commitment that the dispute resolution has selected.

Justification. The KZG construction binds each owner’s payout entry to the commitment as a whole. Membership proofs against the resolved commitment are unforgeable under the trusted-setup assumption, and the resolved-treasury script accepts only a valid KZG proof against the resolved commitment as a redeemer. No party can claim funds for an owner not listed in the commitment, and no claim can exceed the owner’s listed entry. Off-the-list addresses produce no valid proof.

Dispute resolution selects the latest hard-confirmed commitment

Claim. The dispute resolution selects the latest hard-confirmed evacuation commitment compatible with the rules-based-regime treasury, as long as at least one honest party — peer or otherwise — submits that commitment to a ballot box before the dispute resolution deadline.

Justification. The rules-based regime resolves disputes through vote, tally, and resolve transactions. The fallback transaction creates two kinds of ballot boxes:

Exclusive ballot boxes, one per head peer, fillable only by the corresponding head peer. They guarantee each head peer an opportunity to register the latest commitment they hold.
Public ballot boxes, open to any submitter — users with signed receipts, third-party watchers, or any other holder of the latest signed commitment.

The vote, tally, and resolve transactions enforce three on-chain constraints that shape what the dispute can settle on:

Ratchet on public ballot boxes: a vote can only replace the box’s current entry with a commitment that multisig consensus had already shown to supersede it, evidenced by the new commitment’s multisig signatures. The ratchet prevents an adversary from spamming the box with arbitrary or older commitments to delay resolution.
Major-version compatibility with the treasury: every commitment submitted to any ballot box must match the major version of the rules-based-regime treasury. The treasury inherits a specific major version from the settlement that produced it before fallback fired; commitments tied to other treasury states are rejected, and already-executed settlement effects cannot be rolled back by the dispute.
Coarse grain of hard-confirmable commitments: slow consensus signs evacuation commitments at most once per major block version, denying grinding-denial attackers fine-step legitimate increments with which to ratchet a public ballot box just enough each time to exhaust the deadline.

Under the soundness honesty assumption (at least one honest head peer or (N − M) + 1 honest coil peers), multisig consensus will not hard-confirm an evacuation commitment that regresses on, or is incompatible with, the latest commitment it has already signed. The honest parties that veto unauthorized disbursements also refuse to sign out-of-order or off-state commitments. The set of hard-confirmed commitments admissible to the dispute is therefore bounded above by the genuinely-latest commitment signed during the head’s lifetime.

Diligent on-L1 submission of hard-confirmed settlement effects — by at least one honest party — keeps the multisig regime treasury current. Each settlement effect has a validity_end_time after which it can no longer be submitted; as long as one honest party submits each settlement before its expiry, any older fallback is invalidated by the new settlement consuming the multisig regime utxo. The rules-based regime then inherits the latest treasury major version, and the dispute’s admissible commitments are those hard-confirmed against this latest state.

Provided at least one honest party participates before the dispute resolution deadline, the tally and resolve transactions retain the latest hard-confirmed commitment as the resolved commitment governing evacuation. Honest participation can come from any channel: a head peer using their exclusive ballot box, or any holder of the latest signed commitment using a public ballot box. If no honest party participates before the deadline, the resolution settles on whatever was submitted, which may be older than the user’s last hard-confirm.

Evacuation solvency

Claim. Every payout in the resolved evacuation commitment is fully backed by the rules-based-regime treasury, regardless of which settlement’s state fallback handed over.

Justification. Slow consensus signs evacuation commitments at major-version granularity, each one paired with the multisig regime treasury state produced by the settlement of that major version. When fallback fires, the rules-based-regime treasury inherits the major version of the settlement that produced it; the dispute’s compatibility check then restricts admissible commitments to those of the matching major version. The resolved commitment is therefore one that was hard-confirmed against this exact treasury state, and every payout in it is backed by treasury value by construction.

Solvency holds even when fallback fires from a non-latest multisig regime treasury — for example, because diligent submission of hard-confirmed settlement effects was not maintained and a settlement expired on L1. Diligence affects which settlement’s state reaches the rules-based regime, and thus how recent the resolved evacuation can be, but it does not affect whether the resolution can pay out what it promises.

What this argument does not establish

This article does not prove the following:

Formal proof of correctness. The arguments here are at the level of structured reasoning supported by mechanism descriptions. The protocol has not yet been modeled in a proof assistant or formal model checker.
Cryptographic primitive security. We assume signature schemes, hash functions, and the KZG construction are secure. The protocol’s safety degrades to the security of these primitives.
L1 security. We assume Cardano’s consensus, transaction processing, and script execution are correct. Any attack against the L1 itself can defeat the protocol’s L1-anchored guarantees.
Correct implementation of on-chain script logic. We assume the head’s native scripts and Plutus scripts faithfully implement the intended protocol semantics. Implementation bugs in those scripts (typos, off-by-one errors, missing input or output checks) can break the guarantees above. Surfacing them requires separate code audit.
Multi-head and cross-head security. This argument scopes to a single head. Cross-head transactions and inter-head custody (described in the roadmap) require additional arguments that we have not yet formalized.
Sybil resistance for the coil. The argument assumes M-of-N is a meaningful threshold given the coil’s identity model. In the single-head deployment, the head operator selects their own coil peers and incentive alignment is negotiated bilaterally. We expect to develop a formal sybil-resistance argument when we implement the multi-head Gummiworm protocol and the associated coil incentives for a permissionless coil.

We expect to expand and harden these arguments through community review and, over time, formal modeling of the most safety-critical components.