L2 interoperability with HTLC

As the Cardano ecosystem develops multiple complementary Layer 2 solutions, user experience risks fragmentation: each L2 has different finality characteristics, fee structures, and native user bases, and users should not need to choose between them at the cost of being isolated from the others. Interoperability lets each L2 specialize in what it does best while allowing users and funds to move freely between them.

The hashed timelock contract (HTLC) is the practical universal mechanism for this.

Hashed timelock contract

An HTLC is a script that holds funds subject to two conditions:

• Redeem: before the expiry time, funds can be sent to the target address if the correct secret (matching a pre-committed hash) is revealed.
• Refund: after the expiry time, funds return to the refund address.

Every utxo at the HTLC address carries a datum specifying the expiry time, the secret hash, the target address, and the refund address.

HTLC transfer

To transfer funds from ledger A to ledger B, Alice (sender) and Bob (recipient) use Charlie as an intermediary who holds funds on both ledgers:

1. Alice locks funds at the HTLC address on ledger A targeting Charlie, using Bob’s secret hash.
2. Charlie, seeing this confirmed, locks equivalent funds on ledger B targeting Bob with the same hash and a slightly earlier expiry.
3. Bob redeems Charlie’s HTLC by revealing his secret.
4. Charlie uses that revealed secret to redeem Alice’s HTLC on ledger A.

If either fails to redeem before expiry, they refund. Assuming the parties are vigilant and both ledgers fully enforce their rules, either all HTLCs are redeemed or all are refunded. Charlie may charge a fee by locking slightly less than Alice’s amount in his HTLC for Bob.

HTLC atomic swap

An atomic swap is an HTLC transfer where the sender and recipient are the same person — effectively exchanging assets between two ledgers. If Alice is both sender and recipient in the above construction, she ends up with Charlie’s funds on ledger B and Charlie ends up with Alice’s funds on ledger A. The same mechanism supports cross-asset swaps: Alice could lock BTC on the Bitcoin ledger while Charlie locks ADA on Cardano.

HTLC in the EUTXO model

Cardano’s EUTXO model makes HTLCs more expressive than in account-based systems. Addresses can be script-based, and utxos can carry datums, so any party in an HTLC — sender, recipient, or intermediary — can be a smart contract or smart wallet rather than a plain public key. This means Alice can transfer funds directly into a dApp on ledger B via an HTLC, without a pubkey-based intermediary holding custody during the transfer. It also means dApps can initiate HTLC transfers, with refunds returning to the dApp’s address with an appropriate datum for further processing.

Midgard

Midgard is Cardano’s first optimistic rollup. It achieves massive throughput by keeping only fixed-size block headers on-chain while processing full transaction blocks off-chain, with a fraud-proof mechanism that lets anyone detect, punish, and remove invalid blocks. This makes Midgard a natural host for large-userbase applications like AMM DEXs, where a state channel’s small multisig group would be an inadequate custodian.

Midgard’s main disadvantage relative to state channel protocols is its block maturity period — expected to be several days — which is fundamental to its design: the window is what gives fraud proofs time to be submitted. Deposits are recognized as soon as a block header referencing them is committed to the state queue, but withdrawals to L1 are only settled after the relevant header has matured. By contrast, Gummiworm can settle withdrawals with immediate finality upon multi-signature, which gives Midgard a strong incentive to interoperate with it.

Expedited Midgard withdrawals

Midgard users can bypass the settlement delay by using HTLC atomic swaps.

Suppose Marie wants to withdraw ADA from Midgard to Cardano, and Lucas is willing to exchange his ADA on Cardano for Marie’s ADA on Midgard:

1. Marie locks ADA in an HTLC on Midgard targeting Lucas.
2. Lucas sees Marie’s HTLC included in a block header committed to Midgard’s state queue. As long as that header and its predecessors are valid and the block commitment transaction is confirmed on L1, Marie’s HTLC will not be rolled back — so Lucas locks ADA in an HTLC on Cardano L1 targeting Marie.
3. Marie redeems Lucas’ L1 HTLC, revealing her secret.
4. Lucas uses that secret to redeem Marie’s Midgard HTLC.

This avoids the maturity delay but has two disadvantages: Lucas’ L1 funding transaction must be confirmed on Cardano (which can take a while under congestion), and both sides of the swap incur L1 fees.

Midgard and a Gummiworm head

If both Marie and Lucas are peers of the same Gummiworm head, the swap can run between Midgard and the head instead. Lucas’ side of the HTLC is set up on Gummiworm: it appears in a multi-signed snapshot within seconds, giving Marie fast confirmation with no L1 fees. After redeeming her ADA on Gummiworm, Marie can transact freely with any other peers of the head, or withdraw to Cardano L1 — where Gummiworm settlements batch multiple withdrawals into a single transaction with no script execution overhead.

Midgard and a Gummiworm network

If Marie and Lucas are not peers of the same Gummiworm head, the Gummiworm network can route the swap across multiple heads. A four-hop example using Marie’s secret hash:

• HTLC from Marie to Lucas on Midgard
• HTLC from Lucas to Nancy on head 1
• HTLC from Nancy to Oscar on head 2
• HTLC from Oscar to Marie on head 3

Each Gummiworm-side HTLC is confirmed by a multi-signed snapshot rather than an L1 transaction, so even multi-hop routes typically complete within a minute, sometimes within milliseconds. Marie receives funds in whichever head she is a peer of, and can proceed from there. The intermediaries (Lucas, Nancy, Oscar) facilitate the transfer without incurring L1 fees and can collect routing fees by locking slightly less than they receive at each hop.

Gummiworm network

A network of Gummiworm heads can be routed much like Bitcoin Lightning, but with a structural advantage: Gummiworm heads are multi-party channels. In a three-peer head where Alice, Charlie, and Oscar each hold 100 ADA, Alice has 200 ADA of inbound capacity and can route 100 ADA outbound in any split between Charlie and Oscar. Three two-party Lightning channels would be needed to provide comparable capacity, with each peer depositing twice the ADA. For a four-party head, the equivalent would be six Lightning channels with each peer depositing three times as much.

Pooled inbound and outbound capacity across multi-party heads should improve both the reliability and cost of routed transfers.

The network topology is likely to be more stable than Lightning’s. A Gummiworm peer who exhausts their balance in a head does not disrupt the other peers — they can continue transacting without disruption as long as the depleted peer continues to respond. The depleted peer can also request to deposit more funds or leave the head without disrupting the others. This gives the Gummiworm network a more persistent backbone.

The cost of larger heads is coordination overhead: peer-to-peer communication scales quadratically with head size, and a single non-responding peer can stall consensus. Each peer will find their preferred head size based on their own resources and their assessment of co-peers’ reliability. This naturally limits centralization around excessively large heads.

Bitcoin interoperability

HTLC atomic swaps between the Gummiworm and Lightning networks are facilitated by liquidity providers who operate nodes in both. Suppose Ursula holds ADA in the Gummiworm network and wants to send BTC to Walter on Lightning. Victor holds ADA in the Gummiworm network and BTC in the Lightning network and is willing to exchange them at a quoted rate. Ursula’s transfer routes ADA to Victor via Gummiworm, which Victor converts into BTC on Lightning and routes to Walter.

With multiple providers quoting rates at the Gummiworm/Lightning boundary, a routing algorithm can optimize jointly over exchange rate, routing fee, and success probability. Rates should track the global BTC/ADA market closely, since providers can update them quickly and arbitrageurs can trade against mismatches.

Beyond this simple atomic swap mechanism, there are many promising design possibilities to explore. Lightning routing suffers from a fundamental uncertainty: channels publish only their total capacity, not individual peer balances, which change with every transfer and are often unbalanced. Alice must find a route to Bob by trial and error, and success probability drops with transfer amount and number of hops. The network consequently tends to centralize around well-connected hubs.

If BTC can be appropriately wrapped on the Cardano/Gummiworm ledger, Gummiworm’s multi-party channel routing improvements — pooled capacity, more stable topology — can be applied to paths between Lightning nodes, potentially improving reliability and reducing fees across the Lightning network itself.

Standardization

For L2 interoperability to deliver on its UX promise, the underlying mechanisms need to be standardized across implementations: L2-L2 HTLC transfers, L2 state queries, and wallet integration. Standardizing these interfaces would allow any L2 that supports HTLCs — including non-Cardano L2s and external chains like Bitcoin — to participate in the same interoperability fabric.