Recursive Sidechains Overview

• Recursive sidechains are blockchain constructions that use recursion to compress execution proofs or compose blockchains, enabling succinct verification and separated security domains.
• They employ zk-SNARKs to generate constant-size proofs of extensive state transitions, reducing verification costs and decoupling sidechain details from the mainchain.
• They also use compositional techniques like serial and triangular gates to achieve rigorous safety–liveness trade-offs across multiple chains, ensuring robust cross-chain security.

Recursive sidechains are sidechain constructions in which recursion is used to compress, compose, or lift verification across chains. In one line of work, recursion denotes the recursive composition of zk-SNARKs so that a mainchain can verify a constant-size proof attesting to a long sequence of sidechain state transitions without learning the sidechain’s internal structure; this is the model exemplified by Zendoo and its Latus instantiation (Garoffolo et al., 2020). In another line of work, recursion denotes the recursive composition of blockchains themselves through serial and triangular composition rules, yielding overlay blockchains with formally characterized safety–liveness trade-offs over multiple underlay chains (Tas et al., 2024). Across both meanings, the central objective is decoupled verification: the underlay or parent chain verifies succinct authenticated summaries rather than replaying the full execution of the sidechain.

1. Conceptual scope and meanings of recursion

The term recursive sidechains covers two distinct but related constructions. The first is proof recursion: a sidechain generates per-transaction proofs, recursively merges them into block proofs and epoch proofs, and ultimately exposes a single succinct certificate to the mainchain. The second is chain recursion: an overlay blockchain is built by recursively wiring together existing blockchains through a small set of compositional operations, so that the overlay inherits formally analyzable safety and liveness properties from its underlays.

Perspective	Recursive object	Main result
Zendoo-style	zk-SNARK proofs of sidechain execution	One final constant-size proof for long state-progression chains
Circuit-style	Composition of underlay blockchains	Achievable safety–liveness points over $k$ chains

In the Zendoo setting, recursion is operationally internal to the sidechain: the mainchain sees only certificates, while the sidechain aggregates proofs of its own execution history (Garoffolo et al., 2020). In the circuit setting, recursion is architectural: serial and triangular “gates” are repeatedly composed to synthesize an overlay blockchain with a chosen operating point in the partial-synchrony safety–liveness region (Tas et al., 2024).

This distinction matters because the two approaches address different bottlenecks. Proof recursion primarily addresses verification cost and decoupling of application semantics from the mainchain. Chain recursion primarily addresses how trust and availability assumptions distribute across multiple blockchains.

2. Parent–child architecture and cross-chain transfer in Zendoo

Zendoo is formulated for Bitcoin-like blockchain systems with a parent–child relationship between a mainchain (MC) and sidechains (SCs) (Garoffolo et al., 2020). The MC is a Bitcoin-style UTXO-based blockchain that maintains the global coin-ledger and a fixed cross-chain interface, the CCTP, while remaining agnostic to sidechain internals. Each SC is an arbitrary blockchain-or-application that uses the MC’s native coin. SC nodes directly observe MC blocks by referencing them; MC nodes do not observe SC internals and instead verify cryptographically authenticated certificates from sidechain maintainers.

When an SC is created via a special MC transaction, the MC stores the sidechain identifier and parameters needed for cross-chain verification: ledgerId, epoch_len, submit_len, and the three SNARK verification keys $vk_{WCert}$, $vk_{BTR}$, and $vk_{CSW}$. Every MC block header includes a Merkle commitment SCTxsCommitment to all SC-related transactions, including forward transfers (FT), backward transfer requests (BTR), and at most one withdrawal certificate (WCert) per SC. SC forgers embed the MC header together with a succinct Merkle proof into SC blocks.

The transfer logic is asymmetric. A forward transfer is a standard MC output that burns coins on the MC and carries SC-specific metadata; once an SC block references the MC block containing the FT, the SC receives newly minted coins in its own UTXO set. Backward transfers are accumulated on the SC during a withdrawal epoch and committed in two stages. First, the SC creates a special WCert transaction that carries a constant-size zk-SNARK proof of correct SC-state progression. Second, that WCert is submitted to the MC, which checks the proof with $vk_{WCert}$ and, if valid, recreates the coins on the MC. If the SC fails to submit a WCert in time, the SC becomes ceased and only CSW transactions are accepted; BTR and CSW use distinct SNARK systems keyed by $vk_{BTR}$ and $vk_{CSW}$.

A central architectural property is that the MC only ever sees constant-size certificates from the SC. This makes cross-chain verification independent of the SC’s internal consensus, transaction logic, or state representation, provided the SC can supply the required proof objects.

3. Recursive zk-SNARK composition for sidechain state progression

Zendoo’s recursive sidechains are built from a state-transition system $(S, T, update)$, where $S$ is the set of states, $T$ is the set of transactions, and $vk_{WCert}$0 (Garoffolo et al., 2020). A base arithmetic circuit $vk_{WCert}$1 checks one state transition in witness form. Its associated SNARK interface is:

• $vk_{WCert}$2
• $vk_{WCert}$3
• $vk_{WCert}$4

Recursive compression is obtained by a merge circuit $vk_{WCert}$5 that verifies two SNARK proofs $vk_{WCert}$6 for adjacent transitions $vk_{WCert}$7 and $vk_{WCert}$8, and checks that $vk_{WCert}$9 is the result of the combined update. Its interface is:

• $vk_{BTR}$0
• $vk_{BTR}$1
• $vk_{BTR}$2

By nesting Merge over Base or Merge proofs, the system obtains a single constant-size SNARK $vk_{BTR}$3 attesting to a long chain of transitions

$vk_{BTR}$4

in $vk_{BTR}$5 SNARK generations, while the final proof remains of size $vk_{BTR}$6. The operational workflow is hierarchical: for each SC transaction $vk_{BTR}$7 in a block $vk_{BTR}$8, a per-transaction proof $vk_{BTR}$9 is generated; those proofs are recursively merged into a block proof $vk_{CSW}$0; the block proofs for a withdrawal epoch are then merged into an epoch proof $vk_{CSW}$1; and the final epoch proof has size $vk_{CSW}$2 with verification time $vk_{CSW}$3, independent of epoch length.

The WCert SNARK exposes this recursive state-progression proof to the MC. Its witness includes all SC-block references and Merkle proofs for MC headers, the sequence of SC blocks or their block-level SNARK proofs for the epoch, the list $vk_{CSW}$4 of backward transfers to be paid out, and an mst_delta bit-vector identifying modified leaves in the Merkleized state. Its public input is

$vk_{CSW}$5

where

$vk_{CSW}$6

and

$vk_{CSW}$7

At bootstrapping, $vk_{CSW}$8; the SC computes $vk_{CSW}$9; and the MC accepts the WCert only if $vk_{WCert}$0 returns true.

The stated security basis consists of SNARK knowledge soundness, collision-resistant hashing and Merkle commitments, and honest-majority in MC proof-of-work for finality of the MC block hashes used in wcert_sysdata. Zero-knowledge ensures that SC internal data appear only in witnesses, while the MC sees only public hash digests.

4. Latus as a concrete recursive sidechain construction

Latus is the specific sidechain construction proposed on top of the Zendoo infrastructure for a decentralized verifiable blockchain system for payments (Garoffolo et al., 2020). Its state is

$vk_{WCert}$1

where $vk_{WCert}$2 is a fixed-depth Merkle tree of UTXO slots with depth $vk_{WCert}$3. Each leaf stores either a UTXO $vk_{WCert}$4 or null.

The transaction set is partitioned into four classes. PaymentTx is a standard multi-input/output transfer. ForwardTransfersTx imports forward transfers from the MC and either creates UTXOs or emits rejected transfers as backward transfers. BackwardTransferTx spends UTXOs and appends outputs to state.backward_transfers. BackwardTransferRequestsTx synchronizes BTRs from the MC, spends UTXOs, and appends to backward_transfers.

Consensus is bound to the MC by a modified Ouroboros proof-of-stake rule: SC blocks must embed references to MC headers in prefix order and obey the longest-MC-chain rule. The proof system mirrors the transaction taxonomy. Latus defines transaction-specific base circuits $vk_{WCert}$5, $vk_{WCert}$6, $vk_{WCert}$7, and $vk_{WCert}$8, together with a universal aggregator $vk_{WCert}$9. The WCert circuit performs one final Merge over the proofs for each SC block in the epoch, Merkle-verification subcircuits for MC references and SCTxsCommitment, and consistency checks for BTList, quality, the state root, and mst_delta.

The performance parameters reported for this construction are succinct in proof size and verification cost. Proof size is approximately $vk_{BTR}$0–$vk_{BTR}$1 bytes in Groth16 style, independent of epoch length. On-chain verification gas is $vk_{BTR}$2, exemplified as a few hundred thousand gas in Ethereum. Off-chain proving cost is

$vk_{BTR}$3

and is parallelizable across provers or “snark-dispatchers.”

The security analysis emphasizes four properties. First, soundness: any invalid backward transfer or invalid state transition would violate the Base or Merge relation, so its proof cannot be forged. Second, zero-knowledge: the MC learns only public digests. Third, fraud-certificate resistance: the MC enforces a sidechain-balance safeguard so that certificates cannot withdraw more than total forward transfers minus past MC withdrawals, and nullifier tracking prevents double-spend or double-withdrawal. Fourth, data-availability resilience: the mst_delta vector together with Merkle-proof-in-SNARK allows users to prove past-state UTXO ownership even if the SC withholds its full tree.

5. Recursive composition of blockchains as circuits

A distinct formalization treats recursive sidechains as overlay blockchains constructed from underlay blockchains by compositional “gates” (Tas et al., 2024). In this model, a blockchain protocol $vk_{BTR}$4 is an abstract state machine whose clients output a growing totally ordered ledger. Honest clients maintain a current chain $vk_{BTR}$5 and adopt the longest valid finalized chain seen so far. Under partial synchrony with unknown GST and delay $vk_{BTR}$6, safety requires that for any two honest clients and times $vk_{BTR}$7, their output chains are consistent with $vk_{BTR}$8; liveness requires bounded inclusion of any honest-submitted transaction after GST.

The first gate is serial composition. Given underlays $vk_{BTR}$9 and $vk_{CSW}$0, the overlay $vk_{CSW}$1 is defined by placing certified snapshots of the finalized $vk_{CSW}$2 chain into blocks of $vk_{CSW}$3. Clients extract the ordered sequence of certified snapshots

$vk_{CSW}$4

and compute the sidechain ledger as

$vk_{CSW}$5

where Clean concatenates each new snapshot but removes transactions already output. The stated theorem is that $vk_{CSW}$6 is safe if at least one of $vk_{CSW}$7 is safe, and live if both are live.

The second gate is triangular composition. For three underlays, the overlay

$vk_{CSW}$8

runs a three-party omission-fault-tolerant protocol in which each underlay hosts a smart contract acting as one validator. In each epoch, the leader reads contract state from finalized underlay blocks, proposes a block via prop(B,v), contracts seeing the proposal emit ack(B,v) at time $vk_{CSW}$9, and if no certificate is observed by time $(S, T, update)$0 they emit leader-down with the last vote. Any certificate of at least two acknowledgments commits the block. The resulting theorem states that $(S, T, update)$1 is safe if all three underlays are safe and live if any two are live.

This construction yields a complete synthesis theory for overlay blockchains on $(S, T, update)$2 underlays. The feasible region under partial synchrony is

$(S, T, update)$3

Equivalently, $(S, T, update)$4 and $(S, T, update)$5. The overlay is safe if any $(S, T, update)$6 underlays are safe and live if any $(S, T, update)$7 underlays are live, and no better trade-off is possible under partial synchrony. The building blocks $(S, T, update)$8 from serial composition and $(S, T, update)$9 from triangular composition are sufficient, through recursive “circuit synthesis,” to realize the boundary

$S$0

and then all integer points in the admissible region by padding with additional serial gates.

6. Security implications, trade-offs, and common misconceptions

A recurrent misconception is that recursive sidechains require the mainchain or underlay chains to track the sidechain’s full state. In Zendoo, the MC is relieved of tracking any SC state or consensus; it need only store $S$1 and the sidechain’s balance (Garoffolo et al., 2020). In the circuit model, the underlays continue to run their native consensus and expose finalized block streams and certificate-validation interfaces; the overlay logic is externalized into smart contracts and off-chain agents rather than into replicated re-execution of all overlay state (Tas et al., 2024).

A second misconception is that recursion is synonymous with a single implementation technique. The proof-recursive and circuit-recursive formulations solve different problems. In Zendoo, recursion yields succinctness: the MC always verifies a single constant-size proof per SC epoch, no matter how many SC blocks or transactions occurred. In the circuit approach, recursion yields compositional threshold design: repeated use of serial and triangular gates realizes exactly the optimal safety–liveness trade-offs over multiple underlays.

A third misconception is that recursive sidechains eliminate all trust assumptions. The record is narrower. Zendoo explicitly relies on SNARK knowledge soundness, collision-resistant hashing, Merkle commitments, and honest-majority MC proof-of-work. The circuit model operates under partial synchrony and requires safe or live underlay chains in the thresholds prescribed by $S$2. This suggests that recursion minimizes, rather than abolishes, dependence on underlying assumptions.

Latency and overhead are also structurally constrained in the circuit setting. Each serial gate adds roughly $S$3 of cross-chain latency, each triangular gate adds approximately $S$4, and a depth-$S$5 circuit incurs $S$6 sequential delay. Message overhead per underlay validator grows with gate fan-in, while computation overhead arises from cross-chain certificate verification. The same section notes that heavy embedding occurs only at gate locations and that the metalayer of gates can be pipelined (Tas et al., 2024).

The broader significance of recursive sidechains lies in decoupling. Zendoo states that sidechains may choose arbitrary consensus logic, transaction models, or policies so long as they provide a valid SNARK certificate, and attributes to this decoupling improved throughput, independent sidechain upgrades, and minimized trust (Garoffolo et al., 2020). The circuit framework, by contrast, formalizes how a blockchain can be built on blockchains with exact safety–liveness guarantees and a converse result showing that no stronger guarantees are possible under the stated model (Tas et al., 2024). Taken together, these lines of work define recursive sidechains as a family of constructions in which recursion is used either to compress execution or to compose security domains, while preserving a sharply defined verification boundary between layers.