Hydra: Fast Isomorphic State Channels

Manuel M. T. Chakravarty1 , Sandro Coretti1 , Matthias Fitzi1 , Peter Gaži1 , Philipp Kant1 ,
Aggelos Kiayias2 , and Alexander Russell3
1
IOHK. [email protected].
2
University of Edinburgh and IOHK. [email protected].
3
University of Connecticut and IOHK. [email protected].

Abstract
State channels are an attractive layer-two solution for improving the throughput and latency
of blockchains. They offer optimistic fast offchain settlement of payments and rapid offchain evo-
lution of smart contracts between multiple parties without imposing any additional assumptions
beyond those of the underlying blockchain. In the case of disputes, or if a party fails to respond,
cryptographic evidence collected in the offchain channel is used to settle the last confirmed state
onchain, such that in-progress contracts can be continued under mainchain consensus. A serious
disadvantage present in current layer-two state channel protocols is that existing layer-one smart
contract infrastructure and contract code cannot be reused offchain without change.
In this paper, we introduce Hydra, an isomorphic multi-party state channel. Hydra simplifies
offchain protocol and contract development by directly adopting the layer-one smart contract
system. We present the onchain contracts to open and close Hydra heads (our isomorphic
state channels) and a novel offchain protocol for fast evolution of heads. We establish strong
security properties for the protocol, and we present and evaluate extensive simulation results that
demonstrate that Hydra approaches the physical limits of the network in terms of transaction
confirmation time and throughput while keeping storage requirements at the lowest possible.

1 Introduction
Permissionless distributed ledger protocols suffer from serious scalability limitations, including high
transaction latency (the time required to settle a transaction), low throughput (the number of
transactions that can be settled per unit of time), and excessive storage required to maintain the
state of the system and its transaction history, which can be ever growing.
Several solutions have been proposed to mitigate these problems by adapting the details of the
underlying ledger protocols. Such direct adaptations for scalability are often referred to as layer-one
solutions.
Layer-one solutions face an inherent limitation, however, as settlement remains a cumbersome
process that involves the participation of a large, dynamic set of participants and requires exchange
of significant amounts of data. An alternative approach to improve scalability, which is our emphasis
in this work, is layer-two (sometimes referred to also as offchain) solutions that overlay a new
protocol on top of the (layer-one) blockchain. Layer-two solutions allow parties to securely transfer
funds from the blockchain into an offchain protocol instance, settle transactions in this instance

1
(quasi) independently of the underlying chain, and safely transfer funds back to the underlying
chain as needed.
Offchain solutions have the advantage that they do not require additional trust assumptions
about the honesty of parties beyond those of the underlying blockchain, and that they can be very
efficient in the optimistic case where all participants in the offchain protocol instance behave as
expected. In particular, such an instance operates among a small number of parties that commu-
nicate with each other directly, and in a way that allows them to forget about recent transactions
as soon as they respectively update (and secure) their local states.
The most prominent offchain scalability solution is the concept of payment channels [9, 31, 15].
A payment channel is established among two parties, allowing them to pay funds back and forth
on this channel; in the optimistic case, this can take place without notifying the layer-one protocol.
Payment channels have been extended to payment-channel networks, e.g., the Bitcoin Lightning
Network [31]. Such networks, in principle, allow for offchain fund transfers among any two parties
that are connected via a path of payment channels.
As a drawback, in a traditional payment-channel network a transaction between two parties
that do not share a direct payment channel requires interaction among all parties on a payment-
channel path between them (so-called intermediaries), even in the optimistic case. Virtual payment
channels, e.g., Perun [17], address this and do not require interaction with intermediate parties (in
the optimistic case).
State channels [5] extend the concept of payment channels to states in order to support smart
contracts. State-channel networks [19, 14, 27] likewise extend the concept of state channels to
networks (analogously to the network extension discussed above). Still, these networks only allow
for the establishment of pairwise state channels over the network.
Multi-party state channels were introduced in [29] together with a high-level description of a
respective protocol. A multi-party state channel allows a set of parties to maintain a “common”
state whereon they can compute without interacting with the blockchain (in the optimistic case).
In [16], the notion of multi-party virtual state channels was introduced, state channels among
multiple parties that can be setup without blockchain interaction (given that a connected graph of
pairwise state channels among the parties already exists); and a respective protocol was presented.
While multi-party state channels offer the full generality of arbitrary smart contracts with
arbitrary groups of participants, they introduce significant conceptual and engineering overhead
beyond layer-one solutions: the contract state must be verified in a non-native representation.
More precisely, the state of the contracts evolved in a specific state channel needs to be isolated
and represented in a form that permits it to be manipulated both offchain and by the onchain
smart contract scripting system in case of an offchain dispute. This implies that it is no longer
in the representation used by the ledger itself; i.e., it is non-native. For example, the sample
Solidity contract of [29] serializes the state into a bytes32 array. The smart contracts themselves
need to be adapted correspondingly. In other words, the scripting system of the ledger and of
state channels attached to the ledger diverge in a substantial way, effectively imposing two distinct
scripting systems.

Hydra. In Hydra, we solve this problem with the introduction of isomorphic multi-party state
channels. These are state channels that reuse the exact state representation of the underlying
ledger and, hence, inherit the ledger’s scripting system as well. Thus, state channels effectively
yield parallel, offchain ledger siblings, which we call heads—the ledger becomes multi-headed. The

2
creation of a new head follows a similar commitment scheme as is common in state channels.
However, once a state channel is closed, either cooperatively or due to a dispute, the head state
is seamlessly absorbed into the underlying ledger state and the same smart contract code as used
offchain is now used onchain. This is possible, even without a priori registration of the contracts
used in a head, because one and the same state representation and contract (binary) code is used
offchain and onchain.
Not every blockchain scripting system is conducive to isomorphic state channels. Building them
requires to efficiently carve out arbitrary chunks of blockchain state, process them independently,
and be able at any time to efficiently merge them back in. We observe that the Bitcoin-style UTxO
ledger model [6, 32] is particularly well suited as a uniform representation of onchain and offchain
state, while simultaneously promising increased parallelism in transaction processing inside multi-
party state channels. While the main restriction of the plain UTxO model has traditionally been its
limited scripting capabilities, the recent introduction of the Extended UTxO model (EUTxO) [13]
has lifted this restriction and enabled support for general state machines.
Just like the UTxO ledger representation, the EUTxO ledger representation makes all data
dependencies explicitly without introducing false dependencies — in other words, two transactions
do only directly or indirectly depend on each other if there is an actual data dependency between
them. This avoids the over-sequentialization of systems depending on a global state. Hence, the
length of the longest path through the EUTxO graph coincides with the depth complexity of the
workload entailed by transaction processing and validation. This is the optimum as far as parallel
transaction processing is concerned [10].
On the basis of these observations, we specify the mainchain portion of the Hydra protocol,
which handles multi-party commitments and settlement to the mainchain, in the form of a EUTxO
state machine and we use the parallelism exposed by the EUTxO graph to implement a parallel
offchain protocol.
Overall, in Hydra, a set of parties coordinates to commit a set of UTxOs (owned by the parties)
into an offchain protocol, called the head protocol. That UTxO set constitutes the initial head state,
which the parties can then evolve by handling smart contracts and transactions among themselves
without blockchain interaction—in the optimistic case. Due to the isomorphic nature of Hydra
heads, transaction validation, including script execution, proceeds according to the exact same
rules as onchain. In fact, the exact same validation code can be used. This guarantees that onchain
and offchain semantics coincide, leading to significant engineering simplifications.
In case of disputes or in case some party wishes to terminate the offchain protocol, the parties
decommit the current state of the head back to the blockchain. Ultimately, a decommit will result
in an updated blockchain state that is consistent with the offchain protocol evolution on the initially
committed UTxO set. In order to reduce mainchain overhead, the mainchain is oblivious of the
detailed transaction history of the head protocol that lead to the updated state. Crucially, the time
required to decommit is independent of the number of parties participating in a head or the size
of the head state. Moreover, the decommit process is designed in such a way that when the latest
state in the head is very large, the head state can be decommitted in small (but parallel) chunks.
Finally, Hydra also allows incremental commits and decommits, i.e., UTxOs can be added to and
removed from a running head without closing it.
Cross-head networking. In this paper, we focus solely on the analysis of the Hydra head protocol;
nevertheless, the existence of multiple, partially overlapping heads off the mainchain can give rise to
cross-head communication (as in the Lightning Network [31]), using similar techniques to [19, 16].

3
 Experimental results. We conducted detailed simulations of head performance under a variety
of load and networking scenarios, including both geographically localized heads and heads with
participants spread over multiple continents, incurring large network delays. We found that our
head protocol, in the optimistic case, achieves progress that rivals the speed and throughput of
the network in all configurations; this is aided by the concurrency afforded by the partial-only
transaction ordering permitted by the graph-structure underlying UTxO ledgers. Moreover, the
storage required by the protocol for the participating nodes is maintained at the lowest level possible
via a snapshot “garbage collection” mechanism that incurs only a marginal overhead.

Comparison to previous work. A number of previous works study state channel protocols.
The protocol by Miller et al. [29] allows a set of parties to initiate a smart contract instance (state)
onchain and take it offchain. The state can then be evolved offchain without chain interaction in the
all-honest case. By concurrently handling disputes in a shared contract, dispute resolution remains
in O(∆) time, where ∆ is the settlement time for an onchain transaction. The offchain protocol
proceeds in phases of 4 asynchronous rounds where a leader coordinates the confirmation of new
transactions among the participants in the offchain protocol. Similarly to Hydra, the protocol
allows to add/remove funds from the offchain contract while it is running.
The protocol by Dziembowski et al. [16] is based on pairwise state channels and allows the
instantiation of a multi-party state channel among any set of parties that are connected by paths
of pairwise state channels—the instantiation of the multi-party channel does not require any inter-
action with the mainchain. The offchain protocol proceeds in phases of 4 synchronous rounds to
confirm new transactions without the need for a coordinating leader.
The Hydra offchain protocol is fully asynchronous; in the optimistic case, transactions are
confirmed in 3 (asynchronous) rounds independently of each other, and without having to involve a
leader. A leader is only required for the resolution of transaction conflicts and for periodic “garbage
collection” that allows the protocol to maintain state size independent of the size of the transaction
history.
In comparison to prior solutions cited above, Hydra provides faster confirmation times in the
offchain protocol; this is an advantage enabled by the structural organization of transactions in
the EUTxO model, whereas prior protocols are hindered by a monolithic state organization. An
additional advantage over [29] and [16] is that those fix the set of contracts that can be evolved in a
given state channel at channel creation time; Hydra does not require such an a priori commitment:
new contracts can be introduced in a head after creation in the native EUTxO language of the
underlying blockchain. Another significant difference to [16] is that their protocol calls for parties
to lock funds on the mainchain on behalf of other parties—caused by asymmetries induced by
the composition along paths of pairwise state channels, whereas in Hydra as well as in [29], the
parties only need to lock funds on behalf of themselves. Finally, Hydra is isomorphic and thus
reuses the existing smart contract system and code for offchain computations. This is not the case
for [29] and [16]. For example, if we consider the sample Solidity contract of [29], it would have
to implement a state machine capable of executing EVM bytecode to achieve contract (system)
reuse—and hence, isomorphic state channels.
We note that there is also a large number of non-peer reviewed proposals for state-channel-based
solutions such as [26, 14, 27, 3]. These proposals come with various degrees of formal specification
and provable security guarantees and their systematization is outside of our current scope; it suffices
to observe that none of them provides the isomorphism property or comes with a complete formal

4
security analysis and an experimental evaluation.
Two concepts related, but distinct, from state channels are sidechains (e.g., [7, 22, 24]) and non-
custodial chains (e.g., [30, 25, 18, 4]), including plasma and rollups. Sidechains enable the transfer of
assets between a mainchain and a sidechain via a pegging mechanism, with the mainchain protected
from sidechain security failures by a “firewall property”; the sidechain has its own consensus rules
and, contrary to a state channel, funds may be lost in case of a sidechain security collapse. Non-
custodial chains, on the other hand, delegate mainchain transaction processing to an untrusted
aggregator and are capable, as in state channels, to protect against a security failure. Nevertheless,
the aggregator is a single-point-of-failure and its corruption, in a setting where a large number
users are served by the same non-custodial chain, gives rise to the “mass-exit” problem (see e.g.,
[18]); note that state channels, in contrast, can scale to a large number of users via state channel
networks [19] without requiring many users per channel. We note finally that work in progress on
optimistic rollups, reported in [4], claims a feature similar to our isomorphic property, nevertheless
without the latency benefits of our approach as their settlement still advances with the underlying
mainchain.

2 Preliminaries
2.1 Multisignatures
A multisignature scheme [23, 28] is a tuple of algorithms MS = (MS-Setup, MS-KG, MS-AVK,
MS-Sign, MS-ASig, MS-Verify) such that Π ← MS-Setup(1k ) generates public parameters; with these
in place, (vk, sk) ← MS-KG(Π) can be used to generate fresh key pairs. Then

• σ ← MS-Sign(Π, sk, m) signs a message m using key sk;

• σ̃ ← MS-ASig(Π, m, V, S) aggregates a set S of signatures into a single, aggregate signature σ̃.

The algorithm avk ← MS-AVK(Π, V) aggregates a tuple V of verification keys vk into a single, aggre-
gate verification key avk which can be used for verification: MS-Verify(Π, avk, m, σ̃) ∈ {true, false}
verifies an aggregate signature under an aggregate verification key. In the following, we often make
the parameter Π implicit in the function calls for better readability.
Intuitively, the security of a multisignature scheme guarantees that, if avk is produced from
a tuple of verification keys V via MS-AVK, then no aggregate signature σ̃ can pass verification
MS-Verify(avk, m, σ̃) unless all honest parties holding keys in V signed m. A full treatment appears
in Appendix A.

2.2 Extended UTxO model & state machines

The basis for our fast isomorphic state channels is Bitcoin’s UTxO ledger model [6, 32]. It arranges
transactions in a directed acyclic graph structure, thus making the available parallelism explicit:
any two transactions that are not directly or indirectly dependent on each other can be processed
independently.

Extended UTxO. The Extended UTxO Model (EUTxO) [13] preserves this structure, while
adding support for more expressive smart contracts and, in particular, for multi-transaction state
machines, which serve as the basis for the mainchain portion of our work presented here. In

5
addition to the basic EUTxO extension, we generalize the currency values recorded on the ledger
to generalized user-defined tokens [1]. Put simply (sufficient to understand the concepts in this
paper), values are sets that keep track how many units of which tokens of which currency are
available. For example, the value {Coin 7→ {Coin 7→ 3}, c 7→ {t1 7→ 1, t2 7→ 1}} contains 3 Coin coins
(there is only one (fungible) token Coin for a payment currency Coin), as well as (non-fungible)
tokens t1 and t2 , which are both of currency c. Values can be added naturally, e.g.,

{Coin 7→ {Coin 7→ 3}, c 7→ {t1 7→ 1, t2 7→ 1}}

+ {Coin 7→ {Coin 7→ 1}, c 7→ {t3 7→ 1}}
= {Coin 7→ {Coin 7→ 4}, c 7→ {t1 7→ 1, t2 7→ 1, t3 7→ 1}} .

In the following, ∅ is the empty value, and {t1 , . . . , tn } :: c is used as a shorthand for {c 7→ {t1 7→
1, . . . , tn 7→ 1}}.
The EUTxO ledger consists of transactions: Transactions are quintuples tx = (I, O, valForge , r, K)
comprising a set of inputs I, a list of outputs O, values of forged/burned tokens valForge , a slot range
r = (rmin , rmax ), and a set of public keys K. Each input i ∈ I is a pair of output reference out-ref
(consisting of a transaction ID and an index identifying an output in the transaction) and redeemer
ρ (used to supply data used for validation). Each output o ∈ O is a triple (val, ν, δ) of a value val,
a validator script ν, and a data value δ. The slot range r fixes the slots within which tx may be
confirmed, and, finally, K are the public keys under which tx is signed.
In order to validate a transaction tx with input set I, for each output o = (val, ν, δ) referenced
by an i = (out-ref, ρ) ∈ I, the corresponding validator ν is run on the following inputs (called
context): ν(val, δ, ρ, txpend ), where txpend consists of tx and all outputs referenced by some i ∈ I
(not just o). Ultimately, tx is valid if and only if all validators return true.

State Machines. A convenient abstraction for EUTxO smart contracts spanning a sequence of
related transactions are state machines. We are specifically using constraint emitting machines
(CEMs) [13]. They are based on Mealy machines and consist of a set of states Scem , a set of inputs
i
Icem , a predicate final cem : Scem → Bool identifying final states, and a step relation s −→ (s0 , tx≡ ),
which takes a state s on an input i to a successor state s0 under the requirements that the constraints
tx≡ are satisfied.
We implement CEMs on a EUTxO ledger (the mainchain) by representing a sequence of CEM
states as a sequence of transactions. Each of these transactions has got a state-machine input icem
and a state-machine output ocem , where the latter is locked by a validator νcem , implementing the
step relation. The only exceptions are the initial and final state, which have got no state-machine
input and output, respectively.
More specifically, given two transactions tx and tx0 , they represent successive states under
i
s −→ (s0 , tx≡ ) iff

• state-machine output ocem = (val, νcem , s) of tx is consumed by the state-machine input

i0cem = (out-ref, ρ) of tx0 , whose redeemer is ρ = i (i.e., the redeemer provides the state-
machine input) and
• either final cem (s0 ) = true and tx0 has no state-machine output, or o0cem = (val0 , νcem , s0 ) and
tx0 meets all constraints imposed by tx≡ .

6
 i
s s′
𝗏𝖺𝗅 ρ̃ 𝗏𝖺𝗅′

⋮ ⋮ ⋮ ⋮

i
Figure 1: Transactions representing successive states in a CEM transition relation s −→
(s0 , tx≡ ). Fields val and val0 are the value fields of the state-machine outputs and ρ̃ is the
additional data.

Sometimes it is useful to have additional data ρ̃ provided as part of the redeemer, i.e., ρ = (i, ρ̃).
A state transition of the described type is represented by two connected transactions as shown in
Fig. 1. For simplicity, state-machine inputs(s, and
i) ↦ (s′, tx≡) are not shown, with the exception of the
outputs
value fields val and val0 of the state-machine output.

3 Protocol Overview
The Hydra protocol provides functionality to lock a set of UTxOs on a blockchain, referred to as
the mainchain, and evolve it inside a so-called offchain head, independently of the mainchain. At
any point, the head can be closed with the effect that the locked set of UTxOs on the mainchain
is replaced by the latest set of UTxOs inside the head. The protocol guarantees full wealth preser-
vation: no generation of funds can happen offchain, and no responsive honest party involved in a
head can ever lose any funds other than by consenting to give them away.
The advantage of head evolution from a liveness viewpoint is that, under good conditions, it
can essentially proceed at network speed, thereby reducing latency and increasing throughput in
an optimal way. At the same time, the head protocol provides the same smart-contract capabilities
as the mainchain.
To avoid overloading with technical details, the main body of the paper presents a simplified
version of Hydra to convey the basic concepts and ideas of the new protocol. Also in the overview,
we focus on the simplified protocol and outline the differences of the full protocol in Section 3.4. A
detailed description of the simplified protocol is given in Sections 4– 6, and Appendix B. The full
protocol is described in Appendix C.

3.1 The big picture

To create a head-protocol instance, any party may take the role of an initiator and ask a set parties
(including himself), the head members, to participate in the head by announcing the identities of
the parties.
Each party then establishes pairwise authenticated channels to all other parties–or aborts the
protocol setup, if this is not possible.1
1
But we generally assume that mechanisms for establishing pairwise authenticated channels are in place, e.g., by
means of a public-key infrastructure.

7
 The parties then exchange, via the pairwise authenticated channels, some public-key material.
This public-key material is used both, for the authentication of head-related onchain transactions
that are restricted to head members (e.g., a non-member is not allowed to close the head), and for
multisignature-based event confirmation in the head.
The initiator then establishes the head by submitting an initial transaction to the mainchain
that contains the head parameters and forges special participation tokens identifying the head
members by assigning each token to the public key distributed by the respective party during the
the setup phase. The initial transaction also initializes a state machine (see Fig. 2) for the head
instance that manages the “transfer” of UTxOs between mainchain and head.
Once the initial transaction appears on the mainchain, establishing the initial state initial, each
head member can attach a commit transaction, which locks (on the mainchain) the UTxOs that
the party wants to commit to the head.
The commit transactions are subsequently collected by the collectCom transaction causing a
transition from initial to open. Once the open state is confirmed, the head members start running
the offchain head protocol, which evolves the initial UTxO set (the union over all UTxOs committed
by all head members) independently of the mainchain. For the case where some head members fail
to post a commit transaction, the head can be aborted by going directly from initial to final.
The head protocol is designed to allow any head member at any point in time to produce,
without interaction, a certificate for the current head UTxO set. Using this certificate, the head
member may advance the state machine to the closed state.
Once in closed, the state machine grants parties a contestation period, during which each party
may (one single time) contest the closure by providing the certificate for a newer head UTxO
set. Contesting leads back to the state closed. After the contestation period has elapsed, the
state machine may proceed to the final state. The state machine enforces that the outputs of the
transaction leading to final correspond exactly to the latest UTxO set seen during the contestation
period.

3.2 The mainchain state machine

The mainchain part of the Hydra protocol fulfills two principal functions: (1) it locks the mainchain
UTxOs committed to the head while the head is active and (2) it facilitates the settlement of the
final head state back to the mainchain after the head is closed. In combination, these two functions
effectively result in replacing the initial head UTxO set by the final head UTxO set on the mainchain
in a manner that respects but does not persist the complete set of head transactions.
The state machine (Fig. 2) implementing the mainchain protocol comprises the four states
initial, open, closed, and final, where the first two realize the first function (locking the initial UTxO
set) and the second two realize the second function (settling the final UTxO set on the mainchain).
State machines inherently sequentialize all actions that involve the machine state. This simplifies
both reasoning about and implementing the protocol. However, steps that could otherwise be taken
in parallel now need to be sequentialized, which might hurt performance. For the cases where this
sequentialization would severely affect protocol performance, we employ a (to our knowledge) novel
technique to parallelize the progression of the state machine on the mainchain.
We use this technique to parallelize the construction of the initial UTxO set of the head.
Without parallelization, all n head members would have to post their commit transactions (their
portion of the initial UTxO set) in sequence, requiring a linear chain of n transactions, each
for one state transition at a time. Instead, we make the state machine consume all n commit

8
 Figure 2: Mainchain state diagram for the simple version of the Hydra protocol.

transactions in a single state transition. In Fig. 2, we represent this in the following way: the
transaction representing state initial connects to the transaction representing state open not just
via the collectCom state transition, but also via a set of commit transactions (one for each head
member).
This requires some extra care. We want to ensure that each head member posts exactly one
commit transaction and that the open transaction faithfully collects all commit transactions. We
gain this assurance by issuing a single non-fungible token to each head member—we call this the
participation token. This token must flow through the commit transaction of the respective head
member and the open transaction, to be valid, must collect the full set of participation tokens. We
may regard the participation token as representing a capability and obligation to participate in the
head protocol.

3.3 The head protocol

The head protocol starts with an initial set U0 of UTxOs that is identical to the UTxOs locked
onchain.

Transactions and local UTxO state. The protocol confirms individual transactions in full
concurrency by collecting and distributing multisignatures on each issued transaction separately.
As soon as such a transaction is confirmed, it irreversibly becomes part of the head UTxO state
evolution—the transaction’s outputs are immediately spendable in the head, or can be safely trans-
ferred back onchain in case of a head closure.
Each party maintains their view of the local UTxO state L, which represents the current set of
UTxOs evolved from the initial UTxO set U0 by applying all transaction that have been confirmed
so far in the head. As the protocol is asynchronous the parties’ views of the local UTxO state
generally differ.

Snapshots. The above transaction handling would be enough to evolve the head state. However,
an eventual onchain decommit would have to transfer the full transaction history onchain as there
would be no other way to evidence the correctness of the UTxO set to be restored onchain.

9
 To minimize local storage requirements and allow for an onchain decommit that is independent
of the transaction history, UTxO snapshots U1 , U2 , . . . are continuously generated. For this, a
snapshot leader requests his view of the confirmed state L to be multisigned as a new snapshot—
the first head snapshot corresponding to the initial state U0 . A snapshot is considered confirmed if
it is associated with a valid multisignature.
In contrast to transactions, the snapshots are generated sequentially. To have the new snapshot
Ui+1 = L multisigned, the leader does not need to send his local state Ui+1 , but only indicate, by
hashes, the set of (confirmed) transactions to be applied to Ui in order to obtain Ui+1 .
The other participants sign the snapshot as soon as they have (also) seen the transactions
confirmed that are to be processed on top of its predecessor snapshot: a party’s confirmed state is
always ahead of the latest confirmed snapshot.
As soon as a snapshot is seen confirmed, a participant can safely delete all transactions that
have already been processed into it as the snapshot’s multisignature is now evidence that this state
once existed during the head evolution.

Closing the head. A party that wants to close the head decommits his confirmed state L by
posting, onchain, the latest seen confirmed snapshot U` together with those confirmed transactions
that have not yet been processed by this snapshot. During the subsequent contestation period,
other head members can post their own local confirmed states onchain.

Transaction throttling. An adversarial leader could stall the snapshot production while still
allowing new transactions to get confirmed. To prevent that such an attack grows the stored
transaction history beyond limits, the size of all snapshot-unprocessed transactions may only grow
to a given limit. As long as this limit is reached, no new transactions are confirmed (or, alternatively,
the head is closed once the limit is reached).

3.4 The full protocol

To improve on the basic protocol, we change the mainchain state machine (as described in Ap-
pendix C) to include

• incremental commits and decommits (adding UTxOs to or removing them from the head
without closing),
• optimistic one-step head closure without the need for onchain contestation,
• pessimistic two-step head closure with an O(∆) contestation period, independent of n, where
∆ is the onchain settlement time of a transaction, and
• splitted onchain decommit of the final UTxO set (in case it is too large to fit into a single
transaction).

4 Protocol Setup
In order to create a head-protocol instance, an initiator invites a set of participants {p1 , . . . , pn }
(himself being one of them) to join by announcing to them the protocol parameters: the list of
participants, the parameters of the (multi-)signature scheme to be used, etc.

10
 Each party then establishes pairwise authenticated channels to all other parties.
For some digital-signature scheme, each party pi generates a key pair (ki,ver , ki,sig ) and send his
respective verification key ki,ver to all other parties. This “standard” digital-signature scheme will
be used to authenticate mainchain transactions that are restricted to members of the head-protocol
instance.
For the multisignature scheme (MS) – see Section 2.1 – each party pi generates a key pair

(Ki,ver , Ki,sig ) ← MS-KG(Π) ,

and sends his verification key Ki,ver to all other parties.

Each party then computes his aggregate key from the received verification keys:

Kagg := ← MS-AVK(Π, (Kj,ver )j∈[n] ) .

The multisignature scheme will be used for the offchain confirmation (and offchain and onchain
verification) of head-protocol events.
At the end of this initiation, each party pi stores his signing key and all received verification
keys for the signature scheme,

ki,sig , k ver := (kj,ver )j∈[n] ,
and his signing key, the verification keys, and the aggregate verification key for the multisignature
scheme,

Ki,sig , K ver := (Kj,ver )j∈[n] , Kagg .
If any of the above fails (or the party does not agree to join the head in the first place), the
party aborts the initiation protocol and ignores any further action.2
The initiator now posts the initial transaction onchain as described in Section 5.

5 Mainchain
Here we describe the details of the mainchain state machine (SM) controlling a Hydra head (see
Fig. 2). For state transitions, a formal description of the conditions in tx≡ is foregone in favor of
the intuitive explanations in the text and the figures.

Onchain verification algorithms. The status of the head is maintained in a variable η, which is
part of the SM state and updated by so-called onchain verification (OCV) algorithms Initial, Close,
Contest, and Final. In the context of the mainchain protocol, these OCV algorithms are intentionally
kept as generic as possible – to keep the mainchain SM compatible with many potential head-
protocol variants. The concrete OCV algorithms for the head protocol specified in this paper are
given in context of the head protocol itself as they depend on the specific head-protocol internals:
verification of head-protocol certificates and related onchain state updates. As such, the OCV
algorithms can be seen as abstract mainchain algorithms implemented by the specific head protocol.
Consequently, the OCV implementation for our head protocol is described in Section 6.3.1.
2
Of course, aborting the initiation can be achieved more gracefully by explicitly notifying the initiator about one’s
non-participation. Techniques are even known to finish such an initiation in agreement among all parties [21].

11
 𝗂𝗇𝗂𝗍𝗂𝖺𝗅,
K𝖺𝗀𝗀, h𝖬𝖳, n, T

∅
𝖼𝗂𝖽 {p1}, ν𝗂𝗇𝗂𝗍𝖺𝗅, k1 commit Transaction

⋮ {p1} ∪ 𝗏𝖺𝗅′, ν𝖼𝗈𝗆, U1

{pn}, ν𝗂𝗇𝗂𝗍𝖺𝗅, kn ρ
(r𝗆𝗂𝗇, r𝗆𝖺𝗑)
commited output o
⋮
Forge {p1, …, pn} :: 𝖼𝗂𝖽
𝗏𝖺𝗅, ν, δ Signed: k1

Figure 3: initial transaction (left) withν commit

: check that
𝗌𝖾𝗍𝗎𝗉 transaction (right) attached and one of the
1. U equals 1
locked outputs (center). concatenation of
all ref.ed outputs

Initial state. After the setup phase of Section 4, the head initiator posts an initial transaction
(see Fig. 3). The initial transaction establishes the SM’s initial state (initial, Kagg , hMT , n, T ), where
initial is a state identifier, Kagg is the aggregated multisignature key established during the setup
phase, hMT is the root of a Merkle tree for the signature verification keys k ver = (k1 , . . . , kn ) ex-
changed during the setup phase (identifying the head members), n is the number of head members,
and T is the length of the contestation period. The initial transaction also forges n participation
tokens {p1 , . . . , pn } :: cid, where the currency ID cid is given by the unique monetary-policy script
consumed by the cid input. The script is unique as it is bound to an output and the ledger prevents
double spending. Consequently, we can use cid as a unique identifier for the newly initialized head.
Crucially, the initial transaction has n outputs, where each output is locked by a validator νinitial
and the ith output has ki in its data field. Validator νinitial ensures the following: either the output
is consumed by
1. an SM abort transaction (see below) or
2. a commit transaction (identified by having validator νcom in its only output), and

(a) the transaction is signed and the signature verifies as valid with verification key ki ,
(b) the data field of the output of the commit transaction is Ui = makeUTxO(o1 , . . . , om ),
where the oj are the outputs referenced by the commit transaction’s inputs and makeUTxO
stores pairs (out-ref j , oj ) of outputs oj with the corresponding output reference out-ref j .

The general well-formedness and validity of the initial transaction is checked on the mainchain.
The head members additionally check whether the head parameters match the parameters agreed
on during the setup phase. In case of a mismatch the head opening is considered as failed.

Committing outputs to a head. To lock outputs for a Hydra head, the ith head member will
attach a commit transaction (see Fig. 3) to the ith output of the initial transaction. Validator νcom
ensures that the commit transaction correctly records the partial UTxO set Ui committed by the
party.
All commit transactions will in turn be collected by an SM transaction—either collectCom or
abort (see below).

Collecting commits. The SM transition from initial to open is achieved by posting the collect-
Com transaction (see Fig. 4). All parameters Kagg , hMT , n, and T remain part of the state, but in

12
 Collect: Initial State to Open ν𝖼𝗈𝗆: check that
1. next transaction is
tx≡: check that
1. π𝖬𝖳 is proof that k is
collect oder abort SM
contained in h𝖬𝖳
2. η = 𝖨𝗇𝗂𝗍𝗂𝖺𝗅(U1, …, Un)

Initial checks:
1. k1 to kn are in h𝖬𝖳

𝗂𝗇𝗂𝗍𝗂𝖺𝗅, 𝖼𝗈𝗅𝗅𝖾𝖼𝗍𝖢𝗈𝗆 𝗈𝗉𝖾𝗇, K𝖺𝗀𝗀, η,

K𝖺𝗀𝗀, h𝖬𝖳, n, T π𝖬𝖳 h𝖬𝖳, n, T
∅ commit transactions {p1, …, pn} ∪ 𝗏𝖺𝗅
{p1}, ν𝗂𝗇𝗂𝗍𝖺𝗅, k1 ⋮ …, ν𝖼𝗈𝗆, U1

⋮ ⋮
{pn}, ν𝗂𝗇𝗂𝗍𝖺𝗅, kn ⋮ …, ν𝖼𝗈𝗆, Un

(r𝗆𝗂𝗇, r𝗆𝖺𝗑) (r′𝗆𝗂𝗇, r′𝗆𝖺𝗑)

Forge {p1, …, pn} :: 𝖼𝗂𝖽 Signed: k′

tx≡: check that

tx
Figure 4: initial
k k
1.
transaction
h
1 to n are in 𝖬𝖳
{p , …, p } :: 𝖼𝗂𝖽
Abort transaction
(left) with collectCom
≡: check that ν (right) πand commit
U = {U }
h
k′

i
transactions 𝖼𝗈𝗆: check that
1. next transaction is
collect oder abort SM
1. 𝖬𝖳 is proof that
contained in 𝖬𝖳
is

(center). 2. 1 n 2. i i where
over those who
committed

𝗂𝗇𝗂𝗍𝗂𝖺𝗅, 𝖺𝖻𝗈𝗋𝗍
K𝖺𝗀𝗀, h𝖬𝖳, n, T 𝖿𝗂𝗇𝖺𝗅
π𝖬𝖳

∅ commit transactions ∅

{p1}, ν𝗂𝗇𝗍𝗂𝖺𝗅, k1 ⋮ …, ν𝖼𝗈𝗆, U1

⋮
{pn}, ν𝗂𝗇𝗍𝗂𝖺𝗅, kn

(r𝗆𝗂𝗇, r𝗆𝖺𝗑) (r′𝗆𝗂𝗇, r′𝗆𝖺𝗑)

⋮
}
<latexit sha1_base64="WxxOLoH8qvPV+BjLCZ5YgtKmayM=">AAAB/XicdVDLSgNBEOz1GeMr6tHLYBA8hd0o6DHoxWMU84BkCbOT2WTIzO4y0yuEJfgDXvUPvIlXv8Uf8DucJHvQBAsaiqpuqqkgkcKg6345K6tr6xubha3i9s7u3n7p4LBp4lQz3mCxjHU7oIZLEfEGCpS8nWhOVSB5KxjdTP3WI9dGxNEDjhPuKzqIRCgYRSvddye9UtmtuDOQZeLlpAw56r3Sd7cfs1TxCJmkxnQ8N0E/oxoFk3xS7KaGJ5SN6IB3LI2o4sbPZp9OyKlV+iSMtZ0IyUz9fZFRZcxYBXZTURyaRW8q/ufhUC2kY3jlZyJKUuQRm4eHqSQYk2kVpC80ZyjHllCmhf2fsCHVlKEtrGiL8RZrWCbNasU7r1TvLsq167yiAhzDCZyBB5dQg1uoQwMYhPAML/DqPDlvzrvzMV9dcfKbI/gD5/MH32SV5A==</latexit>
U

Forge {p1, …, pn} :: 𝖼𝗂𝖽 Signed: k′

Burn {p1, …, pn} :: 𝖼𝗂𝖽

Figure 5: initial transaction (left) with abort transaction (right) and commit transactions
(center).

addition, a value η ← Initial(U1 , . . . , Un ) is stored in the state. The idea is that η stores information
about the initial UTxO set, which is made up of the individual UTxO sets Ui collected from the
commit transactions, in order to verify head-status information later (see below).
It is also required that all n participation tokens be present in the SM output of the collectCom
transaction. This ensures that the collectCom transaction collects all n commit transactions. Note
that since νinitial does not allow an SM commit transaction to consume the outputs of the initial
transaction, the only way to post the collectCom transaction is if each head member has posted a
commit transaction.
Finally, note that the transition requires a proof πMT that the signer k 0 is in the Merkle Tree
belonging to hMT , which ensures that only head members can post SM transactions. This will be
the case for all transitions considered in this paper (and will not be pointed out any further).

Aborting a head. The abort transaction (see Fig. 5) allows a party to abort the creation of a
head in case some parties fail to post a commit transaction. The final state does not contain any
information (beyond its identifier), but it is ensured that (1) the outputs U correspond to the union
of all committed UTxO sets Ui and (2) all participation tokens are burned.

Close transaction. In order to close a head, a head member may post the close transaction (see
Fig. 6), which results in a state transition from the open state to the closed state. For a successful
close, a head member must provide valid information ξ about (their view of) the current head
state. This information is passed through OCV algorithm Close, resulting in a new OCV status

13
 tx≡: check that
1. π𝖬𝖳 is proof that k′ is

Close contained in h𝖬𝖳

2. 𝒞 = {k′}
3. T𝖿𝗂𝗇𝖺𝗅 = r′𝗆𝖺𝗑 + T
4. η′ = 𝖢𝗅𝗈𝗌𝖾(K𝖺𝗀𝗀, η, ξ)

𝖼𝗅𝗈𝗌𝖾𝖽, K𝖺𝗀𝗀,
𝗈𝗉𝖾𝗇, K𝖺𝗀𝗀, η, 𝖼𝗅𝗈𝗌𝖾
η′, 𝒞, h𝖬𝖳, n,
h𝖬𝖳, n, T π𝖬𝖳, ξ
T, T𝖿𝗂𝗇𝖺𝗅
{p1, …, pn} ∪ 𝗏𝖺𝗅 {p1, …, pn} ∪ 𝗏𝖺𝗅

(r𝗆𝗂𝗇, r𝗆𝖺𝗑) (r′𝗆𝗂𝗇, r′𝗆𝖺𝗑)

Signed: k Signed: k′
tx≡: check that
1. π𝖬𝖳 is proof that k′ is

Contest
Figure 6: collectCom transaction (left) with close transaction (right).
contained in h𝖬𝖳
2. k′ ∉ 𝒞 and 𝒞′ = 𝒞 ∪ {k′}
3. η′ = 𝖢𝗈𝗇𝗍𝖾𝗌𝗍(K𝖺𝗀𝗀, η, ξ)
4. r′𝗆𝖺𝗑 ≤ T𝖿𝗂𝗇𝖺𝗅

𝖼𝗅𝗈𝗌𝖾𝖽, K𝖺𝗀𝗀, 𝖼𝗅𝗈𝗌𝖾𝖽, K𝖺𝗀𝗀,

𝖼𝗈𝗇𝗍𝖾𝗌𝗍
η, 𝒞, h𝖬𝖳, n, η′, 𝒞′
′ , h𝖬𝖳, n,
T, T𝖿𝗂𝗇𝖺𝗅 π𝖬𝖳, ξ
T, T𝖿𝗂𝗇𝖺𝗅
{p1, …, pn} ∪ 𝗏𝖺𝗅 {p1, …, pn} ∪ 𝗏𝖺𝗅

(r𝗆𝗂𝗇, r𝗆𝖺𝗑) (r′𝗆𝗂𝗇, r′𝗆𝖺𝗑)

Signed: k Signed: k′

Figure 7: close/contest transaction (left); contest transaction (right)

η 0 ← Close(Kagg , η, ξ). OCV algorithm Close uses the previous OCV status η and Kagg to check
the head information ξ. Note that if a check fails, Close may output ⊥, but in order for a close
transaction to be valid, η 0 6= ⊥ is required.
Once a close transaction has been posted, a contestation period begins which should last at
least T slots. Hence, the last slot Tfinal of the contestation period is recorded in the state, and it is
0
ensured that Tfinal ≥ rmax + T.
Finally, the SM state is extended by a set C initialized to the poster’s signing key, i.e., C ← {k 0 }.
C is used to ensure that no party posts more than once during the contestation period.

Contestation. If the party first closing a head posts outdated/incomplete information about the
current state of the head, any other party may post a contest transaction (see Fig. 7), which causes
a state transition from the closed state to itself. The transition handles update information ξ by
passing it through OCV algorithm Contest, resulting in a new OCV status η 0 ← Contest(Kagg , η, ξ).
OCV algorithm Contest uses the previous OCV status η and Kagg to check the update information
ξ. Similarly to Close, Contest may output ⊥, but in order for a close transaction to be valid η 0 6= ⊥
is required.
The contest transaction is only valid if the old set C of parties who have contested (or closed) so
far does not yet include the poster, i.e., k 0 ∈ / C. If this check passes, the set is extended to include
the poster of the contest transaction, i.e., C 0 ← C ∪ {k 0 }. Furthermore, contest transactions may
0
only be posted up until Tfinal , i.e., it is required that rmax ≤ Tfinal .
Observe that during the contestation period, up to n − 1 contest transactions may be posted (of
course, the parameter T has to be chosen large enough as to allow each head member to potentially
post a close/contest transaction).

14
 tx≡: check that
1. π𝖬𝖳 is proof that k′ is

Fanout contained in h𝖬𝖳

2. 𝖥𝗂𝗇𝖺𝗅(η, U)
3. r′𝗆𝗂𝗇 > T𝖿𝗂𝗇𝖺𝗅

𝖼𝗅𝗈𝗌𝖾𝖽, K𝖺𝗀𝗀,
𝖿𝖺𝗇𝗈𝗎𝗍
η, 𝒞, h𝖬𝖳, n, 𝖿𝗂𝗇𝖺𝗅
π𝖬𝖳
T, T𝖿𝗂𝗇𝖺𝗅
{p1, …, pn} ∪ 𝗏𝖺𝗅 ∅

(r𝗆𝗂𝗇, r𝗆𝖺𝗑)
⋮

(r′𝗆𝗂𝗇, r′𝗆𝖺𝗑)
}
<latexit sha1_base64="WxxOLoH8qvPV+BjLCZ5YgtKmayM=">AAAB/XicdVDLSgNBEOz1GeMr6tHLYBA8hd0o6DHoxWMU84BkCbOT2WTIzO4y0yuEJfgDXvUPvIlXv8Uf8DucJHvQBAsaiqpuqqkgkcKg6345K6tr6xubha3i9s7u3n7p4LBp4lQz3mCxjHU7oIZLEfEGCpS8nWhOVSB5KxjdTP3WI9dGxNEDjhPuKzqIRCgYRSvddye9UtmtuDOQZeLlpAw56r3Sd7cfs1TxCJmkxnQ8N0E/oxoFk3xS7KaGJ5SN6IB3LI2o4sbPZp9OyKlV+iSMtZ0IyUz9fZFRZcxYBXZTURyaRW8q/ufhUC2kY3jlZyJKUuQRm4eHqSQYk2kVpC80ZyjHllCmhf2fsCHVlKEtrGiL8RZrWCbNasU7r1TvLsq167yiAhzDCZyBB5dQg1uoQwMYhPAML/DqPDlvzrvzMV9dcfKbI/gD5/MH32SV5A==</latexit>
U

Signed: k Signed: k′

Burn {p1, …, pn} :: 𝖼𝗂𝖽

Figure 8: close/contest transaction (left); fanout transaction (right)

Final state. Once the contestation phase is over, a head may be finalized by posting a fanout
transaction, taking the SM from closed to final. The fanout transaction must have outputs that
correspond to the most recent head state. To that end, OCV predicate Final checks the transaction’s
output set U against the information recorded in η. The fanout transaction is only valid if Final
0
outputs true. Moreover, to ensure that the fanout transaction is not posted too early, rmin > Tfinal
is required. Finally, all participation tokens must be burned.

6 Simple Head Protocol Without Conflict Resolution

This section describes the simplified version of the head protocol, and without conflict resolution,
with the goal to demonstrate the protocol basics without overloading the presentation with too
many details. Conflict resolution is added to the protocol in Section B, and the full protocol is
sketched in Appendix C.
We first introduce a security definition for the head protocol in Section 6.1. The protocol
machine is described in Section 6.2, the head-specific mainchain code in Section 6.3, and a security
proof for the head protocol is given in Section 6.4.

6.1 Security definition

6.1.1 Protocol syntax
The head-protocol syntax is HP = (Prot, Initial, Close, Contest, Final). The main component is the
protocol machine Prot, an instance of which is run by every head member. The other algorithms
are used for setup and onchain verification and form the interface to the mainchain. In particular,

• Σ ← generates global parameters,

• (Kver , Ksig ) ← MS-KG(Σ) allows every head member to generate fresh public/private key
material based on the global parameters,
• Kagg ← MS-AVK(Σ, (Kver,i )i ) aggregates public keys, and
• Initial, Close, Contest, and Final are onchain verification algorithms (cf. Section 5).

The head-protocol machine Prot has the following interface to the environment:

15
 • input (init, i, K ver , Ksig , U0 ) is used to initialize the head protocol, for the party with index
i, with a vector of public-key material K ver , private-key material Ksig , and an initial UTxO
set U0 ;
• input (new, tx) is used to submit a new transaction tx;
• output (seen, tx) announces that transaction tx has been seen (by the party outputting the
message);
• output (conf, tx) announces that transaction tx has been confirmed (in the view of the party
outputting the message);
• input (close) is used to initiate head closure (produces a certificate ξ); and
• input (cont, η) is used to contest (produces a certificate ξ).

6.1.2 Protocol security

The security definition for the head protocol guarantees the following four, intuitively stated prop-
erties:

• Consistency: No two uncorrupted parties see conflicting transactions confirmed.

• Liveness: If all parties remain uncorrupted and the adversary delivers all messages, then
every transaction becomes confirmed at some point.
• Soundness: The final UTxO set accepted on the mainchain results from a set of seen trans-
actions.
• Completeness: All transactions seen as confirmed by an honest party at the end of the
protocol are considered on the mainchain.

Experiment for security definition. The security properties above are captured by considering
a random experiment that involves
• an adversary A,
• a network under full scheduling control of A, able to drop messages or delay them arbitrarily,
• a setup phase,
• n parties pi , corruptible by A, running the head protocol with the parameters from the setup
phase and an initial UTxO set U0 chosen by A, and
• an abstract mainchain (mostly) controlled by A.
The experiment ends once the mainchain state machine arrives in the final state, and the
adversary wins if certain conditions are not satisfied at the end of the experiment.
In more detail, the experiment proceeds as follows:
1. Global parameters Σ ← MS-Setup are generated, and Σ is passed to A.
2. For each party pi , key material (Kver,i , Ksig,i ) ← MS-KG(Σ) is generated, and the vector K ver
of all public keys and Kagg ← MS-AVK(Σ, K ver ) are passed to A.

16
 3. Each party pi ’s protocol machine is initialized with (init, i, K ver , Ksig,i , U0 ), where U0 is
chosen by A.
4. The adversary now gets to control inputs to parties (e.g., new transactions, close/contest
requests) and sees outputs (e.g., seen and confirmed transactions). The following bookkeeping
takes place:
• when an uncorrupted party pi outputs ξ upon close command, record (close, i, ξ);
• when uncorrupted party pi outputs ξ upon (cont, η) command, record (cont, i, η, ξ).
In “parallel” to the above, the experiment sets C, Hcont ← ∅ and does the following to simulate
the mainchain:
(a) Initialize η ← (U0 , 0, ∅).
(b) When A supplies (i, ξ): if i is uncorrupted, ξ gets replaced by the ξ recorded in
(close, i, ξ) and Hcont ← Hcont ∪ {i}. Then, η ← Close(Kagg , η, ξ) and C ← C ∪ {i}
is computed. If Close rejects, everything in this step is discarded and the step repeated.
(c) The adversary gets to repeatedly supply (i, ξ) for i ∈
/ C; if i is uncorrupted, ξ gets replaced
by the ξ recorded in (cont, i, ξ) and Hcont ← Hcont ∪ {i}. Then, η ← Contest(Kagg , η, ξ)
and C ← C ∪ {i} is computed. If Contest rejects, everything in this step is discarded.
(d) When the adversary supplies Ufinal , b ← Final(η, Ufinal ) is computed, and the experiment
ends.
Our protocol gives different security guarantees depending on the level of adversarial corruption. It
provides correctness independently of both, the number of corrupted head parties and the network
conditions. But the guarantee that the protocol makes progress (i.e., that new transactions get
confirmed in the head) is only provided in the case that no head parties are corrupted and that the
network conditions are good.
To capture this difference, we distinguish:
Active Adversary. An active adversary A has full control over the protocol, i.e., he is fully unre-
stricted in the above security game.
Network Adversary. A network adversary A∅ does not corrupt any head parties, eventually delivers
all sent network messages (i.e., does not drop any messages), and does not cause the close
event. Apart from this restriction, the adversary can act arbitrarily in the above experiment.

Security events. Consider the following random variables:

• Ŝi : the set of transactions tx for which party pi , while uncorrupted, output (seen, tx);
• C i : the set of transactions tx for which party pi , while uncorrupted, output (conf, tx);
• Hcont : the set of (at the time) uncorrupted parties who produced ξ upon close/contest request
and ξ was applied to correct η (see above); and
• H: the set of parties that remained uncorrupted.
The security of the head protocol is captured by considering the following events, each corresponding
to one of the security properties introduced above:

17
 • Consistency (Head): In presence of an active adversary, the following condition holds:
For all i, j, U0 ◦ (C i ∪ C j ) 6= ⊥, i.e., no two uncorrupted parties see conflicting transactions
confirmed.
• Liveness (Head): In presence of a network adversary the following condition T holds: For
any transaction tx input via (new, tx), the following eventually holds: tx ∈ i∈[n] C i ∨ ∀i :
U0 ◦ (C i ∪ {tx}) = ⊥, i.e., every party will see the transaction confirmed or every party will
see the transaction in conflict with his confirmed transactions.3
• Soundness
T (Chain): In presence of an active adversary, the following condition is satisfied:
∃S̃ ⊆ i∈H Ŝi : Ufinal = U0 ◦ S̃, i.e., the final UTxO set results from a set of seen transactions.
• Completeness S (Chain): In presence of an active adversary, the following condition holds:
For S̃ as above, pi ∈Hcont C i ⊆ S̃, i.e., all transactions seen as confirmed by an honest party
at the end of the protocol are considered.
Note that our simplified protocol with conflict resolution and our full protocol in Appendices B
and C achieve liveness in the above sense, but that our simplified protocol without conflict resolution
in Section 6 only achieves a weaker notion of liveness, namely liveness in a
Conflict-Free Execution: Let N = {tx | (new, tx)} the set of all transactions input to a new event
during the execution of the head protocol. A head-protocol execution is conflict-free iff
U0 ◦ N 6= ⊥.
Respectively, the liveness aspect of the simplified protocol without conflict resolution is captured
by the following event, instead:
• Conflict-Free Liveness (Head): In presence of a network adversary, a conflict-free T execu-
tion satisfies the following condition: For any transaction tx input via (new, tx), tx ∈ i∈[n] C i
eventually holds.

6.2 Protocol machine

The protocol machine Prot consists of a number of subroutines that handle inputs from the en-
vironment (e.g., the client command to issue a new transaction for confirmation, or the arrival
of another party’s confirmation request). The protocol is depicted in Figure 9. All relevant non-
obvious notation is explained in the following paragraphs.

6.2.1 Local state representation

Every party maintains local objects to represent transactions, snapshots, and his local head-UTxO
set. These objects exist in two versions, a seen object has been signed by the party (the party has
seen and approved the event); and a confirmed object is associated with a valid multisignature (the
party has received a valid multisignature on the object). A seen object X is denoted by X̂ and a
confirmed object by X.
A party’s local protocol state consists of the multisignature verification keys and its own signing
key, of snapshot counters ŝ and s, and of variables
3
In particular, liveness expresses that the protocol makes progress under reasonable network conditions if no head
parties get corrupted – implying that, given any guaranteed upper bound δ on message delivery delay, the worst-case
transaction-confirmation time is bounded in function of δ.

18
 • Û and U, keeping track of the most recent seen resp. confirmed, snapshots,
• L̂ and L, keeping track of recent seen resp. confirmed UTxO sets, and
• T̂ and T , the sets of seen resp. confirmed, transactions that have not been considered by a
snapshot yet.

Variables Û and U store so-called snapshot objects, which are data structures keeping information
about a snapshot. Specifically, a snapshot object U has the following structure:

U.s snapshot number

U.U corresponding UTxO set
U.h hash of U
U.T set of transactions relating this snapshot to its predecessor
U.S signature accumulator (array of signatures)
U.σ̃ multisignature

The function snObj(s, U, T ) initializes a snapshot object and is explained later.

Similarly, T̂ and T store sets of transaction objects. A transaction object tx has the following
structure:

tx.i index of the party issuing transaction for certification

tx.tx transaction
tx.h hash of tx
tx.S signature accumulator (array of signatures)
tx.σ̃ multisignature.

The function txObj(i, tx) initializes a transaction object by setting the appropriate fields to the
passed values (including computing the hash of tx) and the remaining fields to ∅ resp. ⊥.

6.2.2 Three-round entity confirmation

Transactions and snapshots are confirmed in an asynchronous 3-round process:4

• req: The issuer of a transaction or snapshot requests the entity to be signed by sending the
entity description to every head member.
• ack: The head members acknowledge the entity be replying their signatures on the entity to
the issuer.
• conf: The issuer collects all signatures, combines the multisignature, and sends the multisig-
nature to all head members.

4
Note that, as a variant, this 3-round process (with linear communication in n) can be condensed to 2 rounds
(with quadratic communication in n) by combining the last two rounds into an “all-to-all” signature notification.
This variant may be preferable for small n.

19
 Simplified Hydra Head Protocol Without Conflict Resolution

on (init, i, K ver , Ksig , U0 ) from client on (close) from client

V ← K ver ↓(tx,σ̃)
return (U.U, U.s, U.σ̃, T )
avk ← MS-AVK(V)
sk ← Ksig on (cont, η) from client
ŝ, s ← 0 (Uη , sη , Tη ) ← η
Û, U ← snObj(0, U0 , ∅) if s ≤ s
L̂, L ← U0 U ← Uη
T̂ , T ← ∅ s ← sη
σ̃ ← ε
on (new, tx) from client else
require valid-tx(tx) and L ◦ tx 6= ⊥ U ← U.U
multicast (reqTx, tx) s←s
σ̃ ← U.σ̃
on (newSn) for pi ↓(tx)
T 0 ← applicable(U, T ∪ Tη ) \ Tη
require leader(s + 1) = i and Û = U if U = Uη

↓(h)
T ← maxTxos(T ) U ←ε
multicast (reqSn, s + 1, T ) return
↓(tx,σ̃)
(U, s, σ̃, {t ∈ T | t.tx ∈ T 0 })

on (reqTx, tx) from pj on (reqSn, s, T ) from pj

require valid-tx(tx) ∧ L̂ ◦ tx 6= ⊥ require s = s + 1 and leader(s) = j
↓(h)
wait L ◦ tx 6= ⊥ wait s = ŝ and T ⊆ T
h ← H(tx) ŝ ← ŝ + 1
T̂ [h] ← txObj(j, tx) Û ← snObj(ŝ, U.U, T )
L̂ ← L̂ ◦ tx σi ← MS-Sign(sk, Û.hkŝ)
output (seen, tx) send (ackSn, ŝ, σi ) to pj
σi ← MS-Sign(sk, h)
send (ackTx, h, σi ) to pj on (ackSn, s, σj ) from pj
require s = ŝ and leader(s) = i
on (ackTx, h, σj ) from pj require Û.S[j] = ε
require T̂ [h].i = i Û.S[j] ← σj
require T̂ [h].S[j] = ε if ∀k : Û.S[k] 6= ε
T̂ [h].S[j] ← σj σ̃ ← MS-ASig(Û.hks, V, Û.S)
if ∀k : T̂ [h].S[k] 6= ε if σ̃ 6= ⊥
σ̃ ← MS-ASig(h, V, T̂ [h].S) multicast (confSn, s, σ̃)
if σ̃ 6= ⊥
multicast (confTx, h, σ̃) on (confSn, s, σ̃) from pj
require s = ŝ 6= s
on (confTx, h, σ̃) from pj if MS-Verify(avk, Û.hkŝ, σ̃)
if MS-Verify(avk, h, σ̃) s←s
tx ← T̂ [h].tx Û.σ̃ ← σ̃
L ← L ◦ tx U ← Û
T̂ [h].σ̃ ← σ̃
T ← T \ ReachT (U.T )
T [h] ← T̂ [h]
T̂ ← T̂ \ T̂ [h]
output (conf, tx)

Figure 9: Head-protocol machine for the simple protocol without conflict resolution from the
perspective of party pi .

20
6.2.3 Code notation
Code is depicted by view of a generic head party pi . We assume that a party only accepts mes-
sages authenticated by its claimed sender (by use of the authenticated channels established during
the setup phase)—unauthenticated messages are simply treated as unseen by the recipient. For
simplicity, whenever a party pi sends a message to all head parties, it also sends the message to
itself.
For the transaction set T̂ (and similarly T ), T̂ [h] denotes tx ∈ T̂ such that tx.h = h, i.e., the
transaction object corresponding to the transaction with hash H(tx) = h.
The ↓ operator indicates the projection of an object onto a subset of its fields. For example,
T̂ ↓(h) denotes the set of hashes corresponding to the transactions in T̂ .
The following notation is used to describe the application of transactions to a given UTxO set.

• U 0 = U ◦ tx assigns to U 0 the UTxO set resulting from applying transaction tx to UTxO set
U . In case that the validation fails it returns U 0 = ⊥.
• U 0 = U ◦ T assigns to U 0 the UTxO set resulting from applying all transaction in the trans-
action set T to UTxO set U . In case that not all transactions can be applied it returns
U 0 = ⊥.

In the protocol routines of Fig. 9, by require(P ), we express that predicate P must be satisfied
for the further execution of a routine—while immediately terminated on ¬P . By wait(P ) we
express a non-blocking wait for predicate P to be satisfied. On ¬P , the execution of the routine is
stopped, queued, and reactivated as soon as P is satisfied. Finally, we assume the code executions
of each routine to be atomic—excluding the blocks of code that may be put into the wait queue
for later execution, in which case we assume the wait block to be atomic.

6.2.4 Protocol flow

Initializing the head. Initially, by activation via the (init) event, the parties store their mul-
tisignature key material form the setup phase, ad set L = L̂ = U = Û = U0 where U0 is the
initial UTxO set extracted from the η-state of the collectCom transaction (see Fig. 4). The initial
transaction sets are empty, T = T̂ = ∅, and s = ŝ = 0.

Confirming new transactions.

(new). At any time, by calling (new, tx), a head party can (asynchronously) inject a new trans-
action tx to the head protocol—initiating a 3-round confirmation process for tx as described in
Section 6.2.2. For this, the transaction must be well-formed (valid-tx) and applicable to the current
confirmed local UTxO state: L ◦ tx 6= ⊥. If the checks pass, a (reqTx, tx) request is sent out to all
parties.

(reqTx). Upon receiving request (reqTx, tx), a signature is only issued by a party pi if tx applies
to his local seen UTxO state: L̂ ◦ tx 6= ⊥. If this is the case, the party waits until his confirmed
UTxO state L has “caught up”: the signature is only delivered as soon as L ◦ tx 6= ⊥, i.e., a
transaction is only signed once it is applicable to the local confirmed state.

21
 In case the preconditions are satisfied, a respective transaction object is allocated, initialized,
and added to T̂ ; L̂ is updated by applying tx, and (seen, tx) is output; and, finally, a signature on
the hash of tx, σ = MS-Sign(H(tx)), is delivered back to the transaction issuer by replying with an
(ackTx, H(tx), σ).

(ackTx). Upon receiving acknowledgment (ackTx, h, σj ), the transaction issuer stores the received
signature in the respective transaction object. If a signature from each party has been collected, pi
computes the multisignature σ̃ and, if valid, sends it to all parties in a (confTx, h, σ̃) message.

(confTx). Upon receiving confirmation (confTx, h, σ̃) from the transaction issuer, containing a
valid multisignature, the multisignature is stored in the respective transaction object, L is updated
by applying tx, and the transaction object is moved from T̂ to T . Finally, (conf, tx) is output.

Creating snapshots. In parallel to confirming transactions, parties generate snapshots in a

strictly sequential round-robin manner. We call the party responsible for issuing the ith snapshot
the leader of the ith snapshot. The issuance frequency of the snapshots tunes a tradeoff between
the transaction space that has to maintained by the parties for storing confirmed but snapshot-
unprocessed transactions against the snapshot-communication overhead in the head protocol. As
the information to be exchanged among the parties for snapshot confirmation is small, such snap-
shots can in principle be greedily issued as soon as the next snapshot leader sees a new confirmed
transaction.

(newSn). On activation by (newSn), the snapshot leader verifies whether Û = U to ensure that he is
not already in the process of snapshot creation. The leader pi then announces the transaction set T ,
the not yet snapshot-processed confirmed transactions to be applied to compute the new snapshot.
However, to reduce communication overhead, only the hashes of the maximal transactions of T
are announced which are the transactions of T not referenced by another transaction in T . This
maximal set is computed by function T = maxTxos(T )↓(h) . Finally the leader sends (reqSn, s+1, T )
to all parties.

(reqSn). Upon receiving request (reqSn, s, T ), party pi checks that s is the next snapshot number
and that pj is responsible for leading its creation. Party pi then waits until the previous snapshot
is confirmed (s = ŝ) and all transactions referred in T are confirmed.
Only then, pi increments his seen-snapshot counter ŝ, and allocates a new snapshot object
calling function snObj that performs the following steps:

1. It reconstructs the transaction set to be applied to the latest confirmed snapshot by calling
function ReachT (T ) that computes all transactions in T reachable from the transactions (with
hashes) in T by following the output references (the inverse of maxTxos); and

2. computes the UTxO set of the new snapshot as Û.U ← U.U ◦ ReachT (T ), and

3. computes the hash of Û.U and sets the fields for the snapshot number and the maximal
transactions applied.

22
Finally, pi computes a signature σi = MS-Sign(sk, H(Û)kŝ), and replies to pj the message (ackSn, s, σi ).5

(ackSn). Upon receiving acknowledgment (ackSn, s, σj ), the snapshot leader stores the received
signature in the respective snapshot object. If a signature from each party has been collected, pi
computes the multisignature σ̃ and, if valid, sends it to all parties in a (confSn, h, σ̃) message.

(confSn). Upon receiving confirmation (confSn, s, σ̃) from the snapshot leader, containing a valid
multisignature, pi stores the multisignature and updates s = s and U = Û. Finally, the set of
confirmed transactions is reduced by excluding the transactions that have been processed by U:
T ← T \ ReachT (U.T ).

Closing the head.

(close). In order to close a head, a party causes the (close) event which returns the latest
confirmed snapshot U.U , snapshot number U.s and the respective multisignature U.σ̃, together
↓(tx,σ̃)
with the remaining confirmed transactions T (multisigned). These items form the certificate
ξ to be posted onchain (see Section 6.3.2).

(cont). In order to contest the current state closed on the mainchain, a party causes the (cont, η)
event with input η being the latest observed head status that has been aggregated onchain for this
head so far (by a sequence of close and contest transactions).
The algorithm then computes “differential” data between the current onchain head status and
the contester’s confirmed view: the latest confirmed snapshot (if newer than seen onchain) and the
set of confirmed transactions (in his view) not yet considered by the current state η. These items
form the certificate ξ to be posted onchain (see Section 6.3.2).
↓(tx)
We only want to pass on the (multisigned) transactions in T \ Tη that have not yet been
processed by the latest snapshot U . This is achieved by applying function applicable that tests, for
↓(tx)
each transaction in tx ∈ T ∪ Tη in appropriate order, whether U ◦ tx 6= ⊥ is still applicable.
Note that the transactions in Tη have to be considered in this process as some transactions in T
may directly depend on them, and would otherwise not be detected to be applicable. As we only
want to extract “differential” data, the transactions in Tη are finally removed again as they are
already recorded in the (accumulative) η state.

6.3 Head-specific mainchain functionality

On an abstract level, as described in Section 5, mainchain and head functionality are clearly sepa-
rated into events that happen onchain and events that happen in the head. In particular, network
participants that are not members of the head protocol only observe mainchain events.
Still, depending on the concrete implementation of the head certification process (which our
abstract description of the mainchain functionality is agnostic of), some mainchain functionality
has to be adapted to the specific choice made for the head protocol. This concerns two aspects:
5
Note that no UTxO sets have to be exchanged in this process as the parties can locally compute a new snapshot
by the given transaction hashes.

23
 client Hydra Protocol

Mainchain Protocol Head Protocol

𝗌𝗍𝖺𝗍𝖾 𝗆𝖺𝖼𝗁𝗂𝗇𝖾 𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅 𝗆𝖺𝖼𝗁𝗂𝗇𝖾

chain 𝚊𝚋𝚜 𝖮𝖢𝖵 𝚒𝚖𝚙𝚕 𝖮𝖢𝖵 head
messaging 𝚊𝚋𝚜 𝖢𝖧𝖨 𝚒𝚖𝚙𝚕 𝖢𝖧𝖨 messaging

Figure 10: Hydra protocol components.

Onchain verification (OCV). The confirmation of head events by means of the multisignature
scheme must be verifiable onchain; and thus, the exact workings of head certification must
be known to the mainchain protocol. Now, given that the onchain portion of the mainchain
protocol (i.e., state machine transition validation) is realized by EUTxO validator scripts,
these scripts utilize the abstract interface of the OCV. Hence, we interpret the head OCV
code as implementing the abstract mainchain OCV specification for all network participants
(Fig. 10).

Chain/head interaction (CHI). Upon observing certain onchain events, a head member’s main-
chain functionality must interact with the head protocol. For instance, this is the case, when a
head member observes the closing of the head on the mainchain. The mainchain functionality
must then query the head protocol to know whether a contest transaction must be posted.

6.3.1 Onchain verification (OCV)

Recall that the mainchain functionality was generically described it terms of η, the latest head
state as known onchain, and ξ, a certificate posted by a head member to update η by delivering
head-confirmed information.
We shortly recapitulate the abstract workings of OCV. After the processing of the collectCom
transaction, the initial UTxO set is stored as η in association of the open state. Later, a party pi
can

• produce a certificate ξ accepted by Close(·) to close out the head and make (his view of) the
current head-UTxO set available on the mainchain, and,
• given the current state η on the mainchain, produce a certificate ξ accepted by Contest(η, ·)
to contest a closure and supply an updated view of the head-UTxO set to the mainchain.

Finally, the function Final checks the UTxO set in the transaction that moves the state machine
into its final state against the information stored in η.
We now instantiate the respective onchain verification (OCV) functionality for the head protocol
given in this section—with its specific way of certifying head states (see Fig. 11).

Initial. The entire initial UTxO set U0 is composed from the n committed UTxO sets Up1 , . . . , Upn ,
and returned as η = (U0 , 0, ∅).

24
 Algorithms for Onchain Verification

Initial (Up1 , . . . , Upn ) Contest (Kagg , η, ξ)

return (Up1 ∪ · · · ∪ Upn , 0, ∅) (Uη , sη , Tη ) ← η
(U, s, σ̃, T ) ← ξ
Close (Kagg , η, ξ) if ∃(txi , σ̃i ) ∈ T : ¬MS-AVerify(Kagg , H(txi ), σ̃i )
(U, s, σ̃, T ) ← ξ return ⊥
if ∃(txi , σ̃i ) ∈ T : if s ≤ sη
¬MS-AVerify(Kagg , H(txi ), σ̃i ) UN ← Uη
return ⊥ else
if s = 0 UN ← U
(U, ·, ·) ← η if ¬MS-AVerify(Kagg , H(U )ks, σ̃) return ⊥
else if ¬MS-AVerify(Kagg , H(U )ks, σ̃)
Tη ← applicable(UN , Tη )
return ⊥
if UN ◦ (Tη ∪ T ↓(tx) ) = ⊥
if U ◦ T ↓(tx) = ⊥
return ⊥
return ⊥
return (UN , s, Tη ∪ T ↓(tx) )
return (U, s, T ↓(tx) )
Final (η, U )
(Uη , sη , Tη ) ← η
return (U = Uη ◦ Tη )

Figure 11: The algorithms used by the state machine for onchain verification.

Close. The state machine uses the onchain verification (OCV) algorithm Close to verify the infor-
mation submitted by the party.
Recall that, when a pi receives the close command, it simply outputs as certificate the snap-
shot number, the UTxO set, and the multisignatures corresponding to the most recent confirmed
snapshot U as well as all confirmed transactions in T which have not yet been considered in U,
along with the corresponding multisignatures.
OCV function Close (see Figure 11) verifies all multisignatures in ξ = (U, s, σ̃, T ), i.e., those of
H(U )ks and the transactions in T , and ensures that the transactions in T can be applied to U (or,
in case of s = 0, to U0 ). The algorithm then outputs the new state η 0 = (U, s, T ↓(tx) ).

Contest. The state machine uses the OCV algorithm Contest to verify the “differential” data
submitted by a contesting party.
Recall that, when a pi receives the command (cont, η) for η = (Uη , sη , Tη ), he supplies his
latest snapshot U.U if it is newer than Uη , and those confirmed transactions that have not yet been
considered by the latest snapshot. In case that Uη is newer than the own snapshot, the transactions
yet to be delivered can be found by trying to apply them (together with Tη ) to Uη —as those already
considered by Uη can no longer be applied; this computation is performed by function applicable.
Similarly to the close case, OCV function Contest, given ξ = (U, s, σ̃, T ), first checks all signa-
tures.
In case that the provided snapshot U is newer than the snapshot Uη from the onchain state η,
the set Tη is reduced to those transactions that are still applicable to the newer of both snapshots,
UN .
Finally, it is ensured that Tη ∪ T ↓(tx) can be applied to the newest of both snapshots, and the

25
 Chain/Head Interaction

on (clientTx, tx) on (chainCollectCom)

head.(new, tx) (U0 , ·, ·) ← Initial(Up1 , . . . , Upn )
head.(init, i, K ver , Ksig,i , U0 )
on (clientClose)
ξ ← head.(close) on (chainClose)
chain.postTx(close, ξ) η 0 = (U 0 , s0 , T 0 ) ← chain.Close(Kagg , η, ξ)
ξ = (U, s, σ̃, T ) ← head.(cont, η 0 )
on (chainInitial) if s > s0 ∨ T 6= ∅
chain = K setup
require Kagg agg chain.postTx(contest, ξ)
require hMT = HMerkle (k ver )
chain.postTx(commit, U ) on (chainContest)
η 0 = (U 0 , s0 , T 0 ) ← chain.Contest(Kagg , η, ξ)
on (chainInitialTimeOut) ξ = (U, s, σ̃, T ) ← head.(cont, η 0 )
if (all members committed) if s > s0 ∨ T 6= ∅
chain.postTx(collectCom) chain.postTx(contest, ξ)
else
chain.postTx(abort) on (chainClosedTimeOut)
chain.postTx(fanout)

Figure 12: Chain/head interaction: Additional mainchain actions for head members.

new (aggregate) state η 0 = (UN , s, Tη ∪ T ↓(tx) ) is output.

Final. Given η = (Uη , sη , Tη ) and U , Final checks that U = Uη ◦ Tη .

6.3.2 Chain/head interaction (CHI)

In Fig. 12, we summarize that part of the Hydra mainchain functionality that interacts with the
head member (client) and the head protocol.
Routine clientTx handles the client’s request to issue a head transaction by delegating the
request to the head protocol. Routine clientClose handles the client’s request to close the head.
It gathers a certificate for the current local state from the head protocol, and posts this certificate
onchain.
Routine chainInitial gets triggered on seeing the head’s initial transaction onchain. It verifies
the parameters recorded in the initial transaction against the parameters gathered during the setup
phase described in Section 4: in particular, the aggregate multisignature key must match, and hMT
must be the Merkle-tree hash of the gathered verification keys k ver . If successful, the client’s UTxO
set is committed onchain.
Routine chainInitialTimeOut gets triggered once the initial commit period has expired. It
then either posts a collectCom transaction containing all committed UTxO sets—in case that all
head members committed a UTxO set—or an abort transaction otherwise.
Routine chainCollectCom gets triggered on seeing the head’s collectCom transaction onchain.
It computes, into U0 , the set of committed UTxOs, and initializes the head protocol.
Routines chainClose and chainContest get triggered by observing the head’s close and contest
transactions, respectively. They compare the latest onchain state η to the party’s own head state by

26
calling the head protocol’s cont function to obtain a certificate ξ for a differential onchain update
to represent the portions of the local state not yet considered by η. If necessary, a corresponding
contest transaction is posted onchain.
Routine chainClosedTimeOut gets triggered once the contestation period has expired. It then
posts a fanout transaction containing the final UTxO set.

6.4 Security proof

This section proves that the head protocol presented in Section 6 satisfies Consistency, Conflict-
Free Liveness, Soundness, and Completeness. The proof proceeds by establishing several
invariants that facilitate proving these properties. Throughout the proof, the assumption is made
that at most n − 1 head members are corrupted. Moreover, assume no signatures are forged and no
hashes collide; these events occur with negligible probability only. Consider the following random
variables:

• SNj : the UTxO set corresponding to j th snapshot, i.e., the set that gets the j th multisignature
on snapshots (SN0 = U0 );
• T̃j : the transaction set corresponding to SNj , formally defined via T̃0 = ∅, and T̃j := T̃j−1 ◦
ReachT (T ) where T is the set proposed in (reqSn, j, T );
• Cchain : keeps track of “transactions on chain” and is defined as follows: upon (successful) close
resp. contest with ξ for η, let Cchain ← T̃s ∪ T , where (·, s, T ) is the output of Close(Kagg , η, ξ)
resp. Contest(Kagg , η, ξ);
• SNcur,i : latest confirmed snapshot as seen by party pi .

Lemma 1 (Consistency). The basic head protocol satisfies the Consistency property.

Proof. Observe that C i ∪ C j ⊆ Ŝi since no transaction can be confirmed without every honest
party signing off on it. Since parties do not sign conflicting transactions, U0 ◦ Ŝi 6= ⊥. Thus,
U0 ◦ (C i ∪ C j ) 6= ⊥

Invariant 1. Consider a conflict-free execution of the basic head protocol in presence of a network
adversary. Then, for any transaction tx input to the protocol via (new) the following holds with
respect to any parties pi and pj :
(t0 ) (t) (t)
∀t0 : Li ◦ tx 6= ⊥ ⇒ ∃T ≥ t0 ∀t ≥ T : Lj ◦ tx 6= ⊥ ∨ tx ∈ C j

where the superscript ·(t) indicates the time when the respective variable is evaluated.
(t )
Proof. Assume that party pi sees tx at time t0 and Li 0 ◦ tx 6= ⊥. By conflict-freeness and full
(t) (t ) (t)
delivery we get that, eventually, each party pj holds C j ⊇ C i 0 . By this time t, either Lj ◦tx 6= ⊥
(t) (t)
or tx ∈ C j (as we have conflict-freeness, and C j ⊆ N ).

Lemma 2 (Conflict-Free Liveness). The basic head protocol achieves Conflict-Free live-
ness.

27
Proof. We demonstrate that a transaction tx issued by a player pi will eventually be confirmed by
every player pj . By conflict-freeness, in (new, tx) we have that Li ◦ tx 6= ⊥.
Assume that tx ∈ / C j , i.e., that pj has not seen tx confirmed yet. As soon as pj enters (or gets
reactivated from the wait queue) (reqTx, tx) under the condition Lj ◦tx 6= ⊥ (eventually guaranteed
by Invariant 1), by conflict-freeness, also L̂j ◦ tx 6= ⊥ holds, and pj acknowledges the transaction.
Thus, every pj eventually acknowledges the transaction, and tx ∈ ∩i∈[n] C i .

Invariant 2. Consider an arbitrary uncorrupted party pi . Let T̃ be the set corresponding to

SNcur,i . Then, T̃ ∪ T i = C i , where T i is the set T of pi .
Proof. Observe that the invariant is trivially satisfied at the onset of the protocol’s execution.
Furthermore, each time a new transaction is confirmed via confTx, both T i and C i grow by the
newly confirmed transaction, while T̃ remains unchanged.
The only other time one of the sets T̃, T i , or C i change is when a new snapshot is confirmed
via confSn. In such a case, note that C i stays the same while any transaction removed from T i is
considered by the new snapshot and thus added to T̃. Hence, the invariant is still satisfied.

Invariant 3. T̃0 ⊆ T̃1 ⊆ T̃2 ⊆ . . ..

Proof. Let pi be an honest party. It is easily seen that the set of transactions considered by a new
snapshot always includes the set considered by the previous snapshot since the set of transactions
T in a reqSn satisfies that SNcur,i ◦ ReachT i (T ) 6= ⊥, (this is implied by Invariant 2).

Invariant 4. Cchain grows monotonically (w.r.t. ⊆).

Proof. Consider operation Contest(Kagg , η, ξ) and let η = (Uη , sη , Tη ) and ξ = (U, s, σ̃, T ). Note
that before the operation Cchain = T̃sη ∪ Tη . Consider now the set T ∗ in the output (·, ·, T ∗ ) of
Contest. Note that after the operation Cchain = T̃s ∪ T ∗ . Observe that:
• Since s ≥ sη , Invariant 3 implies that a transaction tx ∈ T̃sη is also in T̃s .
• If a transaction tx ∈ Tη is not in T ∗ , then s > sη and the transaction is consumed by the
snapshot with number s, i.e., tx ∈ T̃s .
Hence, Cchain grows monotonically.

Invariant 5. For all i ∈ Hcont , C i ⊆ Cchain .

Proof. Take any honest party pi and let s̃ be the current snapshot number at pi , i.e., SNcur,i = T̃s̃ .
Recall that, by Invariant 2, C i = T̃s̃ ∪ T i . Consider a close or contest operation by pi as well as the
output (U, s, T ∗ ) of Contest, and observe that after the operation Cchain = T̃s ∪ T ∗ . By Invariant 3,
T̃s̃ ⊆ T̃s and, by a similar argument as in the proof of Invariant 4, if tx ∈ T i is not in T ∗ , it must
be in T̃s . Hence, C i ⊆ Cchain . Furthermore, since Cchain grows monotonically (Invariant 4), the
invariant remains satisfied.

Invariant 6. For all uncorrupted parties pi , ∪j∈[n] C j ⊆ Ŝi .

Proof. Honest parties will only output (conf, tx) if there exists a valid multisignature for tx, which
implies that each honest party output (seen, tx) just before they signed tx.
T
Invariant 7. For any j, T̃j ⊆ i∈H C i .

28
Proof. Only transactions that have been seen as confirmed by all honest parties can ever be included
in a confirmed snapshot.
T
Invariant 8. Cchain ⊆ i∈H Ŝi .

Proof. Let η = (U, s, T ). Observe that Cchain = T̃s ∪ T . Consider a transaction tx ∈ Cchain .
T T
• If tx ∈ T̃s , then tx ∈ i∈H C i ⊆ i∈H Ŝi by Invariants 7 and 6.
T
• If tx ∈ T , then tx ∈ i∈H Ŝi since no transaction can be confirmed without being seen by all
honest parties.

Lemma 3 (Soundness). The basic head protocol satisfies the Soundness property.

Proof. Let η = (U, s, T ) be the value of η just before applying Final(η, Ufinal ). Clearly, the only set
Ufinal that will be accepted by Final is U0 ◦ (T̃s ∪ T ). By definition T̃s ∪ T = Cchain . Soundness now
follows from Invariant 8.

Lemma 4 (Completeness). The basic head protocol satisfies the Completeness property.

Proof. Follows from Invariant 5 and an argument similar to that in the proof of Lemma 3.

7 Simulations
We will now investigate the performance of the Hydra protocol in terms of both latency (transaction
settlement time) and throughput (rate of transaction processing), using simulations.
The simulations will demonstrate that Hydra is optimal in achieving fast transaction settlement.
By comparing to theoretical limits, we will also show that producing snapshots does not slow down
transaction confirmation or reduce transaction throughput in any significant way.
In order to determine how quickly transactions settle in Hydra, and at which rate they can be
processed, we have to consider the following factors:

Opening and closing of a head. This consists of creating and submitting the commit/decommit
transactions, and waiting until they are confirmed to be in the chain.

The performance of the head protocol. Given a geographical distribution and CPU/network
capacity of the head nodes, how long does it take to exchange the messages that lead to transactions
and snapshots being confirmed?

Limitations on in-flight transactions. When a player wants to send two transactions, where
one uses the change from the other, they have to defer sending the second transaction until they
have confirmation for the first. Furthermore, players may want to prevent an excessive number of
confirmed, but not snapshotted transactions to keep decommits smaller. Together, this limits the
number of in-flight (submitted but not yet confirmed) transactions that any one node can have.

29
The value at risk. To minimize this, players may wait for some transactions to be confirmed
before sending more transactions, further limiting the number of in-flight transactions.
Since the time for opening and closing a head is largely dependent on the underlying layer-
one protocol and can be amortized over the head’s lifetime, we do not cover this aspect in our
simulations. Furthermore, to simplify the simulations, we model the effect of a finite UTxO by
directly limiting the number of in-flight transactions per node. Thus, we focus the simulations
on the execution of the head protocol, as specified in Fig. 9. In the following, we will describe
how we implemented the simulations for the head protocol. The implementation is available at
https://github.com/input-output-hk/hydra-sim.

7.1 Simulation implementation

We model the head nodes using concurrent threads which exchange the protocol messages from
Fig. 9 via channels. We use the io-sim library [2], which allows us to write concurrent code, and
then either execute it directly as threads in the Haskell runtime system, or run the same code in a
simulation of the runtime system. The latter yields an execution trace of the code very quickly, as
it delays a thread by just increasing a number representing the thread’s clock, instead of actually
pausing the thread. As we describe below, the simulations make heavy use of thread delays, so this
allows us to perform simulations much more quickly. We can also manually insert trace points at
relevant points in the protocol (such as when a transaction is confirmed). Measuring, for instance,
the confirmation time for a message, can then be done by simply subtracting timestamps of the
events “transaction is submitted” (new) and “transaction is confirmed” (confTx).

Cryptographic Operations. Instead of using real cryptographic functions for multisignatures,

we use mock functions that do not perform any calculations, but instead allow for a tunable delay
of the thread that is performing the operation.

Message Propagation. Before being sent across the network, each message has to be serialized
and pass the networking interface, which takes time linear in the message size. So the event of
a message being sent by a node does not correspond to a single point in time, but rather to a
time interval. We take that into account by modeling each message by its leading and trailing
edge. The time distance between leading and trailing edge—the serialization delay—of a message
is determined by its size and the bandwidth of the node’s networking interface. We capture this with
a parameter S, giving the delay per byte. Furthermore, we take into account that the networking
interface can only start sending the next message after the trailing edge of the previous message
has been sent. When the network is sufficiently busy, this can be a point of contention.
We model the network by a delay G between each message edge leaving the sending node and its
arrival at the target node. The parameter G is determined by the distance between the two nodes
and is independent of message size.6 We use real data measured between Amazon Web Services
data centers.
Once the leading edge of a message reaches the receiving node, we put its incoming networking
interface into a busy state, for a time given by the size of the message and the bandwidth of this
6
The messages in the Hydra protocol are small enough to ignore TCP window effects that would introduce a
dependency on the message size.

30
node. Finally, when the trailing edge is received, the message contents is placed into the local
inbox, so that the node can start acting on the message.
If we only consider a single message, this model will just lead to a delay of the whole message
determined by G, the message size, and S of the slower node. But once we have multiple messages
in the system, it also correctly accounts for the contention at the outgoing and incoming connection
points. The contention introduces variance, since messages may or may not have to wait at either
end of the network.

7.2 Simulation optimizations

We applied two refinements that optimize the performance without changing the security of the
protocol.

• First, when submitting a new transaction via new, a node will validate the transaction, and
then send reqTx to every party, including itself. Every party, upon receiving reqTx, will then
validate the transaction again. For the sending node, this is not necessary (it just validated
the same transaction), so we skip the second validation on the same node.
• Second, the specification of the protocol states that handlers are executed strictly one after
the other. Avoiding concurrency in this way simplifies the analysis of the protocol. But
there is one case where we can safely perform actions in parallel: upon receiving reqTx (and
similarly reqSn), a node will validate the transaction or snapshot against its local state, and,
if appropriate, sign it and reply. The action of signing does not access the state of the node,
so we can safely perform it concurrently with handling subsequent events.

These are fairly trivial changes, that any concrete implementation would apply, so we felt it
was appropriate to reflect them in our simulations.

7.3 Scenarios
We consider networks with varying geographic distributions: 1) local deployment of three nodes
within the same AWS region, 2) continental deployment across multiple AWS regions on the same
continent (Ireland, London, and Frankfurt), and 3) global deployment (Oregon, Frankfurt, and
Tokyo). For each configuration, we load the network with transactions, and measure the confir-
mation time for individual transactions as well as the throughput in terms of transactions per
second.
In addition, we also vary (a) the bandwidth that each party allocates to running the head
protocol and (b) the maximal transaction concurrency. For concurrency = 1, any node will submit
a single transaction, and wait until that transaction is confirmed before sending the next. For
concurrency = n, each participant will submit a batch of n transactions, and then send another
one whenever one of their transactions is confirmed.
During the simulations, nodes perform aggressive snapshotting, where a round-robin schedule
determines the next node to snapshot. This next node will produce a snapshot as soon as it has at
least one confirmed transaction that is not included in a previous snapshot.
The numerical results depend on a number of parameters that we set, representing the time
that elementary operations within the protocol take. We use the settings described below.

31
Transaction size. We use two representative transaction types: (1) simple UTxO transactions
with two inputs and two outputs, whose size is 265 bytes, and (2) script transactions containing
larger scripts occupying an extra 10 kbytes. We use transaction references of 32 bytes. For each
message, we allow for a protocol-level overhead of 2 bytes.

Transaction validation time. This is the CPU time that a single node will expend in order to
check the validity of a transaction. We use conservative values here: 0.4 ms for simple transactions,
and 3 ms for script transactions.

Time for multisignature operations. We performed benchmarks for the multisignature scheme [11]
resulting in the following estimates: 0.15 ms for MS-Sign, 0.01 ms for MS-ASig, and 0.85 ms for
MS-AVerify.

7.4 Baselines
Instead of just producing bare numbers for transaction throughput and confirmation times, we want
to compare our experimental results to theoretical limits that capture the optimal performance,
given the physical constraints of a distributed system. For that, we use the following two baseline
scenarios:

Full Trust. To quantify the price we pay for consensus in Hydra, we compare our simulations
with a scenario where we assume perfect trust between all participants; i.e., we only distribute the
knowledge on transactions, without trying to achieve consensus.
In this scenario, nodes submit transactions (after checking that they are valid). Other nodes
just acknowledge that they have seen them (without validating or signing them). We still consider
the effect of having a finite transaction concurrency.
The transaction throughput is thus limited by the computational power (but there will only be
transaction validation, no signing or verifying of signatures). It is also limited by the bandwidth
(though the messages for acknowledging a transaction are smaller since they do not contain a sig-
nature). The third bound is determined by the distance between nodes, divided by the transaction
concurrency.
This baseline sets an upper limit for the transaction throughput of any protocol that distributes
and validates transactions in a distributed system. Furthermore, for any consensus protocol, we
should expect some additional overhead (which might or might not reduce the actual throughput
in different regions of the parameter space).

Hydra Unlimited. In this scenario, we look at how the head protocol would perform in an
idealized setting, ignoring some real world practical limitations. In particular, we assume not being
limited to sending a finite number of transactions concurrently. This allows us perfectly amortize
the network round trip times, so we can effectively ignore the distance between nodes. Thus, the
maximal transaction rate is limited only by the bandwidth and CPU power that each node allocates
to run the protocol. Furthermore, we also ignore the cost of performing snapshots.
This sets a limit on the transaction rate for a Hydra-like protocol. In particular, we should
expect to approach this limit only when

32
 • the resource cost of producing snapshots is low (compared to the cost of the rest of the
protocol execution),

• there are no contention effects in the protocol that cause additional delays, and

• there are enough concurrent transactions to effectively amortize the network round-trip time.

For the optimal confirmation time, we assume that there is no contention, neither in the net-
working interfaces, nor on the CPU. So we get the minimal confirmation time by just adding up
the times of all the steps needed to confirm a transaction, assuming that there is zero time spent
waiting in between. Note that this is the optimal confirmation time that any protocol can hope
to achieve, since each of the steps (sending the transaction, validating and signing it on the other
side, sending it back, and verifying the signature) is essential and all of them must be carried out
sequentially.
In summary, this baseline lets us determine how well we approach the physical limits for

• the confirmation time for any protocol, and

• the transaction throughput for a protocol like Hydra, where transactions are signed by every
participant in order to guarantee consensus.

7.5 Transaction throughput

Concerning transaction throughput for the Hydra Unlimited baseline, the limit will rise linearly
with the bandwidth, until the point where we are no longer limited by bandwidth. At this point,
allocating more bandwidth will not change anything, since we are purely CPU bound, and the
limit will stay constant. Since we assume that we can amortize latency perfectly, this limit will not
depend on the geographic distribution at all—it is simply given by the inverse of the transaction
validation time plus the time to verify an aggregate signature.
Similarly, for the Full Trust baseline, we will have a linear increase for low bandwidth (though
the limit is a little larger than for Hydra Unlimited, since the acknowledgment does not contain a
signature and thus needs less bandwidth). Also, the CPU limit is higher, since we do not validate
aggregate signatures. But since we take the finite concurrency into account, we might not approach
the CPU bound, if the bound from the finite latency is lower. So in this scenario, the limit will
depend on the geographic distribution of the nodes.
By juxtaposing the simulations results with the limits from the baseline scenarios, we can not
only see which transaction rates we can expect, but also how close we can get to an ideal estimate
that neglects the cost of snapshotting, network contention, and network distance (Hydra Unlimited ),
and which price we are paying for consensus in Hydra (Full Trust).
Figs. 13 and 14 display results for ordinary UTxO and script transactions, respectively. We
observe the following:

• The low latency of a single-region or continental cluster is easily hidden, even with low
transaction concurrency, allowing us to get close to the Hydra Unlimited optimum.
• The relative price for consensus (distance to Full Trust) decreases with increasing work needed
to distribute transactions (either by having a larger distance between the nodes or by having
more complex transactions).

33
 Figure 13: Transaction rates for the Hydra head protocol, compared with the baseline scenarios
from Section 7.4. Simple UTxO transactions with 2 inputs and 2 outputs.

Figure 14: Transaction rates for the Hydra head protocol, compared with the baseline scenarios
from Section 7.4. Script transactions.

• The cost of producing snapshots aggressively is generally quite low. This is not surprising,
as computing the snapshots is done locally, and very little information about the actual
snapshots needs to be exchanged. Furthermore, computing the snapshots does not involve
validating transactions or checking signatures, but just following the UTxO graph.
• When we are able to amortize latency via concurrency (for the single region and continental
clusters, and concurrencies per node of 10), we get within 95 % of the Hydra Unlimited
baseline. For the global cluster, though, the roundtrip times are too large to be completely
amortized (unless we go to unrealistically high concurrencies).
• The more work we have to do to distribute transactions across the network—the larger the
transactions, the more time needed to validate them, and the longer the roundtrip times—the
smaller is the impact of enforcing consensus with Hydra. E.g., if we look at script transactions

34
 Figure 15: Confirmation times for simple UTxO transactions, in a cluster located in one AWS
region. From panel to panel, we increase the transaction concurrency. The theoretically minimal
confirmation time is represented by a dashed line.

in a global network, we get within 92 % of the Full Trust baseline.

7.6 Transaction confirmation times

One aspect where Hydra really shines is fast settlement: as soon as all parties have signed a trans-
action, and the sending node has aggregated a valid multisignature, this multisignature provides
a guarantee that the transaction can be included into the ledger of the layer-one system. We can
derive a minimal confirmation time using the Hydra Unlimited baseline:7 if there is no contention
on any resource,8 we can just add up the times for validating a transaction two times (once at the
issuing node, once at every other node), sending the reqTx and ackTx messages across the longest
path in the network, and creating and validating the aggregate signature.
Fig. 15 illustrates the conditions under which we achieve minimal confirmation time. In the first
panel, we have a transaction concurrency of one. We see that, with enough bandwidth, we get very
close to the minimal validation time (dashed line). In the other panels, we increase the concurrency.
While this increases the total transaction throughput by sending transactions in parallel, individual
transaction are more likely to be slowed down by congestion in the networking interfaces. Hence,
confirmation time and its spread increase.
In clusters across different regions, the confirmation time generally depends on which node
sent the transaction. For example, in Fig. 16, we see that the transactions from Oregon tend to
get confirmed faster than those from Frankfurt or Tokyo. This is because confirmation requires a
roundtrip to the farthest peer, and Frankfurt and Tokyo are farther away from one another than
either of them is from Oregon.
We see that even for script transactions and a globally distributed network, we consistently
achieve settlement well below half a second if we provide enough bandwidth.
7
We do not compare to Full Trust. Confirmation time is a measure for achieving consensus on a single transaction,
which is irrelevant for Full Trust.
8
Amortizing latency is irrelevant for single transaction confirmation time.

35
 Figure 16: As Fig. 15, but for script transactions in a cluster spanning the AWS regions Oregon,
Frankfurt, and Tokyo. Here, the minimal confirmation time depends on which node is sending
the transaction, so we have two optimal lines.

7.7 Larger clusters

In addition to three node clusters, we have also evaluated how the results depend on cluster size
by running simulations with clusters of up to 100 nodes (located in the same AWS region):

• The transaction rates of a larger cluster are close to those for a three node cluster. This is
due to the amount of computation per node per transaction not depending on the number of
participants9 .
• The bandwidth needed at each node to reach the maximal transaction rate does depend on
the cluster size. This is not surprising, since each node needs to communicate with more
peers.
• For the same reason, the confirmation time of transactions increases with the cluster size.

Note that these simulations still use a communication pattern where everyone sends messages to
everyone, which is not optimal for large clusters. Instead, we ought to construct a graph to broadcast
messages, keeping the number of peers for direct communication small for each participant. An
advantage of the Hydra approach is that we can easily have different versions of the head protocol,
or different implementations of the same head protocol, optimized for different cluster sizes.

7.8 Conclusions from simulations

Due to the way that consensus is achieved by getting confirmations from every participant, we
consistently achieve subsecond settlement, even for globally distributed heads.
9
Note that aggregating signatures and verifying an aggregate signature do depend on the number of participants.
However, this does not impact the transaction rates in our simulations, for three reasons: i) we assume that we
aggregate the verification keys once at the beginning of the head protocol, and only perform verification against
the already computed aggregate verification key during the protocol, ii) even for 100 participants, combining the
signatures is quicker than producing a single signature, iii) combining signatures is performed concurrently with the
rest of the protocol (see Section 7.2).

36
 More importantly than raw numbers are the comparisons with the theoretical limits from the
baselines scenarios of Section 7.4:

• Comparing transaction confirmation times with the Hydra Unlimited baseline demonstrates
that Hydra achieves near-optimal confirmation times consistently. When we allocate suffi-
cient networking resources, and choose a low concurrency (which does limit the transaction
throughput), we do get optimal confirmation times.

• Comparing with the same baseline, we see that we do not pay a significant cost for creating
snapshots, neither in terms of transaction throughput, nor in terms of confirmation time.
This is a crucial point: compared to other state channel protocols, Hydra utilizes the UTxO
parallelism to avoid having to sequentialize transactions. Snapshots are necessary for that
approach, since otherwise, the decommit transactions would become unwieldy. Seeing that
snapshots do not slow down the protocol in any significant way thus validates the design of
Hydra.

• As for transaction throughput, we see that we approach the limits in regions where we can
expect to. When the cost of achieving consensus via multisignatures is dominated by network
roundtrip times and transaction validation, we get close to the Full Trust scenario. When we
have enough parallelism to offset the roundtrip times, we do approach the Hydra Unlimited
case.

Besides demonstrating Hydra’s capability to perform efficiently, the simulations also allow op-
erators to get a handle on the network bandwidth they should provide in order not to impact the
head performance. They also show that there is a tradeoff between total transaction throughput
and individual transaction settlement time when increasing concurrency.

8 Acknowledgments
Aggelos Kiayias was supported in part by EU Project No.780477, PRIVILEDGE.

References
[1] Extended UTXO-2 model. https://github.com/hydra-supplementary-material/eutxo-
spec/blob/master/extended-utxo-specification.pdf.

[2] The io-sym library. https://github.com/input-output-hk/ouroboros-network/tree/

master/io-sim, https://github.com/input-output-hk/ouroboros-network/tree/
master/io-sim-classes.

[3] The Connext Network. https://docs.connext.network/en/latest/background/

architecture.html.

[4] John Adler. The why’s of optimistic rollup. https://medium.com/@adlerjohn/the-why-s-

of-optimistic-rollup-7c6a22cbb61a, November 2019.

[5] Ian Allison. Ethereum’s Vitalik Buterin explains how state channels address privacy and
scalability. International Business Times, 2017.

37
 [6] Nicola Atzei, Massimo Bartoletti, Stefano Lande, and Roberto Zunino. A formal model of
Bitcoin transactions. In Financial Cryptography and Data Security - 22nd International Con-
ference, FC 2018, Nieuwpoort, Curaçao, February 26 - March 2, 2018, Revised Selected Papers,
pages 541–560, 2018.

[7] Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller,
Andrew Poelstra, Jorge Timón, and Pieter Wuille. Enabling blockchain innovations with
pegged sidechains, 2014.

[8] Mihir Bellare and Gregory Neven. Multi-signatures in the plain public-key model and a general
forking lemma. In Ari Juels, Rebecca N. Wright, and Sabrina De Capitani di Vimercati, editors,
ACM CCS 2006, pages 390–399. ACM Press, October / November 2006.

[9] Bitcoin Wiki. Payment channels. Wiki article, accessed 2019-11-06.

[10] Guy E. Blelloch. Programming parallel algorithms. Communications of the ACM, 39:85–97,
1996.

[11] Alexandra Boldyreva. Threshold signatures, multisignatures and blind signatures based on
the gap-Diffie-Hellman-group signature scheme. In Yvo Desmedt, editor, PKC 2003, volume
2567 of LNCS, pages 31–46. Springer, Heidelberg, January 2003.

[12] Dan Boneh, Manu Drijvers, and Gregory Neven. Compact multi-signatures for smaller
blockchains. In Thomas Peyrin and Steven Galbraith, editors, ASIACRYPT 2018, Part II,
volume 11273 of LNCS, pages 435–464. Springer, Heidelberg, December 2018.

[13] Manuel M. T. Chakravarty, James Chapman, Kenneth MacKenzie, Orestis Melkonian,

Michael Peyton Jones, and Philip Wadler. The extended UTxO model. In 4th Workshop
on Trusted Smart Contracts, 2020. http://fc20.ifca.ai/wtsc/WTSC2020/WTSC20_paper_
25.pdf.

[14] Jeff Coleman, Liam Horne, and Li Xuanji. Counterfactual: Generalized state channels, 2018.

[15] Christian Decker and Roger Wattenhofer. A fast and scalable payment network with bit-
coin duplex micropayment channels. In Symposium on Self-Stabilizing Systems, pages 3–18.
Springer, 2015.

[16] Stefan Dziembowski, Lisa Eckey, Sebastian Faust, Julia Hesse, and Kristina Hostáková. Multi-
party virtual state channels. In Annual International Conference on the Theory and Applica-
tions of Cryptographic Techniques, pages 625–656. Springer, 2019.

[17] Stefan Dziembowski, Lisa Eckey, Sebastian Faust, and Daniel Malinowski. Perun: Virtual
payment hubs over cryptocurrencies. In 2019 IEEE Symposium on Security and Privacy (SP),
pages 106–123. IEEE, 2019.

[18] Stefan Dziembowski, Grzegorz Fabiański, Sebastian Faust, and Siavash Riahi. Lower bounds
for off-chain protocols: Exploring the limits of plasma. Cryptology ePrint Archive, Report
2020/175, 2020. https://eprint.iacr.org/2020/175.

38
[19] Stefan Dziembowski, Sebastian Faust, and Kristina Hostáková. General state channel net-
works. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communica-
tions Security, pages 949–966. ACM, 2018.

[20] Ethereum. Patricia tree, 2019. Github Repository.

[21] Matthias Fitzi, Daniel Gottesman, Martin Hirt, Thomas Holenstein, and Adam Smith. De-
tectable byzantine agreement secure against faulty majorities. In Aleta Ricciardi, editor, 21st
ACM PODC, pages 118–126. ACM, July 2002.

[22] P. Gaži, A. Kiayias, and D. Zindros. Proof-of-stake sidechains. In 2019 2019 IEEE Symposium
on Security and Privacy (SP), pages 677–694, Los Alamitos, CA, USA, may 2019. IEEE
Computer Society.

[23] Kazuharu Itakura and Katsuhiro Nakamura. A public-key cryptosystem suitable for digital
multisignatures. NEC Research & Development, (71):1–8, 1983.

[24] Aggelos Kiayias and Dionysis Zindros. Proof-of-work sidechains. IACR Cryptology ePrint
Archive, 2018:1048, 2018.

[25] Georgios Konstantopoulos. Plasma cash: Towards more efficient plasma constructions, 2019.

[26] Jeremy Longley and Oliver Hopton. Funfair technology roadmap and discussion, 2017.

[27] ScaleSphere Foundation Ltd. Celer network: Bring internet scale to every blockchain, 2018.

[28] Silvio Micali, Kazuo Ohta, and Leonid Reyzin. Accountable-subgroup multisignatures: Ex-
tended abstract. In Michael K. Reiter and Pierangela Samarati, editors, ACM CCS 2001,
pages 245–254. ACM Press, November 2001.

[29] Andrew Miller, Iddo Bentov, Surya Bakshi, Ranjit Kumaresan, and Patrick McCorry. Sprites
and state channels: Payment networks that go faster than lightning. In International Confer-
ence on Financial Cryptography and Data Security, pages 508–526. Springer, 2019.

[30] J. Poon and V. Buterin. Plasma: Scalable autonomous smart contracts. http://plasma.io/
plasma.pdf.

[31] Joseph Poon and Thaddeus Dryja. The bitcoin lightning network: Scalable off-chain instant
payments, 2016.

[32] Joachim Zahnentferner. An abstract model of UTxO-based cryptocurrencies with scripts.

IACR Cryptology ePrint Archive, 2018:469, 2018.

39
A Security of Multisignature Schemes
For convenience, our definition of a multisignature scheme given in Section 2 differs from the stan-
dard one in e.g. [8] by assuming the existence of separate algorithms MS-Sign and MS-ASig and
postulating that the way to produce a multisignature is that each party creates a local signature
via MS-Sign and these are then exchanged and combined using MS-ASig. This is no important de-
viation, as typical modern multisignature scheme (including the one we use in our simulations [11])
satisfy this pattern. Below we present a standard definition of multisignature security from [8, 12],
tailored to this special case.
A secure multisignature scheme needs to satisfy two properties: completeness and unforgeability.

Completeness. For any n, Π ← MS-Setup(1k ) and (vki , ski ) ← MS-KG(Π) for i = 1, . . . , n, for
any message m if we have σi ← MS-Sign(Π, ski , m), σ̃ ← MS-ASig(Π, m, {vki }ni=1 , {σi }ni=1 ), and
avk ← MS-AVK(Π, {vki }ni=1 ), then MS-Verify(Π, σ̃, m, avk) = true.

Unforgeability. This property is defined by a three-stage game:

1. Setup. The challenger runs Π ← MS-Setup(1k ), generates the challenge key pair (vk∗ , sk∗ ) ←
MS-KG(Π) and runs the adversary A(Π, vk∗ ).
2. Signing queries. A is allowed to make signing queries on any message m, i.e., A has access
to the signing oracle MS-Sign(Π, sk∗ , ·).
3. Output. Finally, A outputs a multisignature forgery σ̃ ∗ , a message m∗ and a set of verification
keys V ∗ . A wins if vk∗ ∈ V ∗ , A made no signing queries on m∗ , and

MS-Verify(Π, MS-AVK(Π, V ∗ ), m∗ , σ̃ ∗ ) = true .

We say that A is a (τ, q, ε)-forger for a multisignature scheme MS = (MS-Setup, MS-KG, MS-AVK,
MS-Sign, MS-ASig, MS-Verify) if it runs in time τ , makes q signing queries, and wins the above game
with probability at least ε. MS is (τ, q, ε)-unforgeable if no (τ, q, ε)-forger exists.

B Simple Head Protocol with Conflict Resolution

This section explains the differences between the basic head protocol from Section 6 and the head
protocol with conflict resolution; it also contains a corresponding security proof.

B.1 Description of the protocol

The head protocol with conflict resolution (CR) works much like the basic head protocol, except
that snapshots are also used to resolve conflicts among transactions. In the basic protocol, since
parties do not sign conflicting transactions, such conflicts would have to be settled on the mainchain
even if no head members are corrupted.
In the CR version of the head protocol (cf. Figure 17), each head member pi additionally
maintains a set R̂ of known transactions that conflict with a set TR ⊆ T̂ of transactions already
signed by pi . In the (likely) event that transactions in R̂ have also been signed off on by at least
one party, no transaction in TR ∪ R̂ can ever become confirmed with the basic confirmation flow

40
 Simplified Hydra Head Protocol With Conflict Resolution

on (init, i, K ver , Ksig , U0 ) from client on (close) from client

V ← K ver ↓(tx,σ̃)
return (U.U, U.s, U.σ̃, T )
avk ← MS-AVK(V)
sk ← Ksig on (cont, η) from client
ŝ, s ← 0 (Uη , sη , Tη ) ← η
Û, U ← snObj(0, U0 , ∅) if s ≤ s
L̂, L ← U0 U ← Uη
T̂ , T , R̂ ← ∅ s ← sη
σ̃ ← ε
on (new, tx) from client else
require valid-tx(tx) and L ◦ tx 6= ⊥ U ←U
multicast (reqTx, tx) s←s
σ̃ ← U.σ̃
on (newSn) for pi ↓(tx)
T 0 ← applicable(U, T ∪ Tη ) \ Tη
require leader(s + 1) = i and Û = U if U = Uη

↓(h)
T ← maxTxos(T ) U ←ε

↓(h) ↓(tx,σ̃)
TR ← conflict-tx(T̂ , R̂) return (U, s, σ̃, {t ∈ T | t.tx ∈ T 0 })
R ← R̂↓(h)
multicast (reqSn, s + 1, T, TR , R)

on (reqTx, tx) from pj on (reqSn, s, T, TR , R) from pj

require valid-tx(tx) ∧ tx ∈ / T̂ ∪ R̂ require s = s + 1 and leader(s) = j
↓(h)
if L̂ ◦ tx = ⊥ wait s = ŝ and T ⊆ T and TR ∪ R ⊆ (T̂ ∪ R̂)↓(h)
R̂ ← R̂ ∪ {txObj(j, tx)} T̃R ← (T̂ ∪ R̂)[TR ]
else R̃ ← (T̂ ∪ R̂)[R]
h ← H(tx) require ∀tx ∈ T̃R : conflict(R̃ ∪ {tx})
T̂ [h] ← txObj(j, tx) require ∀tx ∈ R̃ : conflict(T̃R ∪ {tx})
L̂ ← L̂ ◦ tx require ¬conflict(T ∪ T̃R )
wait L ◦ tx 6= ⊥ ŝ ← ŝ + 1
output (seen, T̂ [h]) forall h ∈ R̂↓(h) ∩ TR do
σi ← MS-Sign(sk, h) output (seen, R̂[h])
send (ackTx, h, σi ) to pj
Û ← snObj(ŝ, U.U, T, TR )
on (ackTx, h, σj ) from pj T̂ ← (T̂ ∪ T̃R ) \ R̃
require T̂ [h].i = i R̂ ← R̂ \ (R̃ ∪ T̃R )
require T̂ [h].S[j] = ε L̂ ← L ◦ T̂
T̂ [h].S[j] ← σj σi ← MS-Sign(sk, Û.hkŝ)
if ∀k : T̂ [h].S[k] 6= ε send (ackSn, ŝ, σi ) to pj
σ̃ ← MS-ASig(h, V, T̂ [h].S)
on (ackSn, s, σj ) from pj
if σ̃ 6= ⊥
require s = ŝ and leader(s) = i
multicast (confTx, h, σ̃)
require Û.S[j] = ε
on (confTx, h, σ̃) from pj Û.S[j] ← σj
tx ← T̂ [h].tx if ∀k : Û.S[k] 6= ε
if MS-Verify(avk, h, σ̃) σ̃ ← MS-ASig(Û.hks, V, Û.S)
if L ◦ tx 6= ⊥ ∧ Û ◦ tx 6= ⊥ if σ̃ 6= ⊥
L ← L ◦ tx multicast (confSn, s, σ̃)
T̂ [h].σ̃ ← σ̃
on (confSn, s, σ̃) from pj
T [h] ← T̂ [h]
require s = ŝ 6= s
T̂ ← T̂ \ T̂ [h]
if MS-Verify(avk, Û.hkŝ, σ̃)
output (conf, tx)
s←s
Û.σ̃ ← σ̃
U ← Û
forall h ∈ U.TR do
output (conf, (T̂ ∪ R̂)[h])
L ← L ◦ U.(TR )↓(tx)
T ← T \ ReachT (U.T )
T̂ ← T̂ \ U.TR

Figure 17: Head-protocol machine with conflict resolution for from the perspective of party pi .

based on multisignatures on transactions. To avoid this, whenever pi is snapshot leader, pi also

includes the sets of (hashes of) the transactions in TR and R ← R̂ in a reqSn message (in addition
to the set T of already confirmed transactions not included in any snapshot so far).

41
 The remainder of the snapshot process is changed (as compared to the basic protocol) to ensure
that transactions in TR become confirmed and transactions in R̂ are discarded. Specifically, a party
pi receiving a snapshot request reqSn first waits until he learns all transactions referenced by the
sets TR and R received from the snapshot leader pj . (Observe that parties may have different
local sets T̂ and R̂.) It then ensures that these sets are legitimate in that transactions in TR and
R indeed conflict. Furthermore, it checks that transactions in TR do not conflict with already
confirmed transactions. If these checks pass, pi updates his sets T̂ and R̂ to match those of the
snapshot leader pj . Function snObj—in addition to the snapshot number, the UTxO set of the
previous snapshot, and the set T of maximal confirmed transactions—now also takes as input the
set TR , and computes the UTxO set for the new snapshot Û as10

Û.U ← U.U ◦ (ReachT (T ) ∪ TR ) .

Party pi finally signs H(Û.U )kŝ and sends the signature to the snapshot leader pj .
The rest of the snapshot process is very similar to the one in the basic protocol, except that in
confSn, (conf, tx) is output for transactions referenced by TR ; these transactions are also removed
form the set T̂ and the execution of reqTx is stopped and discarded for all transactions conflicting
with TR (such executions would be stuck in the wait command forever).
Observe that if at least one party is corrupted, the CR version of the head protocol now allows
the adversary to create multisigned transactions that conflict with transactions confirmed via the
snapshot process. This occurs if an honest party pi signs a snapshot that includes in the set TR
(sent by the snapshot leader) a transaction tx0 in pi ’s R̂ set: tx0 being in R̂ means that pi has
already signed off on a transaction tx in conflict with tx0 . This results in a race condition between
the following two events:

• pi receives a multisignature of tx via confTx;

• pi signs off on the snapshot that includes tx0 .

Crucially, only one of these events must occur. To that end, in reqSn a party checks that the set
TR does not conflict with already confirmed transactions (in the fourth require statement) and
that (conf, tx) is only output before pi signs the new snapshot (the check Û ◦ tx 6= ⊥), i.e., if the
multisignature for tx arrives after the snapshot was signed, pi will simply drop it. Note that, in
case the above require fails for an honest party, snapshot production will stall as this snapshot
will never get confirmed. However, in this case, the head can be safely closed since the snapshot
leader is corrupted.

B.2 Security proof

Consider the random variables defined at the beginning of Section 6.4. The proof proceeds along
similar lines as that of the basic protocol with the additional consideration of the fact that different
(honest) parties might sign off transactions that conflict with each other due to race conditions.

Lemma 5 (Consistency). The head protocol with CR satisfies the Consistency property.
10
Recall that ReachT (T ) returns the transactions in T reachable (by following output references) from the trans-
actions (with hashes) in T .

42
Proof. Consider an arbitrary uncorrupted party pi and a transaction tx for which pi outputs
(conf, tx). Assume there exists a party pj such that tx conflicts with some tx0 ∈ C j . Consider the
following cases:

• Both tx and tx0 were confirmed via confTx. This cannot happen since that would imply that
honest parties signed reqTx messages for conflicting transactions.
• Transaction tx was confirmed via confTx and tx0 via confSn. This cannot happen since it
would imply that pi signed a snapshot conflicting with tx0 before outputting (conf, tx).
• Both tx and tx0 were confirmed via confSn. This cannot happen since transactions confirmed
via snapshots are checked for conflicts by a party before it signs the snapshot.

Invariant 9 (Snapshot-leader fault detection). If for any honest party, during (confTx), it
holds that L ◦ tx = ⊥ or Û ◦ tx = ⊥ then there is a faulty party.

Proof. If L ◦ tx = ⊥ then there must have abeen a snapshot leader who signed tx but resolved
a conflict of tx in favor of another transaction—against tx against the rule to prefer the signed
transaction. This behavior is faulty. The case Û ◦ tx = ⊥ implies faulty behavior of the current
snapshot leader in the same way.

Invariant 10 (Eventual mutual C inclusion). Consider the presence of a network adversary.

Then, given C i of party pi at any point in time, any party pj will eventually have C j ⊇ C i .

Proof. Any transaction added to C i during (confSn) will eventually be (or has been) added to C j
as the only guard in (confSn) relates to signature verification.
Any transation tx added to C i during (confTx) will eventually trigger (or has already triggered)
a respective (confTx) for party pj , and by the assumption that all parties are honest and by
Invariant 9, tx ∈ C j holds eventually.

In the following lemma we establish that, under control of a network adversary, new snapshots
continue being produced and confirmed. This property is not only required for the proof of liveness
but also demonstrates that old transactions can eventually be deleted.

Lemma 6 (Snapshot Liveness). Under presence of a network adversary, for any s > 0, a
snapshot with snapshot number s eventually gets confirmed.

Proof. We have to demonstrate that for any snapshot number s and party pi , the following condi-
tions eventually hold when pi enters the respective event-handler instance (reqSn, s, T, TR , R):
↓(h)
(1) T ⊆ T ∧ TR ∪ R ⊆ (T̂ ∪ R̂)↓(h)

(2) ∀tx ∈ T̃R : conflict(R̃ ∪ {tx}) ∧ ∀tx ∈ R̃ : conflict(T̃R ∪ {tx})

(3) ¬conflict(T ∪ T̃R )

43
 ↓(h) ↓(h)
On (1), T ⊆ T part. As the snapshot leader chooses T ⊆ T in (newSn) (and T ⊆ C), by
↓(h)
Invariant 10, every party pi will eventually observe T ⊆ T i ⊆ C i .
On (1), TR ∪ R ⊆ (T̂ ∪ R̂)↓(h) part. After entering (newSn), all transactions in tx ∈ TR ∪ R will
eventually have triggered (reqTx, tx) implying that TR ∪ R ⊆ (T̂ ∪ R̂)↓(h) .
On (2). As shown above, we have that TR ∪ R ⊆ (T̂ ∪ R̂)↓(h) . Once that condition is satisfied
then also ∀tx ∈ T̃R : conflict(R̃ ∪ {tx}) ∧ ∀tx ∈ R̃ : conflict(T̃R ∪ {tx}) by honesty of the snapshot
leader and the way he has to pick TR and R during (newSn).
On (3). If conflict(T ∪ T̃R ) then the snapshot leader resolved a conflict in favor of a transaction
tx ∈ T̃R such that conflict(T ∪ {tx}) implying that he also signed a transaction that conflicts tx, in
contradiction to the assumption that he is honest.

Invariant 11 (Local transaction liveness). Under presence of a network adversary, con-

sider any transaction tx issued by a party pi via (new). Then, eventually, either tx ∈ C i , or
conflict(tx, C i ).
·
Proof. After (new, tx), pi will eventually process tx by (reqTx, tx), and tx ∈ T̂ ∪ R̂ (symmetric
difference). Assume that never tx ∈ C i which, by assumption that all parties are honest and by
Invariant 9, implies that tx ∈ R̂j of at least one party pj . Consider the next snapshot produced by
pj . Since tx ∈ R̂j , there is a transaction tx0 ∈ T̂j with conflict({tx, tx0 }) that he adds to TR , and by
Lemma 6, eventually tx0 ∈ C k for every party pk .

Lemma 7 (Liveness). The head protocol satisfies Liveness.

Proof. By local transaction liveness and Invariant 10.

Invariant 12. Let T̃ be the set corresponding to SNcur,i . Then, T̃ ∪ T i = C i , where T i is the
(random variable corresponding to the) set T of pi .

Proof. Fix some party pi . Observe that the invariant is trivially satisfied at the onset of the
protocol’s execution. Furthermore, each time a new transaction is confirmed via confTx, both T i
and C i grow by the newly confirmed transaction, while T̃ remains unchanged.
The only other time one of the sets T̃, T i , and C i change is when a new snapshot is confirmed
via confSn. In such a case, note that

• any transaction removed from T i is considered by the new snapshot and thus added to T̃,
and
• any transaction added to C i is also considered by the new snapshot and thus added to T̃

Hence, the invariant is still satisfied.

Invariant 13. T̃0 ⊆ T̃1 ⊆ T̃2 ⊆ . . ..

Proof. Let pi be an honest party. It is easily seen that the set of transactions considered by a new
snapshot always includes the set considered by the previous snapshot since the set of transactions T
and TR in a reqSn satisfy that SNcur,i ◦(ReachT i (T )∪TR ) 6= ⊥, (this is implied by Invariant 12).

Invariant 14. If tx ∈ C i ∩ Cchain , it will remain there.

44
Proof. Consider operation Contest(Kagg , η, ξ) and let η = (Uη , sη , Tη ) and ξ = (U, s, σ̃, T ). Note
that Cchain = T̃sη ∪ Tη holds before the operation. Consider now the set T ∗ in the output (·, ·, T ∗ )
of Contest. Note that after the operation Cchain = T̃s ∪ T ∗ . Observe that:

• Since s ≥ sη , Invariant 13 implies that a transaction tx ∈ T̃sη is also in T̃s .

• If a transaction tx ∈ Tη is not in T ∗ but in C i , then s > sη and the transaction is consumed
by the snapshot with number s, i.e., tx ∈ T̃s . This is due to the fact that honest parties do
not sign snapshots contradicting confirmed transactions.

Invariant 15. For all i ∈ Hcont , C i ⊆ Cchain .

Proof. Take any honest party pi and let s̃ be the current snapshot number at pi , i.e., SNcur,i = U0 ◦T̃s̃ .
Recall that, by Invariant 12, C i = T̃s̃ ∪ T i . Consider a close or contest operation by pi as well as
the output (U, s, T ∗ ) of Contest, and observe that Cchain = T̃s ∪ T ∗ holds after the operation. By
Invariant 13, T̃s̃ ⊆ T̃s and, by a similar argument as in the proof of Invariant 14, if tx ∈ T i is not
in T ∗ , it must be in T̃s . Hence, C i ⊆ Cchain . Furthermore, by Invariant 14, the invariant remains
satisfied.

Invariant 16. C i ⊆ Ŝi .

Proof. Honest parties will only output (conf, tx) if there exists a valid multisignature for tx, which
implies that each honest party output (seen, tx) just before they signed tx.
T
Invariant 17. T̃j ⊆ i∈H C i .

Proof. Only transactions that have been seen confirmed by all honest parties can ever be included
in a snapshot.
T
Invariant 18. Cchain ⊆ i∈H Ŝi .

Proof. Let η = (U, s, T ). Observe that Cchain = T̃s ∪ T . Consider a transaction tx ∈ Cchain .
T T
• If tx ∈ T̃s , then tx ∈ i∈H C i ⊆ i∈H Ŝi by Invariants 17 and 16.
T
• If tx ∈ T , then tx ∈ i∈H Ŝi since no transaction can be confirmed without being seen by all
honest parties.

Lemma 8. The head protocol with CR satisfies the Soundness property.

Proof. Let η = (U, s, T ) be the value of η just before applying Final(η, Ufinal ). Clearly, the only set
Ufinal that will be accepted by Final is U0 ◦ (T̃s ∪ T ). By definition T̃s ∪ T = Cchain . Soundness now
follows from Invariant 18.

Lemma 9. The head protocol with CR satisfies the Completeness property.

Proof. The lemma from Invariant 15 and an argument similar to that in the proof of Lemma 8.

45
 𝖿𝗂𝗇𝖺𝗅𝗂𝗓𝖾
𝗂𝗇𝖼𝗋𝖾𝗆𝖾𝗇𝗍/𝖽𝖾𝖼𝗋𝖾𝗆𝖾𝗇𝗍

𝖼𝗅𝗈𝗌𝖾 𝖼𝗈𝗅𝗅𝖾𝖼𝗍𝖲𝖭
𝖼𝗈𝗅𝗅𝖾𝖼𝗍𝖧𝖳
𝖼𝗈𝗅𝗅𝖾𝖼𝗍𝖢𝗈𝗆 𝗈𝗉𝖾𝗇 𝖼𝗅𝗈𝗌𝖾𝖽 𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭
SN txs HT txs
⋯ ⋯

𝗂𝗇𝗂𝗍𝗂𝖺𝗅 𝖿𝗂𝗇𝖺𝗅
⋯ ⋯ ⋯
⋯ ⋯

commit txs
𝗌𝗉𝗅𝗂𝗍
⋯
⋯
⋯ ⋯ ⋯
⋯

𝖺𝖻𝗈𝗋𝗍

Figure 18: Mainchain state diagram with (a) incremental commits and decommits, (b) opti-
mistic finalize, and (c) parallel contestation phase.

Ideas:
C Full Mainchain State Machine
- close: provide hash of SN
- newerSN: can provide newer SN
- allocate: take newest SN and provide hanging txs
This -section outlines
addTxs: provide thehanging
missing followingtxs additions to the basic protocol:
- fanout: compute hash of final UTxO set
- split: provide particular part of final UTxO set
• Incremental commits and decommits: These allow head members, while the head is open, to
(1) commit new UTxOs to the head and (2) remove UTxOs from the head.
• An optimistic finalization procedure: If all head members agree to close a head, this procedure
allows a single-transaction head finalization.
• A more efficient way to close a head: For the cases where the head is closed due to a slow
network and/or corrupted head members, this procedure allows to close the head with a short
contestation period. Moreover, the new closure procedure is designed in a way that keeps the
size of the mainchain transactions small.

The state diagram corresponding to the full mainchain state machine (SM) is depicted in Figure 18.
The transactions used to implement the above features are explained in Section C.1 and make
use of additional on-chain verification (OCV) algorithms Increment, Decrement, Finalize, Snapshot,
ValidSN, ValidHT, and Fanout as well as modified Close and Final. The additional OCV algorithms
as well as changes to the head protocol are explained in Section C.3, after defining a variant of
so-called Merkle-Patricia trees in Section C.2.

C.1 New mainchain transactions

C.1.1 Incremental (de)commits
In the basic protocol, UTxOs can only be committed to a head before it reaches the open state.
Once the head is running, no additional UTxOs can be added to it. Similarly, the only way of
freeing up UTxOs in the head and make them available for spending on the mainchain is to close

46
 tx≡: check that
1. π𝖬𝖳 is proof that k′ is

Increment contained in h𝖬𝖳

2. η = 𝖨𝗇𝖼𝗋𝖾𝗆𝖾𝗇𝗍(η, U)
where U are added
UTxOs

𝗈𝗉𝖾𝗇, K𝖺𝗀𝗀, η, 𝗂𝗇𝖼𝗋𝖾𝗆𝖾𝗇𝗍 𝗈𝗉𝖾𝗇, K𝖺𝗀𝗀, η′,

h𝖬𝖳, n, T π𝖬𝖳 h𝖬𝖳, n, T
{p1, …, pn} ∪ 𝗏𝖺𝗅 {p1, …, pn} ∪ 𝗏𝖺𝗅′
ρ

⋮
commited output o

𝗏𝖺𝗅′′, ν, δ
(r𝗆𝗂𝗇, r𝗆𝖺𝗑) (r′𝗆𝗂𝗇, r′𝗆𝖺𝗑)

Signed: k Signed: k′

tx≡: check that

Decrement
Figure 19: collectCom/increment/decrement transaction (left) π with h increment transaction
k′ 1. 𝖬𝖳 is proof that is
contained in 𝖬𝖳
(right). η = 𝖣𝖾𝖼𝗋𝖾𝗆𝖾𝗇𝗍(K , ξ, U) 2. 𝖺𝗀𝗀

𝗈𝗉𝖾𝗇, K𝖺𝗀𝗀, η, 𝖽𝖾𝖼𝗋𝖾𝗆𝖾𝗇𝗍 𝗈𝗉𝖾𝗇, K𝖺𝗀𝗀, η′,

h𝖬𝖳, n, T π𝖬𝖳, ξ h𝖬𝖳, n, T
{p1, …, pn} ∪ 𝗏𝖺𝗅 {p1, …, pn} ∪ 𝗏𝖺𝗅′

(r𝗆𝗂𝗇, r𝗆𝖺𝗑)
⋮

(r′𝗆𝗂𝗇, r′𝗆𝖺𝗑)
}<latexit sha1_base64="WxxOLoH8qvPV+BjLCZ5YgtKmayM=">AAAB/XicdVDLSgNBEOz1GeMr6tHLYBA8hd0o6DHoxWMU84BkCbOT2WTIzO4y0yuEJfgDXvUPvIlXv8Uf8DucJHvQBAsaiqpuqqkgkcKg6345K6tr6xubha3i9s7u3n7p4LBp4lQz3mCxjHU7oIZLEfEGCpS8nWhOVSB5KxjdTP3WI9dGxNEDjhPuKzqIRCgYRSvddye9UtmtuDOQZeLlpAw56r3Sd7cfs1TxCJmkxnQ8N0E/oxoFk3xS7KaGJ5SN6IB3LI2o4sbPZp9OyKlV+iSMtZ0IyUz9fZFRZcxYBXZTURyaRW8q/ufhUC2kY3jlZyJKUuQRm4eHqSQYk2kVpC80ZyjHllCmhf2fsCHVlKEtrGiL8RZrWCbNasU7r1TvLsq167yiAhzDCZyBB5dQg1uoQwMYhPAML/DqPDlvzrvzMV9dcfKbI/gD5/MH32SV5A==</latexit>
U

Signed: k Signed: k′

Figure 20: collectCom/increment/decrement transaction (left) with decrement transaction

(right).

the head. Incremental commits and decommits allow arbitrary UTxOs to be added and removed
from the head, respectively, while the head is open.

Incremental commit. In order to add UTxOs to the head, a head member may post an in-
crement transaction (cf. Figure 19), causing a state transition from open to itself. The increment
transaction can have any number of inputs (but at least one) that consume the newly committed
outputs. Let U be the set of such outputs o; OCV function Increment processes this information
and outputs an updated head status η 0 ← Increment(η, U ).

Incremental decommit. A head member wishing to make UTxOs inside the head available
on the mainchain posts a decrement transaction (cf. Figure 20), again causing a transition from
open to itself. The decrement transaction can have any number of outputs (but at least one)
that make the newly decommitted outputs available on the mainchain. Let U be the set of such
outputs; OCV function Decrement processes this information along with a certificate ξ created by
the head members to permit the decommit operation. Decrement outputs an updated head status
η 0 ← Decrement(Kagg , η, ξ, U ); it may also output ⊥, but in order for a close transaction to be valid
η 0 6= ⊥ is required.

C.1.2 Optimistic head closure

If all head members agree that a head should be closed, the close/contestation phase can be foregone,
and, by posting a finalize transaction (cf. Figure 21), the head SM can be made to go from the open

47
 Note: finalize can also split UTxOs if needed
Finalize tx≡: check that
1. π𝖬𝖳 is proof that k′ is
contained in h𝖬𝖳
2. 𝖥𝗂𝗇𝖺𝗅𝗂𝗓𝖾(η, ξ, U)

𝗈𝗉𝖾𝗇, K𝖺𝗀𝗀, 𝖿𝗂𝗇𝖺𝗅𝗂𝗓𝖾

𝖿𝗂𝗇𝖺𝗅
η, h𝖬𝖳, n, T π𝖬𝖳, ξ

{p1, …, pn} ∪ 𝗏𝖺𝗅 ∅

(r𝗆𝗂𝗇, r𝗆𝖺𝗑)
⋮

(r′𝗆𝗂𝗇, r′𝗆𝖺𝗑)
}
<latexit sha1_base64="WxxOLoH8qvPV+BjLCZ5YgtKmayM=">AAAB/XicdVDLSgNBEOz1GeMr6tHLYBA8hd0o6DHoxWMU84BkCbOT2WTIzO4y0yuEJfgDXvUPvIlXv8Uf8DucJHvQBAsaiqpuqqkgkcKg6345K6tr6xubha3i9s7u3n7p4LBp4lQz3mCxjHU7oIZLEfEGCpS8nWhOVSB5KxjdTP3WI9dGxNEDjhPuKzqIRCgYRSvddye9UtmtuDOQZeLlpAw56r3Sd7cfs1TxCJmkxnQ8N0E/oxoFk3xS7KaGJ5SN6IB3LI2o4sbPZp9OyKlV+iSMtZ0IyUz9fZFRZcxYBXZTURyaRW8q/ufhUC2kY3jlZyJKUuQRm4eHqSQYk2kVpC80ZyjHllCmhf2fsCHVlKEtrGiL8RZrWCbNasU7r1TvLsq167yiAhzDCZyBB5dQg1uoQwMYhPAML/DqPDlvzrvzMV9dcfKbI/gD5/MH32SV5A==</latexit>
U

Signed: k Signed: k′

Burn {p1, …, pn} :: 𝖼𝗂𝖽

Figure 21: collectCom/increment/decrement transaction (left) with finalize transaction (right).

state to the final state right away. The final transaction must have outputs that correspond to the
final head state as agreed upon by the parties. To that end, OCV predicate Finalize(η, Kagg , U, ξ)
checks the transaction’s output set U against a special certificate ξ provided by the redeemer and
the information recorded in η. The certificate ξ consists of a multisigned value h||“final”, where
h is the hash of the final UTxO set. The finalize transaction is only valid if Final outputs true.
Moreover, all participation tokens must be burned.

C.1.3 Efficient contestation phase

Recall that in the simple protocol, in order to terminate a head, some party p first posts a close
transaction, which also contains information about the current head state. In a subsequent se-
quential contestation phase, each party is given the opportunity to supply more recent information
in case p’s information was outdated or p is corrupted. In the worst case, this process requires
a sequence of n mainchain transactions. In order to avoid this issue, a more involved parallel
contestation phase can be used to close out a head.
This parallel contestation phase is tailored to the actual head protocol in use (cf. Section 6) in
that it first collects—in parallel—proposals for the most recent snapshot and thereafter—also in
parallel—so-called hanging transactions, which are the confirmed head transactions that have not
yet been considered by a snapshot. The reason for executing a head closure in two steps is that
collecting snapshots first prevents a corrupted head member from posting a very old snapshot along
with a large number of hanging transactions.
Thus, to close a head, a close transaction is posted by some head member. The close transac-
tion has n outputs—one for each head member—to which SN transactions can be attached. An
SN transaction allows a head member to post (information about) the newest snapshot to the
mainchain. The subsequent transaction, the collectSN transaction, collects all SN transactions
and picks the most recent snapshot. It has n outputs as well, to which each party may attach a
HT transaction. Each HT transaction allows a head member to post (information about) hanging
transactions. Finally, the collectHT transaction collects all HT transactions and determines the
final UTxO set. The collectHT transaction also determines how to spilt the final UTxO set and
provides sufficiently many outputs for split transactions to be attached, where each split transaction
has as outputs a subset of the final UTxO set.

48
 tx≡: check that
1. π𝖬𝖳 is proof that k′ is

Close contained in h𝖬𝖳

2. (η′, β′1, …, β′n) = 𝖢𝗅𝗈𝗌𝖾(η, ξ)
3. k1 to kn are in h𝖬𝖳
4. T𝗌𝗇𝖺𝗉𝗌𝗁𝗈𝗍 = r′𝗆𝖺𝗑 + T

𝖼𝗅𝗈𝗌𝖾𝖽,
𝗈𝗉𝖾𝗇, K𝖺𝗀𝗀, 𝖼𝗅𝗈𝗌𝖾
K𝖺𝗀𝗀, η′, h𝖬𝖳, n, Information in β′i allows
η, h𝖬𝖳, n, T π𝖬𝖳 to check SN proposals
T, T𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭 immediately (as

{p1, …, pn} ∪ 𝗏𝖺𝗅 𝗏𝖺𝗅

opposed to only upon
allocate)

{p1}, ν𝖼𝗅𝗈𝗌𝖾𝖽, (k1, β′1)

⋮ ⋮

{pn}, ν𝖼𝗅𝗈𝗌𝖾𝖽, (kn, β′n)

(r𝗆𝗂𝗇, r𝗆𝖺𝗑) (r′𝗆𝗂𝗇, r′𝗆𝖺𝗑)

Signed: k Signed: k′

Figure 22: collectCom/increment/decrement transaction (left) with close transaction (right).

NewerSN Txs
ν𝖼𝗅𝗈𝗌𝖾𝖽: check that
1. 𝖵𝖺𝗅𝗂𝖽𝖭𝖲𝖭(β1, ξ1, ρ1)
or
𝖼𝗅𝗈𝗌𝖾𝖽, 1. next transaction is
allocate SM
K𝖺𝗀𝗀, η, h𝖬𝖳, n,
T, T𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭
𝗏𝖺𝗅
{p1}, ν𝖼𝗅𝗈𝗌𝖾𝖽, (k1, β1) SN transaction

⋮ ρ1 {p1}, ν𝖲𝖭, ξ1
{pn}, ν𝖼𝗅𝗈𝗌𝖾𝖽, (kn, βn) Signed: k1

(r𝗆𝗂𝗇, r𝗆𝖺𝗑)
ν𝗇𝖾𝗐𝖾𝗋𝖲𝖭: check that
1. next transaction is
Signed: k allocated SM

Figure 23: close transaction (left) with SN transaction (right).

Initiating head closure. In order to close a head, a head member may post the close transaction
(cf. Figure 22), which results in a state transition from the open state to the closed state. Compared
to the basic protocol, the poster is not required to provide any information about the status of the
head at this point. Instead, the close transaction has n outputs locked by validator νclosed . The ith
output has (ki , βi0 ) in its data field, where k1 , . . . , kn are the public keys that are hashed in hMT and
the βi0 contain information required by OCV algorithm ValidSN to verify the SN transactions posted
(see below). Specifically, they are created by OCV algorithm (η 0 , β10 , . . . , βn0 ) ← Close(Kagg , η),
which is also allowed to update the head status. Observe that the close transaction also places the
n participation tokens in the outputs.
Validator νclosed ensures the following: either the output is consumed by

1. an SM collectSN transaction (see below) or

2. an SN transaction (identified by having validator νSN in its only output), and

(a) the transaction is signed by ki ,

(b) OCV algorithm ValidSN(βi0 , ξi , ρi ) returns true, where ξi and ρi —in the SN transac-
tion’s output data field resp. redeemer—contain snapshot information (see below and
Figure 23).

Once a close transaction has been posted, an SN-posting period begins which should last at
least T slots. Hence, the last slot TnewestSN of said period is recorded in the state, and it is ensured
0
that TnewestSN ≥ rmax + T.

49
 tx≡: check that

Collect
1. π𝖬𝖳 is proof that k′ is contained in h𝖬𝖳
2. (η′, β′1, …, β′n) = 𝖲𝗇𝖺𝗉𝗌𝗁𝗈𝗍(η, ξ1, …, ξn)
3. r′𝗆𝗂𝗇 ≥ T𝗌𝗇𝖺𝗉𝗌𝗁𝗈𝗍
4. T𝖿𝗂𝗇𝖺𝗅 = r′𝗆𝖺𝗑 + T

𝖼𝗅𝗈𝗌𝖾𝖽, 𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭,
𝖼𝗈𝗅𝗅𝖾𝖼𝗍𝖲𝖭
η, K𝖺𝗀𝗀, h𝖬𝖳, n, K𝖺𝗀𝗀, η, h𝖬𝖳,
π𝖬𝖳
T, T𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭 n, T, T𝖿𝗂𝗇𝖺𝗅
𝗏𝖺𝗅 SN transactions 𝗏𝖺𝗅
{p1}, ν𝖼𝗅𝗈𝗌𝖾𝖽, (k1, β1) ⋮ …, ν𝖲𝖭, ξ1 {p1}, ν𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭, β′1

⋮ ⋮

{pn}, ν𝖼𝗅𝗈𝗌𝖾𝖽, (kn, βn) {pn}, ν𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭, β′n Information in β′i

allows to check
(r𝗆𝗂𝗇, r𝗆𝖺𝗑) (r′𝗆𝗂𝗇, r′𝗆𝖺𝗑) hangingTxs txs
immediately (as
opposed to only
Signed: k Signed: k′ upon collect)

Figure 24: collectSN transaction (left) with collectHT transaction (right) and HT transactions
(center).

Providing snapshot information. In an SN transaction (cf. Figure 23), a party simply provides
information about their most recent snapshot in the redeemer ρ and the output data field ξ; ρ
contains data only relevant to verify the SN transaction itself, whereas ξ contains information
relevant for the SM. Specifically, ξ contains h||s, where h is the hash and s the number of the
newest snapshot, and ρ contains a multisignature on h||s. All SN transactions are collected by an
SM collectSN transaction.

Collecting snapshot information. The collectSN transaction (cf. Figure 24) causes the SM to
transition from closed to newestSN. The OCV function Snapshot is responsible for collecting the
values ξi provided in the SN transactions and computing a new head state η 0 as (η 0 , β10 , . . . , βn0 ) ←
Snapshot(Kagg , η, ξ1 , . . . , ξn ), where the βi0 have a purpose similar to that of the βi0 in the close
transaction.
The collectSN transaction has n outputs, each locked by validator νnewestSN , which ensures the
following: either the output is consumed by

1. an SM collectHT transaction (see below) or

2. a hangingTx transaction (identified by having validator νHT in its only output), and

(a) the transaction is signed by ki ,

(b) OCV algorithm ValidHT(βi0 , ξi , ρi ) returns true, where ξi and ρi contain information
about hanging transactions (cf. Figure 25).

Once a collectSN transaction has been posted, a hangingTx-posting period begins which should
last at least T slots. Hence, the last slot Tfinal of said period is recorded in the state, and it is
0
ensured that Tfinal ≥ rmax + T.

Providing hanging transactions. In an HT transaction (cf. Figure 25), a party simply provides
information about hanging transactions not included in the most recent snapshot provided during
the snapshot phase. As with SN transactions, this information is split between the redeemer and
the output data field. All HT transactions are collected by an SM collectHT transaction.

50
 ν𝖺𝗅𝗅𝗈𝖼: check that
HangingTxs Txs 1. 𝖵𝖺𝗅𝗂𝖽𝖧𝖳𝗑𝗌(β1, ξ1, ρ1)
or
1. next transaction is
final SM

𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭,
K𝖺𝗀𝗀, η, h𝖬𝖳,
n, T, T𝖿𝗂𝗇𝖺𝗅
𝗏𝖺𝗅
HT transaction
{p1}, ν𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭, β1
{p′1}, ν𝖧𝖳, ξ1
ν𝗁𝖺𝗇𝗀𝗂𝗇𝗀𝖳𝗑𝗌: check that
⋮ ρ1 1. next transaction is
final SM
{pn}, ν𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭, βn

(r𝗆𝗂𝗇, r𝗆𝖺𝗑)

Signed: k

tx≡: check that

1. π is proof that k′ is contained in h

Collect
𝖬𝖳 𝖬𝖳
Figure 25: collectSN transaction (left) with HT transaction
2. (𝗏𝖺𝗅 , β )
(right).
← 𝖥𝖺𝗇𝗈𝗎𝗍(η, ξ , …, ξ ) i
ℓ
i i=1 1 n
3. r′𝗆𝗂𝗇 ≥ T𝖿𝗂𝗇𝖺𝗅

𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭,
𝖼𝗈𝗅𝗅𝖾𝖼𝗍𝖧𝖳
K𝖺𝗀𝗀, η, h𝖬𝖳, 𝖿𝗂𝗇𝖺𝗅
π𝖬𝖳, 𝖺𝗎𝗑
n, T, T𝖿𝗂𝗇𝖺𝗅
𝗏𝖺𝗅 HT transactions ∅
{p1}, ν𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭, β1 ⋮ …, ν𝖧𝖳, ξ1 𝗏𝖺𝗅′1, ν𝖿𝗂𝗇𝖺𝗅, β′1

⋮ ⋮
{pn}, ν𝗇𝖾𝗐𝖾𝗌𝗍𝖲𝖭, βn 𝗏𝖺𝗅′ℓ, ν𝖿𝗂𝗇𝖺𝗅, β′ℓ
(r𝗆𝗂𝗇, r𝗆𝖺𝗑) (r′𝗆𝗂𝗇, r′𝗆𝖺𝗑)

Signed: k Signed: k′

Burn {p1, …, pn}

Figure 26: close transaction (left) with collectSN transaction (right) and SN transactions
(center).

Collecting hanging transactions. The collectHT transaction (cf. Figure 26) collects all the
information ξi provided by the HT transactions in order to compute the final UTxO set (i.e., the
UTxO set resulting from applying all hanging transactions to the newest snapshot) and to determine
how to partition the UTxO set into ` components (in order to avoid posting large transactions on the
mainchain). Specifically, the OCV function Fanout takes as input key Kagg , η, auxiliary information
aux in the redeemer, and the values ξi and computes (val0i , βi0 ) for i = 1, . . . , `, where val0i is the
value in the ith partition and βi0 is used to validate the corresponding split transaction. The final
transaction must also burn the participation tokens p1 , . . . , pn and may only be posted after the
HT phase is completed, i.e., only when rmin0 ≥ Tfinal .

Splitting the final UTxO set. The task of split transactions (cf. Figure 27) is to make the
UTxOs in a particular partition (as determined by Fanout) available for consumption on the main-
chain. To verify that this is done correctly, validator νfinal runs OCV predicate Final(βi , Ui ), where
Ui is the set of outputs of the split transaction.

C.2 UTxO sets and Merkle-Patricia Trees

The head protocol and OCV algorithms for the full Hydra protocols make use of a variant of so-
called Merkle-Patricia Trees (MPTs) [20]. Hydra’s MPTs store a set of D of outref/output pairs

51
 Split Txs
ν𝖿𝗂𝗇𝖺𝗅: check that
1. 𝖥𝗂𝗇𝖺𝗅(η1, U1)

𝖿𝗂𝗇𝖺𝗅

∅
split Transaction
𝗏𝖺𝗅1, ν𝖿𝗂𝗇𝖺𝗅, β1

𝗏𝖺𝗅ℓ, ν𝖿𝗂𝗇𝖺𝗅, βℓ

(r𝗆𝗂𝗇, r𝗆𝖺𝗑)

Signed: k
⋮
}
<latexit sha1_base64="WxxOLoH8qvPV+BjLCZ5YgtKmayM=">AAAB/XicdVDLSgNBEOz1GeMr6tHLYBA8hd0o6DHoxWMU84BkCbOT2WTIzO4y0yuEJfgDXvUPvIlXv8Uf8DucJHvQBAsaiqpuqqkgkcKg6345K6tr6xubha3i9s7u3n7p4LBp4lQz3mCxjHU7oIZLEfEGCpS8nWhOVSB5KxjdTP3WI9dGxNEDjhPuKzqIRCgYRSvddye9UtmtuDOQZeLlpAw56r3Sd7cfs1TxCJmkxnQ8N0E/oxoFk3xS7KaGJ5SN6IB3LI2o4sbPZp9OyKlV+iSMtZ0IyUz9fZFRZcxYBXZTURyaRW8q/ufhUC2kY3jlZyJKUuQRm4eHqSQYk2kVpC80ZyjHllCmhf2fsCHVlKEtrGiL8RZrWCbNasU7r1TvLsq167yiAhzDCZyBB5dQg1uoQwMYhPAML/DqPDlvzrvzMV9dcfKbI/gD5/MH32SV5A==</latexit>
U1

Burn {p1, …, pn}

Figure 27: collectHT transaction with split transaction.

(out-ref, o) in such a way that

• (determinism) the set D defines the tree (i.e., the order of insertions and removals have no
effect on the tree’s shape),

• (hashing) a tree can be hashed—i.e., a so-called root hash can be computed—in such a way
that it is computationally hard to find two trees (or, equivalently, two sets D and D0 ) with
the same hash,

• (membership proofs) membership of a pair (out-ref, o) in the tree can be verified using the
root hash and auxiliary information aux of size O(log |D|),

• (removing and adding) given a root hash hroot corresponding to a set D and sets R ⊆ D and
A with A ∩ D = ∅, the root hash corresponding to D \ R ∪ A can be computed from hroot and
auxiliary information aux of size O(log |D|), and

• (splitting) given any number B, a tree corresponding to D can be split into subtrees corre-
sponding to disjoint sets D1 , . . . , D` (for some `) with D1 ∪ . . . ∪ D` = D such that

– the elements of each Di have size at most B bits, and

– the root hashes and total values corresponding to each Di can be computed using the
root hash hroot of D and auxiliary information aux of size B.11

Defining MPTs. MPTs used by Hydra have alphabet size A = 16. The MPT corresponding
to a set D is defined via algorithm MPT-Build in Figure 28. Note that outrefs take on the role
of “keys” and outputs o that of “values.” MPTs are defined recursively, where the root node
node = (pre, H, S, V ) of the tree corresponding to D with D > 1 has the following fields:

• Prefix: The field pre stores the common prefix of all the keys found in D.

• Children: The array H stores the hashes of all A children nodes, where H[i] = ⊥ if the
corresponding child is not present. The ith child of node is the root of the MPT containing
all elements corresponding to the set D00 computed as follows:
11
Observe that this only works if the trees do not exceed a certain maximum size.

52
 1. Let the set D0 be the set obtained by removing the prefix pre from every key out-ref in
every pair (out-ref, o) ∈ D; this is denoted (pre, D0 ) ← CP(D) in Figure 28.
2. Let D00 bet the set obtained by additionally removing the character i from each out-ref;
this is denoted by Proj(D0 , i) in Figure 28.

• Size: For each i ∈ [A], S[i] records the combined size of the leaves of the subtreePat the ith
child. The combined size of all leaves in node’s subtree is Sum(S), where Sum(S) = i∈[A] S[i].

• Value: For each i ∈ [A], V [i] records the value th

P of the subtree at the i child. The value of
node’s subtree is Sum(V ), where Sum(V ) = i∈[A] V [i].

Leaf nodes leaf = (pre, o) correspond to a single- N [·] ← ε

element D = {(pre, o)}. Their size is given by Size(leaf), MPT-Build (D)
and their value is val, where o = (val, ν, δ). if |D| > 1
(pre, D0 ) ← CP(D)
H[·], S[·], V [·] ← ε
Hashing. The hash of an MPT is simply the hash of for i ∈ [A]
its root node. (H[i], S[i], V [i]) ← MPT-Build(Proj(D0 , i))
node ← (pre, H, S, V )
h ← H(node)
Membership proofs. To provide a proof that some N [h] ← node
out-ref appears in an MPT with root hash hroot , it suf- return (h, Sum(S), Sum(V ))
else if |D| = 1
fices to provide as auxiliary information aux the nodes {(pre, o)} ← D
on the path from the root to the leaf containing o. leaf ← (pre, o)
h ← H(leaf)
The corresponding verification function is denoted by N [h] ← leaf
MPT-VfyMemb(h, out-ref, aux). (val, ·, ·) ← o
return (h, Size(leaf), val)
else
Removing and adding. Similarly to membership return (⊥, 0, ∅)
proofs,
Figure 28: Recursive procedure to build an
• for removing a pair (out-ref, o) from an MPT with MPT from a set D of outref/output pairs
root hash hroot , the new root hash can be com- (out-ref, o). The algorithm stores the nodes
puted if given as auxiliary information aux the in the array N indexed by their hashes and
nodes on the path from the root to the node returns the hash of the root node as well as
deleted, where, in cases where that node only has total size and value of the entire tree.
one sibling, that sibling has to be provided as
well;

• for adding a pair (out-ref, o) to an MPT with root

hash hroot , the new root hash can be computed if
given as auxiliary information aux the nodes on
the path from the root to the node where out-ref
diverges from the prefix traversed.
In order to remove an entire set R ⊆ D of outref/output pairs and subsequently add a set A
with A ∩ D = ∅ (which is what happens when a transaction is applied to a UTxO set), the above
operations can simply be concatenated, producing a combined auxiliary string aux. The function
that computes the new root hash h0root from the old root hash hroot , the sets R and A, and aux is
denoted by h0root ← MPT-CompRA(hroot , R, A, aux).

53
Splitting. To split, as described above, a tree Pwith nodes N , first, each node node = (pre, H, S, V )
whose subtree has leaves with combined size i S[i] > B is added to a list split (indexed by node
hashes), which is referred to as the split frontier. Then, every node node ∈ / split with a parent in
the split frontier is the root of a subtree corresponding to one of the subsets Di . This way, the
combined size of all elements in each Di is at most B (as otherwise, node would be in the split set).
Denote these root nodes by node1 , . . . , node` and call them split nodes.
In order to compute the hashes h1 , . . . , h` and values val1 , . . . , val` of the split nodes from the
hash hroot of the root node of the entire tree, aux consists simply of the the split frontier split (which
includes said hashes and values).
Finally, for each split node nodei , define the split prefix prei to be the common prefix of all
outrefs in Di . The split prefix will be needed to compute the hashes hi given the sets Di : hi is
obtained by computing the MPT corresponding to Di , but by removing prei from the prefix pre in
the resulting root node before hashing it.
The function computing the above values is denoted by

(h1 , . . . , h` , val1 , . . . , val` , pre1 , . . . , pre` ) ← MPT-CompSpl(hroot , B, aux) .

C.3 Head protocol and on-chain verification

In order to be used with the improved SM (cf. Figure 18), some small changes have to be made in
the head protocol. This section summarizes these changes and describes on a high level how the
OCV functions can be implemented to work with the improved SM.

Merkle-Patricia trees, UTxO sets and transactions. The head protocol and the OCV
algorithms can be implemented in such a way that—apart from split transactions—only hashed
information about snapshots and hanging transactions needs to be posted. That way, Hydra
mainchain transactions remain small even if the head UTxO set becomes large or there are many
hanging transactions.
Recall that a UTxO is simply a pair u = (out-ref, o) of outref and output. The full head protocol
maintains the current UTxO set by storing all UTxOs in an MPT as shown in Section C.2. When
creating new snapshots, parties sign the root hash of the MPT (instead of a plain hash of the UTxO
set).
Note that applying a transaction to a UTxO set always involves removing some UTxOs and
adding some new ones. Thus, evolving the hash corresponding to a UTxO set to include a new
transaction involves simple remove and add operations on the MPT.
To keep HT transactions small (see below), when confirming a transaction tx = (I, O, valForge , r,
K), tx is hashed by computing

H(ID(tx), out-ref 1 , . . . , out-ref w , o1 , . . . , ow0 , hrest ) ,

where
• ID(tx) is the ID of tx as per the ledger rules,
• I = {i1 , . . . , iw } and ij = (out-ref j , ρj ),
• O = (o1 , . . . , ow0 ), and
• hrest = H(ρ1 , . . . , ρw , valForge , r, K) is the hash of the rest of the transaction.

54
For MPT proofs of membership/insertion/deletion, this way of hashing allows to provide only the
ID ID(tx), the output references in I, the outputs O, and the hash hrest , which are usually much
shorter than the entire transaction.

Onchain verification functions. Using these MPTs, the OCV functions for the efficient de-
commit can be implemented as follows:
• η 0 ← Initial(U1 , . . . , Un ) computes the MPT corresponding to the union of the UTxO sets Ui
and stores the hash in the output η 0 .
• (η 0 , β10 , . . . , βn0 ) ← Close(η) leaves η 0 = η unchanged and puts Kagg into each βi0 .
• ValidSN(β, ρ, ξ) uses Kagg (stored in β) to verify the multisignature (stored in ρ) on the MPT
hash and snapshot number (stored in ξ). The algorithm returns true if and only if the
signature verifies and the snapshot number is greater than 0.
• (η 0 , β10 , . . . , βn0 ) ← Snapshot(η, ξ1 , . . . , ξn ) simply picks the ξi with the highest snapshot number
and stores the corresponding MPT root hash in η 0 . Each output βi0 consists of Kagg as well
as said hash. Note that if all ξi are empty (because no party posted a valid SN transaction),
the initial hash (still in η) computed in Initial is used.
• ValidHT(β, ρ, ξ) is somewhat more involved. Recall that this validator checks an HT trans-
action, via which some party posts hanging transactions—in ξ—along with corresponding
multisignatures and proofs—in ρ—showing that these transactions were confirmed in the
head and can be applied to the most recent snapshot, whose hash hSN is stored in β.
Hanging transactions tx = (I, O, valForge , r, K) are provided via the values
˜ = (ID(tx), out-ref 1 , . . . , out-ref w , o1 , . . . , ow0 , hrest )
tx
˜ and checks, using
as defined above. For each such transaction, ValidHT computes h ← H(tx)
Kagg (stored in β), that ρ contains a valid multisignature on h.
Once all transactions have been authenticated, ValidHT now processes them in topological
order and checks for each transaction tx that
– either there is an out-ref i = (txID, txIdx ) in tx such that txID refers to a previously
processed transaction, or
– there is an MPT membership proof aux in ρ such that MPT-VfyMemb(hSN , out-ref i , aux) =
true for some out-ref i in tx.
Note that since transactions are multisigned, it suffices to check a single outref to ensure that
tx is not old (i.e., not already consumed by the newest snapshot).
• (β1 , . . . , β` , val1 , . . . , val` ) ← Fanout(η, aux, ξ1 , . . . , ξn ) has two tasks: First, it must collect
hanging transactions (stored in variables ξi ) and compute, using the hash hSN (stored in η) of
the most recent snapshot and auxiliary information aux1 (stored in aux), the hash hfinal of the
final UTxO set; this can be done by means of the function MPT-CompRA. Second, it must take
auxiliary information aux2 (stored in aux) and compute the split (h1 , . . . , h` , val1 , . . . , val` , pre1 ,
. . . , pre` ) ← MPT-CompSpl(hfinal , B, aux2 ). Each βi is set to (hi , prei ).
• Final(βj , Uj ) simply hashes Uj and checks if it matches ηj .

55