Head initialization

Before the Gummiworm consensus protocol can begin, the head and coil peers must agree on the head’s initial state and how to achieve it. This process is called head initialization, and it follows a pattern similar to block production: first peers decide what the block should contain, then they create block effects, and finally broadcast their signatures so these can be aggregated and the effects can be executed.

Treating initialization as block zero is not merely a notational convenience—it is a deliberate design choice that pushes the block analogy as far as it will go. The initial block is structurally identical to a major block: it has an empty body, a settlement-like effect (the initialization transaction that locks funds into the multisig address), and a paired fallback transaction.

There are two aspects that differ in comparison to a regular major block and are explained in this section:

• The essence of the block is negotiated between peers upfront and reflects the intents of all head and coil peers.
• The initialization transaction is provided exogenously by the operators or their tooling rather than constructed by the head. This allows it to be arbitrarily complex—for example, it may withdraw funds from another protocol and initialize the head in a single atomic transaction.

Head initialization produces the initial block—block zero—which is the block with which Gummiworm starts up. The formal leader of block zero is always head peer zero, but since the essence of the block is negotiated manually, leadership in this case doesn’t imply making any decisions and serves purely as a signaling function.

Treating initialization as block zero pays off: since the initialization transaction mints the head’s beacon tokens, it must be signed by all head peers and a quorum of coil peers regardless. If the head did not sign the initialization transaction itself, whoever built it would need to collect exactly the same set of signatures through some other means—duplicating the effort for no benefit. By routing the initialization transaction through the head’s own consensus, the signing is handled once, correctly, by the machinery that already exists for exactly this purpose.

Overview

Head initialization proceeds in four phases:

Negotiation: bootstrap config

The bootstrap config described here is the default approach, intended for operators who do not have specific integration requirements. Operators with custom integration needs — such as initializing the head as part of a larger protocol interaction — may construct the initialization transaction differently and supply it directly as part of the head config. Any such extended bootstrap config will still need to include the mandatory fields described here, as they are required by the head regardless of integration requirements.

The bootstrap config is the human-specified input from which everything else is derived. To remain simple and editable, it groups its fields into four clusters: network and protocol parameters, peer topology, bootstrap parameters, and block-zero timing.

Network and protocol parameters define how the head behaves at runtime:

• cardanoNetwork — the L1 network on which the head operates (Preprod, Preview, Mainnet or Custom for private testnets).

• headParams — the protocol parameter values with which the head will run:

  • txTiming: minSettlementDuration, inactivityMarginDuration, silenceDuration, depositSubmissionDuration, depositMaturityDuration, depositAbsorptionDuration.
  • fallbackContingency: collectiveContingency and individualContingency.
  • disputeResolutionConfig: votingDuration.
  • settlementConfig: maxDepositsAbsorbedPerBlock.
  • coilQuorum — the minimum number of coil peer signatures required to hard-confirm a block stack and to complete head initialization.

{
  "cardanoNetwork": "Preview",
  "headParams": {
    "txTiming": {
      "minSettlementDuration": 43200000,
      "inactivityMarginDuration": 86400000,
      "silenceDuration": 300000,
      "depositSubmissionDuration": 300000,
      "depositMaturityDuration": 3600000,
      "depositAbsorptionDuration": 172800000
    },
    "fallbackContingency": {
      "collectiveContingency": {
        "defaultVoteDeposit": "1357650",
        "fallbackTxFee": "876277",
        "minAdaForTreasury": "1357650"
      },
      "individualContingency": {
        "collateralDeposit": "4500000",
        "tallyTxFee": "3000000",
        "voteDeposit": "1357650",
        "voteTxFee": "3000000"
      }
    },
    "disputeResolutionConfig": {
      "votingDuration": 347644000
    },
    "settlementConfig": {
      "maxDepositsAbsorbedPerBlock": 158
    },
    "coilQuorum": 3
  }
  // ...
}

Peer topology identifies the consensus participants:

• headPeers — the ordered list of head peers, each identified by their verification key and network address. The ordering is significant: head peer zero leads block zero, and then peers take turns in round-robin fashion as the consensus section specifies.

• coilPeers — the full static set of coil peers, each identified by their verification key and the index of the head peer they connect to as their hub.

{
  // ...
  "headPeers": {
    "headPeerVKeys": [
      "6ea3...87d9",
      "2eda...aa48"
    ],
    "headPeerAddresses": [
      "ws://192.168.1.10:8081",
      "ws://192.168.1.11:8081"
    ]
  },
  "coilPeers": [
    { "vkey": "a1b2c3d4e5f6...", "hub": 0 },
    { "vkey": "b2c3d4e5f6a1...", "hub": 0 },
    { "vkey": "c3d4e5f6a1b2...", "hub": 1 },
    { "vkey": "d4e5f6a1b2c3...", "hub": 1 }
  ]
  // ...
}

Bootstrap parameters reference on-chain data and provide initial state:

• scriptReferenceUtxos — the utxos (specified as txId:txIx) containing the pre-deployed Plutus reference scripts required by the head: rulebasedTreasury and disputeResolution.

• initialEvacuationMap — the evacuation map with which the head is initialized, mapping L1 utxo inputs to their evacuation destinations.

• initialEquityContributions — the amount of equity each head peer contributes to the initial treasury, indexed by head peer number.

• seedUtxo — the utxo input (specified as txId:txIx) consumed by the initialization transaction to produce the head’s unique nonce. Its Blake2b-224 hash becomes the headId.

• additionalFundingUtxos — additional utxo inputs (specified as txId:txIx pairs) that fund the head’s initial treasury and equity, beyond the seed utxo. These may be supplied explicitly by the operators or resolved automatically from the head peers’ keys.

{
  // ...
  "scriptReferenceUtxos": {
    "rulebasedTreasury": "a1b2...a1b2#0",
    "disputeResolution": "b2c3...b2c3#1"
  },
  "initialEvacuationMap": {
    "8258...5402": "a200...3a1b"
  },
  "initialEquityContributions": {
    "0": "102048417",
    "1": "117280909"
  },
  "seedUtxo": "ffff...ff80#5",
  "additionalFundingUtxos": [
    "7f01...4cf3#23",
    "85e5...0580#8",
    "80ff...33d3#0"
  ]
  // ...
}

Block-zero timing fixes the initial block brief’s validity window:

• blockZeroStartTime — the creation start time of the initial block brief, fixed as the negotiation baseline when the operators began agreeing on the bootstrap config.

• blockZeroEndTime — the creation end time of the initial block brief, agreed upon by the operators during negotiation. This determines the fallback transaction’s validity window and therefore must be known before the initialization transaction can be constructed.

{
  // ...
  "blockZeroStartTime": "2026-04-09T11:37:15Z",
  "blockZeroEndTime": "2026-04-09T13:37:15Z"
}

Processing and signing: head config

The head config is derived from the bootstrap config by the bootstrap tooling. It evolves the bootstrap config by resolving the utxos via a Cardano backend, building the initialization transaction, and deriving additional fields. The head config includes everything from the bootstrap config except data that is now contained within the initialization transaction or is no longer needed. The head config adds:

• The headId, derived as the Blake2b-224 hash of the seed utxo input (see initialization transaction).
• The unsigned initialization transaction body, constructed from the bootstrap config and resolved utxo outputs. Peers verify it against the invariants described in Initialization transaction regardless of any additional witnesses present.

If the integration requires it, operators may augment the unsigned initialization transaction with additional signatures or witnesses before it is distributed to the peers.

The head config is what gets distributed to the peers and stored in their local databases.

Initialization transaction

The bootstrap tooling constructs the default initialization transaction from the bootstrap config and the resolved utxo outputs as follows:

1. Spend the seedUtxo input. Its Blake2b-224 hash is the head’s unique nonce, from which the HYDR and HMRW beacon token names are derived.
2. Spend all additionalFundingUtxos inputs.
3. Mint the head’s HYDR and HMRW beacon tokens (one each) under the head’s native script minting policy.
4. Produce the multisig treasury output at the head’s native script address:
   • Include the HYDR beacon token.
   • Include the funds backing the initial L2 state and the equity contributions from initialEquityContributions.
   • Attach a datum containing the Blake2b-256 hashes of headParams and initialEvacuationMap.
5. Produce the multisig regime output at the head’s native script address:
   • Include the HMRW beacon token.
   • Include the head’s serialized native script.
   • Include sufficient ADA to cover the fallback contingency, as specified in headParams.fallbackContingency.
6. Set the transaction’s validity end time to blockZeroEndTime + minSettlementDuration + inactivityMarginDuration.
7. Set the metadata at the {HYDR}.initialization.{headId} path:
   • multisigTreasuryIx — the output index of the multisig treasury output.
   • multisigRegimeIx — the output index of the multisig regime output.
   • seedIx — the input index of the seed utxo.

Example head config

{
  "cardanoNetwork": "Preview",
  "headParams": { ... },
  "headPeers": { ... },
  "coilPeers": [ ... ],
  "scriptReferenceUtxos": {
    "rulebasedTreasury": "a1b2...a1b2#0",
    "disputeResolution": "b2c3...b2c3#1"
  },
  "initialEvacuationMap": {
    "8258...5402": "a200...3a1b"
  },
  "initialEquityContributions": {
    "0": "102048417",
    "1": "117280909"
  },
  "blockZeroStartTime": "2026-04-09T11:37:15Z",
  "blockZeroEndTime": "2026-04-09T13:37:15Z",
  "headId": "0134...6b10",
  "initTx": "84a6...0080"
}

Distribution

Distribution is currently handled by sugar-rush-boot, and will be handled by project-specific deployment software in the future. It is responsible for:

1. Injecting any project-specific data into the head config.
2. Delivering the head config to all head peers and all coil peers.
3. Starting up each peer process.

After delivery, its role in initialization is complete and the head takes over via initial block consensus.

Initial block consensus

Initial block consensus is a regular instance of the slow consensus cycle. Its purpose is to collect the multisignatures required for the initialization and fallback transactions before the Gummiworm consensus protocol begins. Before the signing rounds can start, every node must have the initial block and its effects fully constructed.

Preparation

Upon startup, every node loads the head config and parses the initialization transaction, which may already carry additional witnesses added during the processing and pre-signing phase. Each node resolves the scriptReferenceUtxos and verifies that the hashes of the deployed scripts match those in the node’s local resources and performs any other checks needed to ensure the whole head config can be handled properly.

Then each node constructs the initial block with number zero, block type initial, block version (0, 0), and an empty block body. Its block header contains:

• headId — from the head config.
• startTime — the negotiation baseline timestamp, from the bootstrap config.
• endTime — blockZeroEndTime, from the bootstrap config.
• fallbackTxStartTime — derived as shown in the timing rules.
• majorBlockWakeupTime — derived accordingly, see timing rules.

Finally, each node derives the fallback transaction as described in Fallback transaction, completing the initial block’s effects. With both the initialization and fallback transactions in hand, every node is ready to participate in the signing rounds. Head peer zero starts leading the consensus as soon as it is ready, without waiting for the other peers.

Fallback transaction

The fallback transaction is derived deterministically from the initialization transaction and the head params. Each peer derives it as follows:

1. Identify the multisig treasury and regime outputs using multisigTreasuryIx and multisigRegimeIx from the initialization transaction’s metadata.
2. Construct the fallback transaction spending those outputs, per the requirements in fallback transaction.
3. Set the fallback transaction’s validity start time accordingly, see timing rules.

Because the fallback transaction is fully determined by the initialization transaction and the head params, all peers independently derive the same fallback transaction body and can verify each other’s signatures.

Signing initialization block effects

The signing proceeds in two rounds, which must be completed in order. The initialization transaction locks funds in a multisig address from which they can only be recovered via the fallback transaction—therefore the fallback transaction must be fully multisigned before any peer signs the initialization transaction.

In round one, each head peer and each coil peer broadcasts their signature for the fallback transaction. Round one is complete when all head peers and at least coilQuorum coil peers have done so.

In round two, each head peer and each coil peer broadcasts their multisignature for the initialization transaction and their individual signatures if any utxos are spent from their individual addresses—it’s the only difference from regular major block consensus, applicable only to head peers.

Round two is complete when all head peers and at least coilQuorum coil peers have done so. The Gummiworm consensus protocol then begins with block one.

See slow consensus section for details.