Bridges: Lock, Mint and the Failure Between

A crypto bridge is a system that lets an asset on one chain be used on another, and almost every design does it by holding the original somewhere and issuing a substitute. The holding side is the lock; the issuing side is the mint. Everything a user cares about sits between those two operations, in the gap where the two chains cannot see each other.

That gap is why a crypto bridge carries a different risk from the chains it connects. A chain failure is visible and shared. A bridge failure is a specific contract, a specific set of keys, and a specific moment when the substitute stops being redeemable at par.

• Lock-and-mint bridges hold the original asset in a contract and issue a separate token on the destination chain.
• The wrapped token is a claim on the bridge operator, not a claim on the underlying chain or its validators.
• Liquidity-pool bridges avoid wrapping but concentrate a different risk: the pool has to be deep enough when everyone exits at once.
• Bridge risk concentrates because one contract holds assets for thousands of users across two chains, and both sides must stay consistent.

How a crypto bridge moves value

It moves value by changing custody, not by moving coins. Nothing travels between chains, because the chains do not read each other’s state. What travels is a message authorising someone to create or release a balance on the far side.

The lock side

On the source chain, you send the asset to a contract you do not control. The contract records the amount and emits an event. Your tokens are frozen in a pool that only the bridge’s release logic can draw from. You no longer hold them; you hold a receipt, and what matters is who can move funds out of that pool.

The mint side

On the destination chain, a contract mints a wrapped token against the event, or releases a pre-funded balance from a pool. The wrapped token has its own contract, its own decimals, and often its own listing. It behaves like any other token until you try to redeem it.

Redemption runs the loop backwards: burn, wait for the message, receive the original. The wait is not a formality. During it your claim exists but is not settled, and only the bridge can settle it.

Liquidity pools and the other model

Pool-based bridges do not mint anything. They keep inventory of the real asset on both chains, pay you from the destination pool, and rebalance later. You receive the native asset directly, which removes the wrapped-token step and the redemption queue. Liquidity providers fund the pool and earn a share of the fee, so the pool needs enough depth to cover net outflow in one direction. That works while flows are balanced and badly when one event pushes everyone the same way.

Why pools fail differently

A pool bridge fails by running out, not by becoming insolvent in the abstract. If the pool holds 800 units and 1,600 units of demand arrive in an hour, the last 800 wait, get routed elsewhere, or accept a worse rate. The failure is gradual and observable, which makes it easier to plan around than a drained lock.

Both models share one property: the user is trusting an entity that is not a chain. The entity may be a set of contracts, a validator set, or a multisig, but it is always something with discretion over release.

The wrapped asset is a claim on the bridge, not on the chain

A wrapped token does not give you rights against the source chain, its validators, or its treasury. It gives you a claim enforced by a bridge contract, plus whatever governance sits above that contract. If the bridge stops honouring redemptions, the claim is worth what the secondary market says it is worth.

The distinction becomes concrete in a depeg. The wrapped token keeps its name and decimals while trading below the underlying, because holders are pricing the probability of redemption rather than the asset. A 2% discount is a market estimate that 2% of claims will not be honoured. The underlying did not move; the wrapper’s credit did.

A wrapped token is an IOU with a ticker. It looks like the asset in every interface you use, which is exactly why the difference is easy to forget until the queue forms.

There is an information asymmetry on top of that. Users on the destination chain cannot observe the lock; they see a wallet balance and a page saying the bridge is fully backed. So holding a wrapped asset is a credit position, and it should be sized like one.

Why crypto bridge risk concentrates

Risk concentrates because a bridge is a single point of agreement between two systems that cannot verify each other. One contract holds assets for every user on one side; one message format defines what the other side accepts. Break either and everyone is affected at once.

Three concentrations are worth naming. Custody: the lock holds everyone’s deposits in one address, so one exploit is not proportional to the attacker’s stake. Key material: many bridges secure the lock with a multisig, and a threshold is a smaller target than the value behind it. Code surface: two contracts, a relayer, and a governance path, each of which is a way in.

Worked example: where the backing goes

Take a lock-and-mint bridge holding 10,000 units against 10,000 wrapped units. The backing ratio is 1.00, and every holder can redeem at par in principle, though not all at once in practice. Now suppose a flaw in the release logic lets 2,500 units leave the lock without a matching burn.

The lock holds 7,500 against 10,000 outstanding claims, a ratio of 0.75. The first 7,500 units to redeem are paid in full and the remaining 2,500 claims recover nothing. The loss is not spread evenly at 25% each; it is a queue, and position in it determines the outcome.

Add a secondary market and the arithmetic changes shape. If the wrapped token trades at 0.75 while redemptions are paused, a holder who sells takes the 25% loss immediately; a holder who waits takes either nothing or a full recovery depending on whether the shortfall is repaired. That is why depegs overshoot: the market prices the worst case, and the queue prices the average.

The rows are not ranked by safety. A light-client bridge can be stronger than a multisig one and still fail on a verifier bug, while a multisig bridge with slow, public, timelocked operations fails in a way you can see coming.