Comparative Analysis

We’ve been using the term “Custody Settlement Protocol” for Gummiworm, as it doesn’t fit neatly into existing scaling solution taxonomies. This section identifies a number of dimensions important to potential users and businesses deploying on Gummiworm, and compares Gummiworm to other industry-leading solutions, providing an objective and humble analysis of the tradeoffs that Gummiworm makes.

Security Model

The central question for any blockchain solution, L1 or L2, is “What is its security model?”

The answer to this question should address:

Which actors, if malicious, can perform which actions to manipulate, corrupt, or stall the evolution of state?
What are the practical and worst-case scenarios for critical business state and custodied funds?

In Gummiworm’s case, it derives its security from a robust and diverse validator set, called the Coil, which together implement a replicated state machine.

This validator set is economically aligned via a bond and payment flow incentive model that limits the utility of collusion.

Each head can optionally provide MEV and censorship resistance, and various levels of privacy, via its native support for TEE infrastructure, but we make no reliance on the TEE for the soundness of the ledger state or security of user funds.

In particular, because execution and custody of funds are cleanly separated between the head and the coil, and because of the fallback to the rules-based regime, these properties hold even for a modest deployment. Consider a single head with K head peers and a coil requiring M-of-N threshold signatures. Such a deployment:

can never result in a user believing their transaction is hard-confirmed when it is not
has significant economic penalty if a user is led to believe their transaction is soft-confirmed when it is not
cannot censor a user’s transaction without complete collusion of all K head peers and M coil peers
- if the head is using the TEE extensions, each transaction is opaque, giving very little signal on which a head can meaningfully censor
- if a single head peer is honest, the user can broadcast their transaction to all head peers, and the honest peer will include it
- if all head peers collude, but there is an honest majority of coil peers, the user can submit their transaction to the coil, who can then submit to the head, revealing the censorship, halting consensus, and forfeiting the bond
cannot fabricate or falsify a transaction without collusion of all K head peers and M coil peers, since the coil only ratifies state transitions produced by the head

In practice, then, liveness is guaranteed by K+M honest and online parties, but custody of L1 funds is secured by just (N-M)+1 honest coil peers.

Keeping (N-M)+1 coil peers honest via sufficient bond and access to a revenue stream allows us to ultimately make the coil network permissionless and attract a very large diversity of validators.

We can compare this to the security guarantees of other scaling solutions, some with stronger and some with weaker guarantees than ours.

First, Gummiworm has significantly stronger security guarantees around user deposits than most threshold-signature-based L2s. By building “evacuation” into the protocol as the central and unavoidable construction, a liveness failure doesn’t result in locked user funds. A consensus breakdown is an economic inconvenience rather than a loss of user funds. While most threshold systems would require M honest peers to maintain custody, we only require (N-M)+1 honest peers. In a 70 out of 100 threshold signature scheme, that’s the difference between 70 and 31 honest peers.

Gummiworm most resembles a state-channel solution, like Hydra or Bitcoin Lightning. In essence, it is a very large validator-set state channel, reaching consensus on snapshots that can be used to close the head. However, the explicit separation of custody and execution enables a much more favorable security model. Because only the head peers need to participate in fast consensus, while the coil ratifies asynchronously, Gummiworm can scale the validator set much larger than would be feasible in a traditional state channel without proportionally slowing down the happy path.

While we do utilize TEEs in Gummiworm, we make an explicit choice not to depend on their security. Side-channel attacks on hardware enclaves are not unheard of, and we reduce the profit surface area from potentially billions of dollars of user funds down to low hundreds of thousands in potential MEV extraction. This is in contrast to most crypto-TEE platforms, which go all-in on the trusted enclave.

Where we do make concessions and tradeoffs is when comparing to rollups.

An optimistic rollup, by having a very long ratification period for any L1 effects, is able to achieve a single honest observer security assumption: it just requires one permissionless user to submit sufficient fraud proofs to challenge the bond and prevent the ratification of a bad state. Systems like Arbitrum and Optimism have demonstrated this model at scale, collectively securing billions of dollars in value and processing significant transaction volume on Ethereum. However, ensuring these systems are secure in practice can be extremely challenging. The so-called verifier’s dilemma poses a fundamental incentive problem: if the system works well, fraud is rare, so watchers are never rewarded, so rational actors stop watching, which in turn creates an opportunity for fraud. The correctness of the fraud proofs themselves is also extremely load-bearing; the design space involves a difficult trilemma between permissionless participation, fixed challenge periods, and resistance to resource exhaustion attacks .

A ZK rollup, on the other hand, utilizes the compressive nature of zero-knowledge technologies to prove the validity of the state transition. ZK rollups like zkSync and StarkNet have reached production and demonstrated the viability of the approach for certain workloads. However, proof generation remains expensive, and building fully correct and general-purpose zero-knowledge virtual machines remains, in our opinion, one of the hardest open engineering challenges in the space. Application-specific ZK circuits are more tractable, but constrain what computation you can run — a tradeoff fundamentally at odds with Gummiworm’s pluggable ledger model.

Censorship Resistance

Gummiworm has a layered set of mechanisms to avoid censorship and profit-motivated transaction reordering (MEV):

First, as the user submits their request, they receive a signed confirmation that the head peer has assigned a monotonic order number to their request. This can be used later as evidence to trigger evacuation if that peer later assigns a different transaction to that request ID.
Second, the user receives a finality receipt signed by all head peers once the head peers have determined the order and outcome of the request. This serves as “soft” finality, and prevents the transaction from later being reordered or assigned a different outcome.
Third, if a single head peer is refusing to respond with a certificate, the user can submit to the other head peers, ensuring a single honest head is enough to avoid censorship.
Fourth, even if all head peers collude, the user can submit via one of the coil peers. If the head peers refuse a certificate or finality receipt to a coil node, the coil node withholds its signature, ultimately triggering evacuation.
Fifth, each head may optionally use a TEE to run the head peer nodes, allowing users to encrypt transactions for the trusted enclave. This turns each request into an opaque ciphertext that prevents the head peers from strategically reordering transactions. They would have to rely on external metadata like timing, source IP, or signer, which are unreliable signals for extracting value.

On the other hand, most L2s today provide very little built-in defense against MEV, often relying on a single or small rotating coalition of sequencers who have complete view and control over the ordering of transactions. State-of-the-art advancements focus on encrypted mempools, which use threshold encryption to hide transaction contents until ordering is committed. While promising, these approaches face significant practical limitations around metadata leakage, incentivized decryption, and committee collusion. Gummiworm’s TEE-based approach sidesteps several of these issues: the encryption key is derived and held within the enclave rather than distributed across a threshold committee, and the user can independently verify (via attestation) that the enclave is running the expected code.

Evacuation and Failure Modes

One of the key insights of Gummiworm, as we mention above, is that we make failure a centerpiece of the protocol. The key perspective shift is that Gummiworm largely exists to efficiently arrange for each coin to inevitably end up with the proper owner should consensus break down. With such an “evacuation plan” baked into the protocol, the remaining happy path can be much simpler and lighter weight.

The main way it does this is with a dead-man’s switch: before signing any L1 transactions, the peers all ensure they have a post-dated transaction chained off the proposed effect which dumps the funds into a Plutus contract that can mediate the selection of a specific snapshot. With this transaction in hand, the peers can sign the proposed transaction without fear that funds will become stuck in the multisignature script.

This means that all failure modes are simply degenerate cases of a liveness failure. Each peer can simply withhold signatures and the system automatically falls back to that resolution mechanism. While the mechanism is designed to enable a user-sovereign exit, it’s also designed to, by default, fan out the maximum number of users per transaction, efficiently utilizing the resources of the L1 to exit users in bulk.

Additionally, this insight is at the heart of how Gummiworm is able to support multiple L1s. The evacuation map abstraction is universal enough to support a straightforward implementation across any L1 we might want to integrate with.

We can compare this to the complexity around failure states in other L2 and state channel scaling solutions:

Threshold multisignature bridges and sidechains have a similar structure. However, if consensus breaks down, user funds are locked in the multisig address. If the software can’t regain consensus, it may need the operators to manually mediate and recover user funds, and in the worst cases, may permanently lock them.

Optimistic rollups usually include forced-inclusion mechanisms that allow a user to force a withdrawal if the sequencer is censoring them. However, this requires users to independently reconstruct their state and submit their own proofs. The 7-day withdrawal window makes withdrawals unwieldy, and the mechanism is intended for individual exits, not for resolving a mass consensus breakdown.

ZK rollups have the strongest individual exit guarantee, as users can submit their own withdrawal transactions directly with no 7-day window. However, again, these are designed for individual exits, and would congest the L1 severely if used at scale.

Plasma comes closest to this insight, having an explicit failure mode known as “mass exit”. Like rollups, however, each user exits individually, creating mass competition over block space. This congestion problem was never satisfactorily resolved, and is a major reason why Plasma fell out of favor .

State channels are the closest analog, spiritually, to Gummiworm. As noted above, Gummiworm operates as a very large validator-set state channel, and shares the same basic exit mechanism: reach consensus on a snapshot that can be used to close the head.

Ultimately, it is the hope that such evacuation maps are never needed. Like good insurance, they are there to enable normal operation with peace of mind. In Gummiworm’s case, that takes the form of simpler and lighter-weight consensus throughout. Rather than having to handle each different type of malicious behavior or liveness failure individually, all components can safely rely on the evacuation map as the universal fallback.

Computation Model

Perhaps the most overlooked yet powerful feature of Gummiworm is the ability for businesses to bring their own ledger. Specifically, Gummiworm is a settlement protocol, and so long as your system of accounting can support a replicated state machine (with properties like replay prevention, determinism, and solvency), it becomes trivial to integrate into Gummiworm.

This allows you to easily deploy with a Cardano EUTXO ledger model, an EVM layer, a privacy-preserving ZK VM, or even a purpose-built business-specific ERP. The latter unlocks a very attractive enterprise adoption model, because we don’t need to ask enterprises to completely reinvent their engineering stack to deploy their custom ERP rules to gain access to multi-chain cryptographic infrastructure.

Nearly every other scaling solution locks into a specific ledger model, and that ledger model is deeply coupled with the L1 security guarantees. TEE coprocessors are a notable exception, but to achieve this they need to make their security guarantees rely principally on the hardware security itself, which has proven a dangerous assumption to make.

Of course, we have to acknowledge that this is a double-edged sword. We give up two substantial benefits of a unified accounting model. First, if everyone is using the same accounting model, there is a unified incentive to ensure the soundness of that model, and it is likely subject to more engineering rigor and scrutiny. Second, a unified accounting model enables the composability that is difficult in traditional finance and is the main attractive quality of DeFi.

To mitigate both, we’ve evaluated most major existing ledger models to ensure they are compatible with Gummiworm, meaning those who need such confidence can piggyback off the efforts going to secure those existing ledger models and benefit from the composability within those ledgers.

Additionally, to support composability across ledgers, our roadmap includes plans for cross-head and cross-ledger transactions with atomic settlements utilizing the broader coil consensus.

Finality and Transit Times

Finality as a blockchain measurement means: how confident can any observer be that a transaction (and its effects) is included in all future versions of the ledger? BFT blockchains achieve fast finality on blocks by requiring honesty and liveness from 67% of the network. Nakamoto chains, like Bitcoin, achieve only probabilistic finality, where the probability that a transaction isn’t in all possible futures drops exponentially. Cardano strikes a middle ground, offering probabilistic finality for a window, and then enshrining all blocks at a depth of 2160 or deeper.

By contrast, Gummiworm offers two phases of finality: the first is extremely fast finality, backed by the economic security of being able to penalize a head that changes its mind; and the second is a more robust finality anchored to the L1 from which the funds originate.

In practice, this means L2 transactions enjoy a first finality shelf on the order of hundreds of milliseconds (depending on head peer count and network latency), and a second shelf on the order of minutes.

This also impacts what we refer to as “transit times”: the time to get funds into or out of the head.

For net-new funds, Gummiworm reverts to the finality of the source chain. Deposits go through a structured lifecycle: registration (where the L2 ledger validates the deposit intent), a maturity wait (to ensure the L1 deposit has sufficient finality), and then absorption into the main compartment. In the case of funds coming from Cardano, the maturity wait means several hours before a deposit can be absorbed (though the upcoming Peras improvements will allow us to shorten that considerably). Importantly, deposits that are never absorbed are automatically refundable by the depositor after a deadline, so funds are never at risk of being stranded in limbo.

On the other hand, Gummiworm builds in a native liquidity bridge. If another party with funds already in the head is willing to accept the settlement risk in return for a small fee, this deposit time is dramatically shortened.

Withdrawals have the same finality characteristics as L2 transactions: strong economic confidence (and the ability to begin chaining transactions, for L1s that support it) in hundreds of milliseconds.

Optimistic rollups provide a similar profile, though with much worse hard finality and transit times. Withdrawals typically require waiting out the full 7-day challenge window, though third-party liquidity bridges can shorten this at the cost of additional trust assumptions and fees.

ZK rollups provide better transit times than optimistic rollups, but are largely bottlenecked by proof generation time on top of the L1 finality speed.

State channels typically have better finality (since they similarly sign snapshots, and have fewer participants), and similar transit times to Gummiworm.

Is This a Novel Construction?

Ultimately, nearly all of Gummiworm’s core components or insights are not new: its strength is not some fundamentally new technological innovation.

However, it combines these existing patterns in a genuinely novel way, providing an attractive combination of properties when compared against existing scaling solutions:

It leverages TEEs to give MEV resistance, without giving up its security model to trust in the hardware
It provides flexibility, both in sourcing funds and in the rules governing state updates
It provides excellent failure recovery compared to other solutions
It provides competitive or excellent finality and transit times

The result is a protocol that can serve as credibly neutral infrastructure for a wide range of use cases, from DeFi applications that need a familiar ledger model, to enterprises that want to bring their own accounting rules, to multi-chain deployments that need a consistent custody and settlement layer across L1s.