CIP-118: Nested Transactions
CIP-118 proposes nested transactions for Cardano. A top-level transaction may contain sub-transactions; each sub-transaction need not be balanced on its own, but the batch as a whole must be. Sub-transactions do not provide fees or collateral — the top-level transaction supplies these on behalf of the entire batch.
For Gummiworm, CIP-118 enables three significant improvements to the current design.
Script Collateral
Gummiworm’s current design avoids Plutus scripts in the multisig regime entirely, due to a structural incompatibility with Cardano’s collateral mechanism.
When a Cardano transaction runs Plutus scripts, it must designate collateral utxos. If Plutus validation fails (phase-2 failure), the collateral is consumed in place of the transaction’s regular inputs. Cardano requires collateral utxos to reside at single-owner addresses — not at script addresses or multi-signature addresses.
This creates a problem for Gummiworm. If a multisigned effect such as a settlement transaction ran a Plutus script, it would need to designate collateral from some party’s single-key address. That party could spend the collateral utxo at any time before the transaction is submitted. Doing so would invalidate the transaction, forcing the head and coil peers to re-sign with fresh collateral. In other words, a single party could unilaterally veto any multisigned effect — a violation of a fundamental Gummiworm invariant: once the head and coil peers have multisigned an immediate effect, it must remain valid until it expires.
With CIP-118, Gummiworm’s multisigned effects can be structured as sub-transactions, which carry no collateral requirement. The top-level transaction that packages the sub-transactions supplies all collateral. If that collateral utxo is spent, anyone can repackage the same multisigned sub-transactions into a new top-level transaction with different collateral. The multisigned effects themselves remain unchanged and valid.
This makes it safe to use Plutus scripts in the multisig regime, which in turn enables the improvements described in the following sections.
Atomic Authorization of Block Stack Effects
The current slow-consensus protocol uses a two-round signing scheme to prevent a malicious coalition of peers from selectively withholding signatures — for example, signing a settlement effect while refusing to sign the paired fallback effect, which could strand the treasury if subsequent effects expire before execution.
The two-round scheme is a workaround. Peers must sign all necessary effects except the settlement or finalization effect in the first round, wait for a quorum, and only then release signatures for the settlement or finalization effect in the second round. This adds latency to each block stack and places a coordination burden on every peer.
With Plutus scripts available in the multisig regime, a cleaner solution becomes possible. Instead of multisigning each individual transaction in a block stack separately, the peers multisign a single redeemer that authorizes the entire set of effects for the block stack at once. A Plutus script verifies that the sub-transactions in the batch correspond exactly to the effects authorized by the redeemer, and rejects the batch if any required effect is missing or any unauthorized effect is present.
This makes the authorization of an entire block stack’s effects genuinely atomic: the batch either executes in full or not at all. The two-round signing protocol is no longer needed.
A further benefit: slow consensus now produces only one multi-signature per block stack, rather than one per necessary effect. A block stack can contain many necessary effects — multiple standalone evacuation commitments, a settlement, a fallback, several rollouts — each of which previously required its own round of signature collection. Collapsing these into a single redeemer signature significantly reduces the network traffic between head and coil peers during slow consensus.
Advanced Multi-Signature Schemes
With Plutus scripts available, Gummiworm can adopt more advanced cryptographic multi-signature schemes in place of the current approach. A promising candidate is the BLS-based Accountable Multi-Signature with Constant Size Public Keys scheme by Boneh, Partap, and Waters (BPW23 ), which is compatible with Cardano’s BLS12-381 support and offers three significant benefits.
Accountability. The scheme provides a Trace function: given an aggregate signature s, Trace(m, s) deterministically recovers the exact set of peers J that produced it. This makes it possible to identify coil peers who withheld their signatures, enabling Gummiworm to hold them accountable and align incentives for participation.
Incremental aggregation. Peers do not need to broadcast individual signatures to every other peer. Instead, a peer can attach her signature to any partial aggregate and pass it on; partial aggregates can be merged progressively until a quorum is reached. Only the aggregator needs the public aggregation key pkc, which has linear size in the number of peers.
Efficient onchain verification. After a one-time KeyAgg computation over all peers’ public keys, the verifier only needs to store a constant-size verification key vk — a single group element. The on-chain Plutus script uses only vk to verify any aggregate signature from any quorum, regardless of the quorum size. Verification cost scales with the number of signers at under 0.01 ms per signature off-chain.
Plutus vs. Native Scripts
The improvements described in this article rely on Plutus scripts throughout the multisig regime. An alternative path — described in the CIP-112 article — keeps native scripts as the foundation and adds Plutus guard branches only for specific conditions. These two paths carry different cost profiles:
- Native scripts have zero script execution cost and tend to produce smaller transactions, since native script evaluation is lightweight.
- Plutus scripts incur script execution costs, but the benefits — genuine atomicity, a single multi-signature per block stack, advanced multi-signature schemes, and reduced signing complexity — may outweigh the savings from native scripts.
It is not yet determined which approach will prevail. The two articles should be read as complementary explorations of the design space rather than competing proposals.