What is the Lock-and-Mint model, and how does it differ from other cross-chain approaches?
Lock-and-mint is one of the most common bridge designs today: a user deposits an original asset (say, Bitcoin) into a Smart Contract or multisig wallet on the source chain, where it gets locked. Once the bridge protocol confirms the lock, it mints an equivalent amount of a wrapped Token (say, WBTC) on the destination chain (say, Ethereum), representing the user's claim to withdraw that locked asset. This differs from "native issuance" (where an asset exists natively on multiple chains, as some stablecoins do) — a lock-and-mint Wrapped Token is always just a redemption claim, never the asset itself; the asset's one true form stays locked on the source chain the whole time.
It also differs from the "burn-and-mint" design, which destroys tokens on the source chain outright rather than locking them, theoretically sidestepping the question of whether the locked asset is "still really there." But burn-and-mint requires the asset itself to support native cross-chain burn/mint at the protocol level, which isn't an option for every asset.
Why do cross-chain bridges use the Lock-and-Mint design in the first place?
Most blockchain assets (native Bitcoin, for instance) were never designed with cross-chain interoperability in mind — Bitcoin's protocol has no concept of Ethereum's existence and no built-in mechanism to "move" BTC onto Ethereum to function there. Lock-and-mint solves exactly this gap: it requires no changes to the original asset's underlying protocol, only a lock mechanism on the source chain and a corresponding Token contract on the destination chain. That lets an asset otherwise trapped on a single chain get used within another chain's Smart Contract ecosystem (wrapping Bitcoin into WBTC, say, to provide liquidity in an Ethereum DeFi protocol).
This design became popular precisely because its technical barrier is relatively low — it doesn't require convincing an original asset's core developer community to modify the protocol itself; any third-party team can stand up a lock-and-mint bridge on its own. But that's also its biggest source of risk: the security of what's locked depends entirely on the quality of the third-party bridge team's contracts and key management, not on the security of the original asset's protocol.
How does Lock-and-Mint actually work in practice, step by step?
The typical flow has four steps. First, the user deposits the original asset into a lock contract on the source chain (or a multisig wallet controlled by the bridge operator). Second, the bridge's verification layer — which might be centralized Validator nodes, a multisig committee, or a decentralized light-client verification network — confirms that the deposit genuinely happened and that the amount is correct. Third, once verification passes, a minting contract on the destination chain issues an equivalent amount of wrapped tokens to the user based on that verification result. Fourth, when the user wants to redeem the original asset, the process reverses: the wrapped Token is burned on the destination chain, and once the verification layer confirms the burn, the lock contract on the source chain releases the corresponding amount of the original asset.
The most critical — and most failure-prone — step in this whole flow is step two, the verification layer. If that layer is compromised (a flawed signature-verification logic, or a stolen multisig key, for instance), an attacker can trick the system into believing "a deposit happened" without any real asset ever being deposited, triggering step three's mint and producing wrapped tokens with no real backing at all.
What risks should an ordinary user actually watch for when holding a Lock-and-Mint wrapped Token?
The most direct risk is redemption risk: whether your Wrapped Token can actually be exchanged back for the real original asset depends entirely on whether the lock contract on the source chain genuinely holds the corresponding amount — something you as a user can almost never verify directly. You're relying on the bridge protocol's publicly disclosed lock-address balance, or whether it's been independently audited. If the locked assets are stolen or misappropriated through a vulnerability, your wrapped token becomes a claim on an asset that no longer exists.
The second risk is verification-layer trust risk: you're effectively trusting the bridge protocol's verification mechanism — whether centralized Validator nodes or a decentralized light-client network — rather than trusting the original asset's own blockchain. When deciding whether a wrapped token is worth holding, it's worth spending time confirming which verification mechanism the bridge uses and whether it publishes a verifiable Proof of Reserves, rather than just looking at trading volume or market cap.
WBTC (Wrapped Bitcoin) is the best-known real-world example of lock-and-mint: users deposit BTC into a multisig wallet controlled by custodians (primarily institutions like BitGo today), and an equivalent amount of WBTC is minted on Ethereum, letting Bitcoin — which otherwise can't participate directly in Ethereum's DeFi ecosystem — get used in lending protocols and liquidity pools. The September 2026 Symbiosis Bitcoin bridge exploit, which minted roughly $46.1 billion in unbacked syBTC, is a real-world case of a lock-and-mint verification layer failing.
The advantage is a low technical barrier — cross-chain liquidity is achieved without modifying the original asset's protocol, letting single-chain assets get used in other chains' ecosystems. The drawback is that security depends entirely on the third-party bridge team's verification layer and key-management quality; if the lock contract or verification logic is compromised, the wrapped token can become an unbacked phantom asset, and users have almost no way to independently verify whether the locked state is genuine.