Wrapped token

The wrapper is a receipt, and receipts are cheap

Wrapping exists because assets are not portable across chains. Bitcoin cannot execute on Ethereum, and ETH on Ethereum cannot settle on Solana. So a system locks the native asset on its home chain and issues a claim on the destination chain, and that claim trades, lends and composes like any other token there.

The claim is a plain token contract. It has no special properties, no oracle and nothing clever inside it. All of the design risk sits one layer down, in the answer to two questions: who is permitted to mint a new unit, and what has to be true before they do. Everything below is those two questions in different costumes.

The custodial model, as WBTC documents it

WBTC publishes its flow in full, so it is the cleanest thing to read. Three parties: users, merchants who are regulated institutions performing KYC and AML checks, and a custodian that holds the BTC reserves and is the only entity authorised to mint and release WBTC.¹

Minting runs through the merchant. The user requests WBTC, the merchant completes KYC and AML and instructs the transfer, BTC lands in the custodian's designated custody wallet, and after the Bitcoin transaction receives six network confirmations the custodian verifies receipt and mints. Redemption reverses it: the merchant burns the WBTC first, the custodian waits for 25 Ethereum confirmations to be satisfied the burn is final, then releases BTC.¹

Note what the confirmation counts are actually for. They are not user experience, they are the custodian's own reorg protection on both sides. And note the shape of the exposure: a holder's claim depends on one custodian's solvency, honesty and operational continuity, plus a merchant set that controls access to redemption. That is a counterparty relationship wearing a token's clothes, and it should be diligenced the way you would diligence a counterparty.

The bridge model puts a proof system where the custodian was

A trustless bridge replaces the custodian with code: lock on the source chain, emit a message, verify the message on the destination chain, mint. The exposure moves from a balance sheet to a verification routine, which is a different risk rather than a smaller one.

Wormhole is the case to study because the failure was clean. On 2 February 2022 an attacker exploited the protocol's contract code to mint 120,000 wrapped Ethereum on Solana without posting the equivalent ETH collateral on the source chain. Chainalysis put the value at over $320 million and described the consequence precisely: that $320 million of wrapped ETH on Solana was unbacked for a period, and Solana platforms accepting it as collateral could have become insolvent as a result.²

The resolution is the part founders should sit with longest. Jump Trading, Wormhole's parent company, supplied Ether to replace what was stolen after attempts to pay the attacker a bounty went unanswered.² Holders were made whole by a private firm choosing to absorb a $320 million loss. That was a commercial decision, not a contractual obligation, and no line of code compelled it. If your protocol accepts a wrapped asset, you are underwriting the possibility that the next such decision goes the other way.

Keys and configuration are the other two ways it breaks

Ronin is the key-compromise version. On 23 March 2022 an attacker used compromised private keys to drain the Ronin bridge in two transactions, taking 173,600 ETH and 25.5 million USDC, a total loss of $610 million.³ The detail that should change how you think about monitoring is the timeline: the network issued its community warning on 29 March, and officials reportedly discovered the breach only after a user reported being unable to withdraw 5,000 ETH.³ Six days, and a support ticket was the detection mechanism.

Nomad is the configuration version, and it needed no cryptography to fail. In routine operation a user proves a deposit against a Merkle root that the bridge's Replica contract has accepted. To simplify deployment, the team added the ability to initialise a contract at a specific root. When Home and Replica were freshly deployed the root was zero, so confirmAt[0] was set to 1, and a call carrying a non-existent message resolved in Solidity to acceptableRoot(0), which then passed. Any invalid message could be executed on the destination chain, and the August 2022 exploit cost around $190 million.⁴

Three incidents, and no two of them broke at the same layer. Signature verification, key custody and deployment configuration are separate surfaces, and a bridge is only as sound as the weakest of them. A holder of the wrapped asset is exposed to all three at once and can inspect none of them from the token contract.

What to settle before your design accepts a wrapped asset

Five questions, and they belong in the risk register rather than the integration ticket. Who can mint, named as an entity or a contract with an address. What proves the reserve, at what frequency, published where. What the redemption path is when the venue is under stress rather than on a calm Tuesday. Who is obliged, contractually rather than reputationally, to make holders whole if backing is lost. And what your own protocol does mechanically on the day the wrapper trades away from its underlying.

That last one is the one teams skip and the one that decides the outcome. If your lending market accepts a wrapped asset at a one-to-one price assumption, you have written the bridge's failure directly into your solvency. Pricing the wrapper independently, capping exposure, and defining a circuit breaker in advance are all cheap before an incident and unavailable during one.

Our position with founders is simple enough. A wrapped asset is a credit exposure to its issuer or its bridge, and it should be sized like one. Treat it as equivalent to the native asset in your model and you have made an assumption the mechanism does not support.