Wrapped BTC on Ethereum is not Bitcoin. It is an IOU whose value depends entirely on whoever holds the Bitcoin behind it.
Dario FennDeFi & Markets Lead · DeFi protocols, yield, market structure and on-chain data
A wrapped asset is a token on one chain representing an asset held elsewhere. The custody arrangement determines the risk: a single custodian, a federation of signers, an MPC network, or a bridge contract. Verify backing by comparing the reserve address balance against token supply on-chain, and check who can mint, who can freeze, and what the redemption path is. A bridge-minted wrapper is a claim on that bridge and depegs if it is exploited.
Bitcoin cannot run on Ethereum. What runs on Ethereum is a token that says one BTC is being held somewhere on your behalf, and everything about its risk is contained in who is holding it and what they can do.
This applies far more widely than Bitcoin: wrapped ETH on other chains, wrapped stablecoins, wrapped staking derivatives, and every asset that arrived on a chain through a bridge. In each case the question is identical.
One regulated entity holds the underlying asset and mints a token against it, with a set of merchants able to request minting and burning. Backing is verifiable — the reserve addresses are published, and anyone can compare the on-chain balance against the token supply.
The exposure is that custodian: its solvency, its jurisdiction, its operational security, and its ability to freeze or blacklist. That is a small and well-defined set of risks, which is why this model has held the largest wrapped balances for years. It is also a genuine centralisation, and a change of custodian or of controlling ownership is a material event for holders — as the market's reaction to exactly that happening in the wrapped Bitcoin market demonstrated.
A group of independent entities jointly controls the reserves, requiring a threshold to move funds. This distributes the trust across organisations rather than concentrating it, and it is the structure behind several sidechain and cross-chain assets.
The security is exactly the honesty and key hygiene of that group, so the questions are the same as for any validator-set bridge: how many members, are they genuinely independent, and how large is the balance relative to the effort of compromising a threshold.
Reserves are controlled by a network of nodes producing signatures collectively, with no complete key existing. This removes the single-key failure and, depending on the design, allows a larger and more open participant set.
The trade is complexity: correctness now depends on the protocol implementation and on the incentive design keeping node operators honest. It is harder to reason about than a published custodian, and there is usually no independent attestation of reserves to fall back on.
The most common and the least examined. When you bridge an asset that has no canonical presence on the destination chain, the bridge locks the original and mints a representation. That token is a claim on the bridge's locked reserves and nothing else.
If the bridge is exploited, the reserves leave and the wrapper is worthless while the original asset is unaffected. This is not hypothetical — every large bridge exploit has produced exactly this outcome for holders of its wrapped assets, and the mechanism is why bridge trust models matter to people who never consciously used a bridge.
It also fragments liquidity. Several bridges wrapping the same asset on the same chain produce several non-fungible versions, each with its own depth and its own risk, and the one you hold is determined by which route you happened to use.
For assets with a cooperating issuer, there is a better path. A native issuance route burns on the source chain and mints canonical tokens on the destination — Circle's CCTP does this for USDC — so what arrives is the issuer's own asset, not a claim on a bridge. Where this exists, use it; the distinction is developed in native versus wrapped bridging.
Some chains also operate an official bridge whose wrapped asset is treated as canonical by the ecosystem, which at least concentrates liquidity into one version even if the trust model is unchanged.
Four checks, none of which need special tools.
**Supply against reserves.** Find the published reserve addresses, read the balance on a block explorer, compare against total supply of the wrapper. Any wrapper that does not publish addresses has failed the first test.
**Mint authority.** Who can create new tokens, and under what control? An upgradeable contract with a single owner key is a different asset from one behind a timelocked multisig.
**Freeze and blacklist.** Custodial wrappers generally can freeze. Know whether yours can before you rely on it as collateral, because a frozen position in a lending market gets liquidated while you cannot act.
**Redemption.** Who can convert back to the underlying, at what size, and through what process? If redemption is limited to a whitelist of merchants, your exit is the secondary market's depth, which is the same structural issue as stablecoin redemption access.
Prefer the canonical version on any chain where one exists, and check which version a pool or lending market actually uses before depositing. Treat wrapped exposure as a separate risk from the underlying asset, not as the same position in a different place. And keep long-term holdings in the native asset on its own chain — wrapping is a tool for doing something specific on another chain, and the moment you are not doing that thing, the wrapper is uncompensated risk.
Bridges have lost more value than any other category in crypto, and almost always at the same point: whoever attests that funds arrived on the other side.
A myth-busting look at the difference between letting an exchange hold your keys and holding them yourself, with the real-world collapses that made the distinction matter.
A tokenized bond is only as good as the custodian holding it, the legal entity issuing it, and your ability to actually redeem it. A framework for the risks that live off-chain in every RWA tokenization deal.