Single-head governance

This article covers governance for a single Gummiworm head. Governance of the shared coil network — including coil peer selection for new heads — is a separate concern described in the Coil network article.

Gummiworm heads require governance for two distinct purposes: managing the head’s own configuration — membership, signing keys, and protocol parameters — and authorizing governance actions that need to be passed on to the L2 ledger running inside the head.

Neither purpose fits naturally inside the consensus protocol itself. Head peers’ Gummiworm nodes sign things continuously in the ordinary course of consensus, but governance actions arise from deliberate decisions that the peers make outside of that automated flow. To keep these concerns cleanly separated, each peer holds a cold governance key that is distinct from the hot consensus key their node uses in fast and slow consensus. The cold key is never held in software memory by the node; it is used only when a peer manually decides to authorize a governance action.

Governance Authorization

A governance action takes effect when it has been signed by all head peers and a quorum of coil peers, using their respective cold keys. This threshold is deliberately the same as the quorum required for L1 effects.

The equivalence is not incidental. An effect is authorized by the same set of keys and can instruct the L1 to move all funds under custody anywhere — including into a new head with an entirely different membership or configuration. Governance authority is therefore no greater than effect authority; requiring an equivalent quorum for governance actions does not weaken the security model.

Using separate cold keys, rather than reusing the hot consensus keys for governance, avoids a subtle failure mode: an automated node cannot inadvertently rubberstamp a governance action it hasn’t been explicitly instructed to sign. Governance requires a human decision; the key used to sign it should reflect that.

Membership Management

The authorization controlling the head’s L1 custody is derived from the hot verification keys of all head and coil peers, and the coil quorum threshold. Any change to the membership of either peer set — or a rotation of any peer’s hot consensus key — changes that authorization, and the head’s custody must migrate to reflect the new configuration.

When a membership change or hot key rotation takes effect, the funds in the main, equity, and fallback contingency compartments must all move to the new custody. The migration is authorized by the existing quorum — the current head and coil peers, using their hot keys — and is produced as a Gummiworm effect.

The existing fallback effect is pre-authorized against specific L1 state that the migration replaces, so it becomes invalid once the migration is executed. A new fallback effect must be produced alongside the migration — just as each settlement effect is paired with a new fallback. Outstanding rollout effects are unaffected; they reference specific L1 state by identity and can be settled independently.

Pending deposit compartments require special handling. Each pending deposit is accompanied by a pre-authorized refund effect whose terms are fixed at the time of deposit. Migrating pending deposits to the new custody configuration would require regenerating and re-authorizing those refund effects — a logistically complex operation involving depositing users. For now, the practical approach is to refund all pending deposits at the time of a membership change. Users can re-deposit under the new configuration once the migration is complete.

Cold key rotation does not trigger a migration. Cold keys are not part of the custody authorization; only hot keys are. Rotating a peer’s cold key requires only that the change be recorded in the head’s governance key registry — a consensus-state update with no L1 footprint.

Protocol Parameters

Not all protocol parameters are equally safe to modify in a running head. The right mental model is to ask whether changing the parameter could undermine commitments already made to in-flight operations.

Timing parameters for future operations are generally safe to update. For example, the deposit maturity and absorption durations affect how long new deposits must wait before the head can absorb them. Existing pending deposits were submitted with specific deadlines already baked into their post-dated refund transactions; those deadlines are unaffected by a parameter change. Only deposits submitted after the change takes effect will see new timing.

Fallback timing parameters demand more caution. The silence duration and inactivity margin determine how quickly the fallback mechanism can trigger, which in turn sets the security margin for settlement. Shortening these parameters could create a race condition in which a fallback transaction becomes valid before an in-progress settlement effect has been confirmed on-chain. Any reduction in fallback timing should be treated as a high-risk governance action, applied conservatively, and coordinated with an absence of in-flight settlements.

The coil quorum threshold cuts both ways. Raising it strengthens the security guarantee but makes effects harder to produce — if fewer coil peers are reliably online than the new threshold requires, the head stalls. Lowering it weakens the security guarantee by reducing the number of coil peers required to collude to falsely authorize an effect. Either direction deserves careful consideration.

The precise classification of every parameter — safe, restricted, or prohibited from in-place updates — is left for the protocol specification. As a general principle, changes that only affect future behavior and carry no risk of racing with in-progress commitments are candidates for safe in-place updates. Changes that touch the security invariants of running operations should be approached with the same caution as a head migration.

L2 Governance

The L2 ledger running inside a Gummiworm head may have its own governance requirements that are independent of the head’s configuration. Sugar Rush, for instance, needs a way to authorize the creation and management of trading markets, designate a protocol fee account, and update Sugar Rush-specific protocol parameters.

These are not concerns that Gummiworm needs to understand semantically. Instead, Gummiworm provides a general mechanism: a governance action can carry an opaque L2 governance payload alongside the cold key signatures. Once Gummiworm has verified that the quorum of cold key signatures is valid, it passes the payload to the L2 ledger as a governance command. The L2 ledger interprets the payload and applies whatever changes it encodes.

This keeps L2 governance cleanly layered: the L2 ledger defines what governance actions mean and what they can affect; Gummiworm provides the authorization mechanism and enforces the quorum requirement.