Transient L2 tokens

The EUTXO-based L2 ledger currently prohibits minting and burning of tokens in transaction requests. This prohibition exists because the evacuation map must be remittable directly to L1: every asset tracked in the main compartment must correspond to a real L1 asset that can appear in an L1 utxo. A token minted inside the L2 head has no L1 policy, and cannot be evacuated.

Transient L2 tokens resolve this by making the scope explicit. A transient token is one that is minted inside the head and explicitly scoped to the head’s lifetime. It never appears in the evacuation map, and therefore never needs to appear on L1 as a native asset. The evacuation invariant is preserved by construction.

The transient-token compartment

The two-compartment design tracks transient tokens separately from the main compartment:

• The main compartment continues to hold only L1-valid assets — ADA and any L1-native tokens that entered the head via deposits. This is identical to the existing evacuation map.
• The transient-token compartment tracks the transient tokens attached to utxos in the main compartment. Each entry associates a utxo ID with the bundle of transient tokens that utxo carries. A bundle holds tokens only: ADA is never transient.

The two compartments together give a complete picture of an L2 utxo’s value. The ledger’s whole state is the combined view: the main compartment overlaid with the transient-token compartment, so that each utxo’s value is its main value plus the transient tokens attached to it. From the perspective of the EUTXO ledger rules, which are unaware of Gummiworm or compartments, this combined value is each utxo’s visible value. When the ledger resolves an input or a reference input, it presents this combined value. Script execution sees the full utxo value, including any transient tokens it carries.

Policy IDs do not tell the compartments apart. The same token — the same policy ID and asset name — may exist in both compartments at once, even in a single utxo: an L1-native token deposited into the head, and transient tokens minted inside the head under the same policy. Only the transaction’s declarations, described below, assign tokens to compartments. Supporting this is a requirement.

Transaction processing

Transaction requests that mint or burn tokens are now permitted, subject to the standard EUTXO rules for minting and burning: minting scripts are executed, and the net mint/burn quantities must balance against the token quantities declared in the transaction’s mint field.

The transaction metadata at the {HYDR}.l2.{headId} path is extended with an optional field:

• l2TransientTokens: Map[Int, MultiAsset] — a map from transaction output index to the transient tokens in that output. Any output index not appearing in the map carries no transient tokens. If this field is omitted, no outputs contain transient tokens.

The processing procedure for a transaction request that involves transient tokens:

1. Check the declarations against the transaction alone:
   • Every declared index refers to an output of the transaction, and every declared bundle is non-empty.
   • An L1-bound output declares no transient tokens. A withdrawal that carries transient tokens is rejected outright, never silently stripped: transient tokens cannot leave the head.
   • Each declared bundle is at most the tokens actually in its output.
2. Resolve each input and reference input using the combined value from both compartments.
3. Validate the transaction over the combined view: scripts (minting policies included), signatures, and value conservation with the mint field.
4. Validate the projection to the main compartment: strip the mint field, reduce each output by its declared bundle, and check value conservation again against the main compartment alone. This single check is the whole enforcement for the main compartment. It rejects:
   • minting an L1-native token, because the minted tokens stay in the projected outputs with no source;
   • burning an L1-native token, because the main inputs exceed the projected outputs with no mint field to absorb the difference;
   • moving transient tokens into the main compartment without declaring them, because they appear in the projected outputs with no source.
5. Post-process the transaction:
   • Spent inputs leave both compartments.
   • Each declared bundle goes into the transient-token compartment, keyed by its output’s utxo ID.
   • The remainder of each output’s value goes into the main compartment.
6. Update the evacuation map to reflect changes to the main compartment only. Transient tokens never appear in the evacuation map.

The transient tokens balance as well: the transient tokens of the spent inputs, plus the mint, equal the declared bundles. This needs no check of its own. L2 transactions pay no fees and carry no withdrawals or certificates, so the balance over the combined view (step 3) equals the balance of the projection (step 4) plus the transient balance, and the two checked balances imply the third.

A holder who wants to take value out of the head first burns their transient tokens, or moves them to an output that stays on L2, and then withdraws the backing value.

Minting policy validation

Transient token minting policies are L2 scripts, executed by the L2 ledger during transaction validation. Policy IDs are derived from these scripts in the standard way, so a transient policy ID can coincide with an L1-native one — for example, when an issuer uses the same native script on L1 and in the head. The two-compartment design supports this: the declarations, not the policy IDs, decide which compartment a token belongs to.

The L2 ledger runs minting scripts with the standard Cardano script context, with one adaptation: the utxo values presented in that context are the combined main-plus-transient values described above, so that minting scripts can inspect the full token content of any utxo they reference.

Minting scripts may be provided inline in the transaction or as reference script inputs, following the standard Cardano mechanisms. A token issuer who wishes to use a reference script can deploy it via a normal L2 transaction before referencing it in subsequent minting transactions — no special handling is required.

Evacuation

When a head evacuates, the main compartment is remitted to L1 as before. The transient-token compartment is discarded. Utxos that carried transient tokens are remitted on L1 with only their L1-valid portion — ADA and any L1-native tokens — included. The transient tokens themselves cease to exist.

Holders of transient tokens at the time of evacuation receive the ADA and L1-native assets that backed their utxos but do not receive any token-denominated redemption. This is a forced scenario; applications that issue transient tokens should communicate this risk to their users.

A subtler risk arises for applications that use transient tokens as beacon tokens or thread tokens — tokens whose presence in a utxo authenticates it as a valid application state output. This is a common pattern on Cardano: a Plutus script at an address expects any utxo it interacts with to carry a specific token, and treats its presence as proof that the utxo was created through the application’s authorized minting path (similar to how oracle utxos are authenticated). If the head evacuates, such utxos are remitted to L1 at their Plutus script addresses but without the beacon or thread tokens. The scripts at those addresses are then stuck: they cannot process the utxos because the expected tokens are absent, and they cannot spend or recover them through their normal logic.

Applications that rely on beacon or thread tokens should document this evacuation behavior clearly and consider what recovery path, if any, their scripts provide for token-less utxos.

Finalization

Finalization is voluntary and gives the head an opportunity to clean up before closing. A head cannot produce a finalization effect while the transient-token compartment is non-empty. Users holding transient tokens must burn them — or exchange them for L1-valid assets in the normal course of L2 transactions — before the head can finalize.

This constraint ensures that transient tokens do not simply vanish in a normal closure: all outstanding tokens must be explicitly accounted for by their issuers and holders before the head shuts down cleanly. Applications that issue transient tokens should provide a redemption path so that holders can burn their tokens before finalization.