Peg-Out

A peg-out is the redemption half of a two-way peg: a user burns or returns a wrapped representation of an asset on a sidechain or destination chain, and the corresponding native asset is released from reserve on the base chain. The inbound direction is the peg-in, usually implemented as lock-and-mint.

Why it matters for security

The peg-out is where paper becomes money. A bug that creates unbacked wrapped supply is only a loss once that supply can be redeemed for the real asset — which means the peg-out path is the last line of defence, and often the only place a solvency check can still catch an earlier failure.

Peg-outs are typically authorised by a federation, multisig, or validator set holding release keys. Critically, that authorisation usually validates the redemption request, not the provenance of the wrapped tokens being redeemed. A syntactically perfect peg-out of illegitimately minted tokens looks identical to a legitimate one.

The design implication

Because the peg-out path cannot usually tell good supply from bad, protecting it requires controls that operate on aggregates rather than individual requests:

• Reserve reconciliation before release — does total outstanding wrapped supply still match custody?
• Rate limits on redemption volume per epoch
• Circuit breakers keyed to reserve drawdown percentage rather than absolute amounts

In the Liquid Network incident, unbacked L-BTC was pegged out through a federation member holding a valid peg-out authorisation key. No key was compromised and no authorisation rule was broken — the tokens themselves were the problem, and the peg-out path had no way to know.