When you bridge a crypto asset, the original token usually stays where it was, gets destroyed, or becomes part of a settlement arrangement. What arrives on the other chain depends on a set of contracts, messages, and promises that most wallet interfaces never explain.
Your wallet says the transfer is complete.
The USDC you held on Ethereum is now showing up on another blockchain. The amount looks right, the destination address is yours, and the transaction has been confirmed.
Nothing about the experience suggests anything unusual happened.
But consider what the word ‘transfer’ actually implies.
When someone sends money between two accounts at the same bank, the institution updates its records. When a physical object moves from one place to another, it leaves its original location.
A blockchain bridge doesn’t necessarily do either of those things in the way users might expect.
Ethereum and Solana, for example, maintain separate transaction histories and independently determine the validity of their states. One network cannot simply reach into the other network’s ledger and change a token balance.
That creates a problem for anyone who wants to use an asset on both networks.
How do you make a token available on a blockchain that never issued it?
The answer is surprisingly varied.
Some bridges keep the original asset in custody and create a representation elsewhere. Others destroy tokens on one chain and authorize the creation of an equivalent amount on another. Liquidity networks may use funds that were already sitting at the destination, settling the transfer between intermediaries afterwards.
All three approaches can produce an almost identical experience inside a wallet.
Yet they leave the user holding economically different things.
The distinction goes beyond technical architecture. It determines what backs a token, who must be trusted, where liquidity comes from, and what can go wrong when a bridge fails.
To understand a cross-chain transfer, it helps to stop imagining a token traveling between blockchains.
Instead, follow what happens to the original asset—and what the receiving blockchain is persuaded to recognize.
The Token That Stayed Behind
Imagine Alice holds 10 ETH on Ethereum.
She wants to use those assets in an application on Solana, but the application cannot directly recognize a native Ethereum balance.
A conventional solution is to deposit the ETH into a bridge contract.
The contract takes custody of the asset on Ethereum. Meanwhile, a corresponding representation is created on Solana, allowing Alice to use something that tracks the value of her original ETH.
The arrangement is commonly described as lock-and-mint.
The terminology matters because it explains the financial relationship that has just been established.
Alice’s original ETH has not left Ethereum. It remains locked under the bridge’s custody arrangements.
What Alice receives on Solana is a different token representing a claim against that locked asset.
Wormhole’s Wrapped Token Transfers documentation describes this mechanism directly: assets originating on one network are locked in custody, while corresponding wrapped tokens are minted on the destination network.
The process also involves a verified cross-chain message that authorizes the receiving network to recognize the deposit.
From Alice’s perspective, she can now trade or deploy ETH-like exposure in a different ecosystem.
From an accounting perspective, however, the position has acquired an additional layer.
The asset on Ethereum serves as the backing. The token on Solana serves as the representation.
That difference might be invisible during ordinary trading.
It becomes crucial when Alice wants to return to Ethereum.
In the reverse operation, the wrapped representation is burned, and the original ETH is released from custody after the required verification.
A functioning system must ensure that claims cannot be redeemed more than once and that newly issued representations correspond to properly secured backing.
Otherwise, it risks creating claims that exceed the assets available to satisfy them.
The Same Capital, Two Visible Balances
Consider a simplified bridge holding 10,000 ETH.
Assume each ETH is worth $3,000, giving the original escrowed assets a market value of $30 million.
The bridge has also issued 10,000 corresponding wrapped tokens on another chain.
At an assumed $3,000 valuation per wrapped token, a dashboard could display two positions.
| Recorded position | Market value |
|---|---|
| Original ETH locked in custody | $30 million |
| Wrapped ETH on the destination chain | $30 million |
| Naive sum of both positions | $60 million |
| Underlying ETH backing the arrangement | $30 million |
Ravel’s hypothetical bridge-accounting illustration. This is not an actual TVL calculation from Wormhole or another bridge.
There are $60 million in displayed asset and claim values if the positions are added without adjustment.
But the arrangement began with $30 million of ETH.
The additional $30 million is a tokenized representation, not another independently deposited pool of ETH.
That doesn’t make the wrapped tokens imaginary.
They may be transferable, usable as collateral, and accepted in functioning markets.
But their value depends partly on the ability to redeem them against the original assets.
The second balance represents an additional financial claim. It does not mean another $30 million of underlying capital entered the system.
This issue is the same accounting problem that appears when DeFi protocols build multiple layers of financial positions on top of existing assets.
Bridges make the relationship particularly visible because the underlying asset and its representation live on different blockchains.
What Actually Crosses Chains Is Often a Message
If the original asset doesn’t travel, the receiving blockchain still needs a reason to create or release something.
That reason usually arrives in the form of authenticated information.
A source-chain event might establish that Alice deposited 10 ETH, that the intended destination is Solana, and that a specific receiving address should receive the corresponding representation.
The destination cannot simply assume that the event occurred.
Someone—or some verification mechanism—must establish that the information is authentic and sufficiently final.
This is where cross-chain messaging becomes central.
A Message Is Not the Asset It Describes
Wormhole’s messaging infrastructure provides a concrete example.
According to its Verified Action Approvals documentation, Wormhole Guardians can observe and verify messages emitted through the protocol.
Once the required supermajority agrees, the Guardians sign the message, producing a Verified Action Approval, or VAA.
That signed message can then be submitted to a contract on the destination chain.
The destination contract verifies the message and performs the authorized action.
In a wrapped-token transfer, that action might be minting the appropriate representation or releasing previously held assets.
The message is not itself a transfer of the original ETH.
It is evidence that a qualifying event occurred elsewhere.
This separation introduces an important security consideration.
A destination contract must know whether the message genuinely came from an authorized source, whether its contents are valid, and whether it has already been processed.
A system that accepts the same transfer authorization repeatedly could create duplicate claims.
A system that accepts forged messages could release funds or mint tokens without legitimate backing.
The strength of the bridge therefore depends on more than the security of the two blockchains.
It also depends on the mechanism connecting their records.
A bridge asks one blockchain to act on information about another. The security of that information becomes part of the asset’s security.
The Wormhole Exploit Showed What Happens When Verification Fails
The consequences became apparent on February 2, 2022, when Wormhole suffered an exploit involving 120,000 wrapped ETH, worth approximately $325 million at the time.
Blockchain analytics firm Elliptic’s investigation of the Wormhole incident described how an attacker exploited weaknesses in the verification process to mint wrapped ETH without the corresponding legitimate backing.
The attacker was then able to extract assets through the bridge.
This was not a case of native Ethereum suddenly losing its ability to record balances.
The failure occurred in the infrastructure responsible for validating cross-chain claims.
That distinction matters.
The bridge’s accounting and authorization system had accepted activity that should not have resulted in legitimate token issuance.
Wormhole subsequently restored backing to the affected assets, but the incident exposed the vulnerability inherent in accepting representations of value based on cross-chain messages.
It would be wrong to assume every bridge uses the same verification system or shares the same historical vulnerabilities.
Many architectures differ substantially in their security assumptions, authorization mechanisms, and safeguards.
Nevertheless, the structural lesson remains relevant.
If a destination blockchain accepts an invalid claim about what happened elsewhere, the tokens it issues can appear legitimate even when the underlying financial event never occurred.
The user may see a normal-looking wallet balance.
The failure sits beneath it, in the machinery that authorized the balance to exist.
Not Every Bridge Creates a Wrapped Token
The lock-and-mint model explains one family of cross-chain transfers.
It does not explain all of them.
Consider someone moving native USDC between Ethereum and Base using Circle’s Cross-Chain Transfer Protocol, or CCTP.
In this arrangement, the protocol does not need to lock USDC in a conventional third-party bridge vault and create a separate wrapped version.
Instead, the source-chain tokens are burned and an equivalent amount of native USDC is authorized for minting on the destination chain.
Circle’s CCTP technical documentation describes this burn-and-mint approach for transferring native USDC across supported blockchains without traditional bridge liquidity pools.
The distinction is subtle from the user’s perspective.
The sender’s balance decreases on Ethereum.
The recipient’s balance increases on Base.
The wallet experience looks much like an ordinary cross-chain transfer.
But the supply accounting is fundamentally different.
Following 10,000 USDC From Ethereum to Base
Suppose Alice has 10,000 native USDC on Ethereum.
She uses a CCTP-enabled route to transfer the tokens to her wallet on Base.
For this illustration, ignore fees and assume the transfer completes successfully.
Before the transfer, Alice holds 10,000 USDC on Ethereum and none on Base.
The CCTP process burns the 10,000 tokens on Ethereum.
Circle’s attestation infrastructure then validates the source-chain event according to the relevant finality requirements and provides the authorization needed to mint USDC on Base.
The destination contract processes that authorization and creates 10,000 native USDC for Alice.
The result is:
| Alice’s position | Ethereum | Base |
|---|---|---|
| Before transfer | 10,000 USDC | 0 USDC |
| After source burn, before destination mint | 0 USDC | 0 USDC |
| After completed destination mint | 0 USDC | 10,000 USDC |
Ravel transaction reconstruction. Assumes no transfer fees, a successful route, and no other wallet activity. The middle row describes Alice’s token balances while the transfer remains in progress, not a permanent destruction of her economic entitlement.
Unlike lock-and-mint, this approach does not leave a corresponding amount of USDC sitting in a third-party bridge vault as backing for a wrapped token.
The token is destroyed on the origin chain and created on the destination chain under the issuer’s authorized mechanism.
Across the two chains, the transfer changes the distribution of native USDC supply without creating an additional wrapped claim.
The issuer’s reserve obligations remain relevant, but the transfer is not intended to create an extra 10,000 USDC of outstanding liabilities.
For Alice, the practical difference is significant.
She receives native USDC on Base rather than a separately issued bridge representation.
However, CCTP still has security and operational dependencies.
The mechanism relies on valid burn events, the attestation process, authorized minting contracts, and successful execution on the destination chain.
And using the native USDC transfer model does not eliminate the broader risks associated with USDC’s issuer or the destination blockchain.
Removing one bridge-custody dependency does not remove every trust assumption. It changes which dependencies matter.
The Same Symbol Can Conceal Different Assets
A particularly important complication is that native and bridged assets can coexist on the same blockchain.
Circle’s USDC versus USDC.e explainer distinguishes native USDC issued by Circle from bridged representations issued through third-party arrangements.
They may track the same dollar reference value.
They may even trade at nearly identical prices.
But they are not the same contractual and technical instrument.
Native USDC represents the issuer’s token on a supported chain, subject to its applicable terms and redemption arrangements.
Bridged USDC generally depends on a third-party bridge and the assets securing its representation.
A wallet displaying a familiar token symbol may not make that distinction obvious.
Applications can also differ in which contract addresses they accept.
A user attempting to deposit the wrong version into a DeFi application could discover that a seemingly familiar asset is unsupported.
This makes token identity more than a branding concern.
The token contract address and issuance mechanism determine what the holder actually owns. A familiar ticker does not.
Some Bridges Don’t Mint Your Tokens. They Pay You From Someone Else’s Liquidity.
Now consider a third approach.
Alice wants to move 25,000 USDC from one network to another.
Rather than waiting for a wrapped representation to be minted or for issuer-authorized supply to move between chains, a liquidity-based protocol can arrange for an intermediary to deliver existing funds on the destination network.
The intermediary provides the destination tokens first and receives compensation after the original deposit is verified and settled.
The user experiences a transfer.
Economically, part of the mechanism resembles short-term liquidity provision.
Across offers a useful example.
Its cross-chain intent lifecycle documentation describes a process in which the user’s assets are deposited into a source-chain contract, a relayer fills the order using its own destination-chain funds, and the protocol later validates the activity and reimburses the relayer.
The user’s destination funds can arrive before the complete settlement between the protocol’s infrastructure and the intermediary has finished.
This changes what ‘bridging’ means.
Alice is not necessarily waiting for the original token to be recreated somewhere else.
She is receiving funds that already exist at the destination.
The relayer accepts the temporary cost and risks associated with providing those funds.
The eventual settlement reimburses that intermediary under the protocol’s rules.
Ravel’s $25,000 Liquidity Test
Consider a simplified cross-chain transfer.
Alice deposits 25,000 USDC on the origin chain.
Assume the quoted fee is 0.20% of her deposit, equivalent to $50.
A relayer delivers 24,950 USDC from the existing destination-chain liquidity.
The simplified accounting is as follows:
| Participant or activity | Amount |
|---|---|
| Alice’s source-chain deposit | 25,000 USDC |
| Destination tokens delivered by relayer | 24,950 USDC |
| Difference between input and output | 50 USDC |
| Alice’s received amount | 24,950 USDC |
Ravel’s hypothetical transfer. The 0.20% fee is assumed solely for illustration, not a current Across quote. The $50 difference may cover protocol, liquidity, relayer, gas, and other route-specific costs; it is not necessarily the relayer’s net profit.
The critical point is where the received tokens came from.
The destination assets were already available to the relayer.
Alice’s original deposit becomes part of the arrangement used to verify, reimburse, and settle the liquidity advanced to her.
In the full settlement process, liquidity may be rebalanced among chains, repayment may occur in a different location from the original deposit, and the relayer may carry exposure until reimbursement is completed.
The details vary by protocol and route.
For users, the attraction is speed and convenience.
For analysts, it introduces a different financial question: how much destination-side liquidity can intermediaries provide, and under what conditions are they willing to provide it?
A network can have technically reliable messaging while still struggling to process large transfers when available destination liquidity is insufficient or uneconomical.
The reverse is also possible.
A well-capitalized liquidity network can deliver funds quickly while settlement continues behind the scenes.
In a liquidity-based bridge, the destination transfer can be an advance from another participant, not a direct movement of Alice’s original tokens.
Why Fast Bridges Need a Different Risk Analysis
Speed is often presented as a central measure of bridge quality.
But execution speed cannot be interpreted without understanding which party bears the waiting risk.
In a liquidity-based arrangement, a relayer may advance capital and accept reimbursement risk.
In an attestation-based arrangement, a system may wait for source-chain confirmations before authorizing the destination action.
Other architectures can provide faster execution under additional finality or trust assumptions.
The user may only notice that one route delivers tokens in seconds while another takes longer.
The economic difference may involve financing costs, available liquidity, verification assumptions, or settlement risk.
That is why a low quoted fee or fast transfer time cannot, on its own, establish that a bridge is safer or more capital-efficient.
The waiting period has not always disappeared. Occasionally the protocol has transferred it from the user to an intermediary.
The Claim Behind the Token Is Where Bridge Risk Actually Lives
Three transfer mechanisms can now be distinguished.
In a lock-and-mint bridge, the user receives a representation backed by assets held elsewhere.
In a burn-and-mint system, tokens are destroyed and reissued under an authorized cross-chain supply mechanism.
In a liquidity network, the user can receive existing destination assets while intermediaries settle their obligations afterwards.
The distinction can be summarized as follows.
| Bridge model | What happens at the origin? | What the user receives at the destination |
|---|---|---|
| Lock-and-mint | Original assets are locked | Newly minted wrapped claims |
| Burn-and-mint | Existing token supply is burned | Newly minted tokens under the supported issuance mechanism |
| Liquidity-based | Deposit enters a settlement arrangement | Existing assets advanced from destination liquidity |
Ravel mechanism comparison. Actual routes can combine these models, use lock-and-release arrangements, or implement additional verification and settlement layers.
These approaches can all perform useful functions.
They also distribute risk differently.
For a wrapped asset, the crucial question is whether sufficient backing remains available and whether redemption can be executed.
For a burn-and-mint system, the integrity of authorized supply changes, and cross-chain verification becomes central.
For a liquidity-based transfer, the user-facing outcome depends on correct fulfillment, available liquidity, and the financial arrangements supporting settlement.
But there is another risk dimension that cuts across these designs: who is permitted to tell the destination chain what happened at the origin?
Canonical Doesn’t Automatically Mean Risk-Free
A canonical bridge is generally the officially designated bridge mechanism for a particular blockchain or rollup ecosystem.
In an Ethereum rollup, it may be integrated with the network’s native settlement and messaging infrastructure.
That can provide a different security basis from an independent bridge relying on an external committee or a separate set of operators.
However, being canonical does not guarantee universal safety.
Rollup bridges can still involve upgrade permissions, delayed withdrawals, sequencing assumptions, smart-contract vulnerabilities, and dependencies on the rollup’s broader architecture.
The Ethereum developer documentation on bridges explains how different bridging systems introduce different assumptions concerning validation, security, convenience, and connectivity.
An externally verified bridge may prioritize broad interoperability and speed.
A system deriving verification from the connected chains may reduce certain external trust assumptions but introduce other trade-offs.
The important issue is whether the user understands those trade-offs before relying on the bridge.
A token carrying the label ‘canonical’ does not eliminate the need to examine its contract, backing, or withdrawal process.
The Ravel Bridge-Claim Test
A more useful examination of a bridge begins with five questions, rather than evaluating it solely by its advertised speed or total volume.
What happened to the original asset?
Was it locked, burned, transferred to a liquidity pool, or exchanged through another arrangement?
This process identifies the source of the destination asset’s economic value.
What exactly arrived in the wallet?
Is the received token native to its destination chain, issued by the original asset issuer, created by a third-party bridge, or supplied from existing liquidity?
The token’s origin determines whether the holder has a direct asset or an additional financial claim.
Who authorized the destination action?
Was the transfer validated using a signed attestation, an external validator set, proof derived from the connected chains, or another verification mechanism?
The answer identifies which system must remain honest and technically correct.
What must happen for the holder to exit?
Can the asset be redeemed directly, burned to release backing, exchanged against available liquidity, or withdrawn only after a settlement period?
An asset that looks fully transferable during normal conditions may encounter significant friction when large numbers of users seek to exit simultaneously.
What breaks if one dependency fails?
This is the most revealing question.
A bug in a message-verification contract could create unauthorized claims.
A compromised custody arrangement could threaten the backing of wrapped tokens.
An unavailable relayer might delay fulfillment.
A liquidity shortage could make a route temporarily unavailable or more expensive.
And an interruption affecting the origin or destination blockchain could prevent the transfer from completing.
A risk assessment that stops at the visible token balance misses these dependencies.
The Backing-Ratio Test
For a lock-and-mint bridge, the relationship between escrowed assets and outstanding wrapped claims can be particularly informative.
Suppose a hypothetical bridge holds one million native tokens in custody.
It has issued one million wrapped representations.
Assuming all claims are entitled to one unit of the underlying asset, the system begins with full nominal backing.
Backing ratio = 1,000,000 / 1,000,000 = 100%.
Now imagine a hypothetical verification failure allows 100,000 additional wrapped tokens to be minted without a corresponding deposit.
The outstanding wrapped claims rise to 1.1 million tokens.
The escrowed backing remains one million.
The ratio becomes:
1,000,000 / 1,100,000 × 100 = 90.91%.
| Hypothetical backing measure | Before invalid mint | After invalid mint |
|---|---|---|
| Original tokens held in custody | 1,000,000 | 1,000,000 |
| Wrapped claims outstanding | 1,000,000 | 1,100,000 |
| Nominal backing ratio | 100% | 90.91% |
Ravel hypothetical backing calculation. Assumes identical units, one-for-one claims, and no subsequent recovery, asset losses, or additional deposits. It does not describe any current bridge’s solvency.
The deficit is 100,000 underlying tokens.
Importantly, a 90.91% backing ratio does not guarantee that each wrapped token will trade at 90.91% of its intended value.
Market pricing also depends on the redemption rules, expectations of recovery, liquidity, claim priority, and whether losses are shared or concentrated among participants.
The calculation establishes the shortfall in nominal backing under the stated assumptions.
It does not predict an exchange price.
Still, the distinction is economically significant.
The destination token can remain transferable after the bridge’s ability to honor all of its claims has been impaired.
Transferability and full backing are separate properties.
A wallet showing a balance cannot prove both.
What Really Crosses the Bridge?
The phrase cross-chain transfer makes interoperability sound like a straightforward movement of assets between two locations.
The underlying reality is more complicated and more compelling.
Sometimes the original asset is locked while another blockchain issues a claim against it.
Sometimes the original token supply is burned and an issuer-authorized amount is minted elsewhere.
Occasionally an intermediary delivers assets that were already available on the destination chain, then gets reimbursed after the transaction is verified.
In each case, separate blockchains coordinate changes in their records.
The asset does not need to physically travel for the user to obtain equivalent purchasing power, token exposure, or application access somewhere else.
That is what makes bridges so useful.
They allow independently maintained blockchain systems to interact without requiring every application and asset to live on one network.
But every method of achieving that interaction relies on particular assumptions about authorization, custody, backing, liquidity, and settlement.
Those assumptions are part of the asset’s financial character.
A wrapped token may trade at the same market price as its underlying asset while carrying additional bridge-specific risks.
Native tokens minted through a cross-chain issuance mechanism may avoid certain custody exposures while remaining dependent on valid attestations and authorized contracts.
Liquidity-based transfers may eliminate much of the user’s waiting time by placing financing and settlement responsibilities on intermediaries.
None of those structures is inherently equivalent to simply picking up a token and carrying it somewhere else.
The next time a wallet displays a successful bridge transfer, the most useful question may not be how quickly the tokens arrived.
It is whether the balance represents the original issuer’s asset, a redeemable claim on locked collateral, or liquidity delivered through a separate financial arrangement.
The token didn’t need to cross the bridge. What crossed was an instruction, a verified claim, or an obligation that another participant agreed to fulfill.
And that difference determines what the holder actually owns.
