Fragmented Treasury

The Gummiworm multisig treasury is a single utxo. Cardano imposes several constraints on what a single utxo can hold, all of which apply to the treasury:

1. Asset count. A single utxo can hold at most 256 distinct assets — assets with different policy IDs and/or asset names.

2. Transaction size. Cardano transactions are limited to 16 kilobytes. A utxo holding 256 distinct assets already exceeds this limit, which means it cannot be produced or reproduced by any transaction. In practice, the effective asset count ceiling for a treasury that must be updated by settlement transactions is considerably lower than 256.

3. Utxo size. Cardano’s ledger also directly limits the serialized size of a utxo’s value field via the MaxValSize protocol parameter, independent of the transaction size limit.

These constraints compound. A head whose treasury approaches the asset count or size ceiling loses the ability to construct valid settlement transactions and must evacuate instead. This is not merely a theoretical edge case for unusual heads — it is an operational constraint that any head managing a diverse portfolio of token types must actively account for.

Fragmentation design

The natural response is to split the treasury across multiple utxos, each holding a portion of the total value. One utxo — the primary treasury — retains the head’s HYDR beacon token and continues to serve as the anchor for the multisig regime. The remaining utxos are treasury fragments, each held at the same native script address and therefore under the same multisig custody.

In normal operation, settlement transactions can redistribute value between the primary treasury and the fragments as needed. A payout that draws on a token held in a fragment spends the fragment and reorganizes the remaining value; a deposit that introduces a new asset class creates a new fragment if the primary treasury is already at capacity.

The fallback challenge and CIP prerequisites

The main difficulty with a fragmented treasury is the fallback transition. In the current single-treasury design, the fallback transaction is fully specified in advance as a pre-signed post-dated transaction. Fragments break this: the fallback would need to spend all fragment utxos simultaneously, but the set of fragments changes as settlements are executed, so it cannot be pre-signed.

This is why fragmented treasury support on Cardano requires either CIP-112 or CIP-118 to be available on mainnet first.

With CIP-112, the pre-signed fallback transaction is replaced by a fallback guard script. The guard script validates the fallback transition dynamically at execution time, and can verify that all treasury fragments — identified by a fragment beacon token — are included in the transition. Anyone can submit the fallback once the deadline passes; the guard script does the work of ensuring every fragment is correctly moved to the rules-based regime. No pre-enumeration of fragments is required.

With CIP-118, Gummiworm’s multisigned effects can include Plutus sub-transaction validation, which similarly allows a script to check that all fragments are accounted for when a fallback or settlement is executed. This enables the same dynamic fragment enumeration within the existing multisig regime structure.

Either CIP makes the fragmented-treasury fallback as clean and permissionless as the single-treasury fallback is today.

The same challenge applies to governance migrations. When a membership change requires migrating the treasury to a new custody configuration, all fragments must be included in the migration effect alongside the primary treasury. CIP-112 or CIP-118 is equally a prerequisite there: Plutus validation can enumerate all fragments by their beacon token and verify they are all moved to the new custody.