EUTXO as L2

State

In the EUTXO-based L2 ledger, the black-box L2 ledger state consists of:

• The main compartment — a set of utxos that can be spent and referenced by L2 transactions.
• The deposit compartments — each containing a set of utxos that will be added to the main compartment when Gummiworm decides to absorb the corresponding deposit.

This state can evolve while Gummiworm is in the multisig regime, and it stops evolving when Gummiworm falls back to the rules-based regime.

Gummiworm keeps the evacuation map identical to the L2 ledger’s main compartment. During evacuation, perform these actions:

1. Remit the main compartment’s utxos on L1.
2. Discard the deposit compartments — depositors will recover these funds via the refund effects.

Deposit request

The L2 payload of a deposit request is a list of new transaction outputs, which must satisfy the same rules that the L2 ledger applies to transaction requests’ outputs. Gummiworm determines the deposit’s outcome in two stages — registration on the L2 ledger, then a later decision to absorb or reject the deposit based on what the user does on Cardano L1.

Registration

Upon receiving the deposit request, Gummiworm issues a RegisterDeposit command to the L2 EUTXO ledger:

• Valid: the ledger stores the payload’s transaction outputs in a new deposit compartment. Gummiworm then hard-confirms the deferred refund effect, at which point the user can safely submit her deposit transaction on Cardano L1.
• Invalid: the ledger reports the request as invalid with an error code. The request is terminal — no L2 state change, no evacuation map update.

Decision

After waiting for the maturity duration (long enough for Cardano L1 finality), Gummiworm checks whether the user’s deposit transaction exists on L1 within the deposit’s absorption period:

• Present and within absorption period: Gummiworm decides to absorb. It issues ApplyDepositDecisions (absorb), and the L2 ledger transfers the deposit compartment’s outputs to the main compartment. Gummiworm receives the corresponding evacuation map update.
• Absent or expired: Gummiworm decides to reject. It issues ApplyDepositDecisions (reject), and the L2 ledger removes the deposit compartment. The user can recover her L1 funds via the refund effect that was hard-confirmed earlier.

Transaction request

The L2 payload of a transaction request consists of a CBOR-serialized Cardano transaction. A transaction request’s outcome is determined in a single stage: Gummiworm passes the transaction to the L2 EUTXO ledger, which spends inputs from the main compartment and routes outputs to either the main compartment (L2-bound) or to L1 settlement/rollout effects (L1-bound).

The encoded Cardano transaction must:

1. Never use these Cardano features:

   • Staking and governance — these are L1 concerns. By not staking funds held in the head, Gummiworm avoids cannibalizing L1 staking rewards; those rewards continue to flow to other Cardano delegators.
   • Byron-era features
   • Datum hashes in transaction outputs
   • Minting and burning of tokens (see transient L2 tokens for a planned extension)
   • Script collateral

2. Set the validity interval equal to the transaction request’s validity interval.

3. Set this map at the {HYDR}.l2.{headId} metadata path (see Gummiworm’s CIP-67 tags):

   • l1outputs: List[Int] — a non-empty list of transaction output indices. The transaction outputs indicated by this list are L1-bound, while the rest of the outputs are implicitly L2-bound. If this field is omitted, then all outputs are L2-bound.

Upon receiving the request, Gummiworm issues ApplyTransaction to the L2 EUTXO ledger:

• Valid: the ledger removes the spent inputs from the main compartment, adds L2-bound outputs to the main compartment, and immediately emits L1-bound outputs via this block’s L1 settlement/rollout effects. Gummiworm receives the corresponding evacuation map update.
• Invalid: the ledger reports the request as invalid with an error code. No L2 state change, no evacuation map update, no L1 payout.