CIP-112: Guard Scripts

CIP-112  proposes a new primitive for Cardano native scripts: the ability to delegate a spending condition to a Plutus script. This allows a native script to say “this condition is satisfied if this Plutus script validates,” combining the simplicity and low cost of native scripts with the full expressive power of Plutus.

For Gummiworm, CIP-112 enables three significant improvements to the current design.

Eliminating Post-dated Transactions

The current design relies on two types of post-dated transactions: the fallback effect and refund effects. Both are pre-signed by the head peers and held in storage, to be submitted if consensus stalls or a deposit goes unabsorbed.

This is a structural liability. If all head peers simultaneously lose these transactions — through data corruption, a coordinated failure, or a prolonged outage — the funds they protect could become permanently stranded. The fallback transaction is particularly critical: without it, a stalled head cannot transition to the rules-based regime, leaving the main compartment locked indefinitely.

With CIP-112, the head’s native script gains two new alternative spending branches alongside the existing multisig branch. A utxo under the native script can be spent if any of these hold:

• It is multisigned by all head peers and a quorum of coil peers (the existing path).
• The fallback guard script validates successfully.
• The refund guard script validates successfully.

Fallback Guard Script

The fallback guard script replaces the pre-signed fallback transaction. It validates if all of these hold:

• Only the multisig treasury and multisig regime utxos are being spent.
• The transaction’s validity start is no earlier than the fallback deadline stored in the treasury’s datum.
• The transaction correctly sets up the ballot boxes for dispute resolution, and satisfies other miscellaneous correctness conditions.

Initialization and settlement effects are responsible for writing and updating the fallback deadline in the treasury’s datum, exactly as they do today with the post-dated transaction’s validity window. Settlement and finalization reset or cancel the deadline. The difference is that the guard script enforces the deadline mechanically — anyone can submit the fallback transition once it is due, with no pre-signed transaction required.

Refund Guard Script

The refund guard script replaces the pre-signed refund transaction. It validates if all of these hold:

• Only a single utxo — a deposit utxo — is being spent.
• Any one of these conditions holds:
  • The transaction’s validity start is no earlier than the refund deadline in the deposit’s datum (equivalent to the current behavior).
  • The transaction references the head’s rules-based regime utxo, which is created if and only if the head transitions to the rules-based regime.
  • A soft-confirmed block brief is presented as a witness, proving that the head peers decided to reject this specific deposit.
• The transaction correctly sends the deposit’s value (minus the refund transaction fee) to the address and datum specified in the refund instructions in the deposit’s datum.

The second and third conditions are meaningful improvements on the current design. Today, a depositor whose deposit was rejected — or whose head has already entered the rules-based regime — must wait out the full refund deadline before recovering their funds. With CIP-112, they can recover immediately by presenting the relevant on-chain evidence. No KZG or membership proof is required: for the rejection case, the depositor simply presents the soft-confirmed block brief, which already carries all head peer signatures, and the guard script verifies that the deposit’s request ID appears in the brief’s rejected deposits list.

Token Cleanup Without Peer Coordination

The head’s HYDR and VOTE tokens are minted under the head’s native script minting policy, which currently requires unanimous head peer and threshold coil peer consent to burn. In the rules-based regime — which exists precisely because consensus has broken down — coordinating this set of signatures may be difficult or impossible.

With CIP-112, a Plutus guard can allow these tokens to be burned without peer coordination, provided that:

• The tokens reside in the rule-based treasury, and
• The treasury’s KZG commitment is empty (all funds have been evacuated).

This makes the deinit transaction fully permissionless after a completed evacuation, ensuring the head can always be cleanly wound down.