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 a set of transient token bundles.

The two compartments together give a complete picture of an L2 utxo’s value. From the perspective of the EUTXO ledger rules, which are unaware of Gummiworm or compartments, each utxo’s visible value is the sum of its entries in both compartments. 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.

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:

• transientOutputs: Map[Int, Value] — a map from transaction output index to the transient token content of that output. Any output index not appearing in the map is assumed to carry 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. Resolve each input using the combined value from both compartments.
2. Execute the transaction, including running any minting scripts, using the combined utxo values throughout.
3. Validate the transient token declarations:
   • The mint field may only reference transient policy IDs — minting or burning of L1-native tokens is not permitted.
   • For each input, the transient tokens it contributes must not exceed its transient-token compartment entry. No utxo may be debited more transient tokens than it holds.
   • For each output, the transient token content declared in transientOutputs must equal the transient tokens attributed to that output by conservation: input transient tokens minus burns plus mints, allocated across outputs as declared.
4. Post-process each output using the transientOutputs declaration:
   • The declared transient token content goes into the transient-token compartment, keyed by the output’s utxo ID.
   • The remainder of the output’s value goes into the main compartment.
5. Update the evacuation map to reflect changes to the main compartment only. Transient tokens never appear in the evacuation map.

This design resolves any ambiguity when an L1-native policy ID and a transient policy ID coincide: the transaction author explicitly declares which tokens in each output are transient, and post-processing does not need to infer compartment membership from policy IDs alone.

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. Because the scripts exist only within the head’s L2 ledger state, their policy IDs are distinct from any L1-native policy — in practice, no L1 policy would share a hash with an L2-only script.

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.