Wrapped or native assets: an integrator’s choice

Wrapped assets give an application a token it can use on a destination chain; native assets keep the asset on its original chain and require the application to reach that chain’s settlement or liquidity. The choice determines which contracts an integrator supports, where liquidity must sit, and which component can fail. It is not a choice between a real asset and a fake one: a wrapped token is a real token on its own chain, but its claim on an asset elsewhere depends on a bridge, issuer, or other backing mechanism.

What changes when an asset is wrapped?

A wrapped asset is a chain-local token that represents an asset held or controlled under a separate system. Its contract can expose familiar token operations to destination-chain applications, while the bridge or issuer manages the relationship to the original asset. That makes the wrapped token usable in the destination chain’s contracts, wallets, and liquidity pools without those components directly handling the source chain’s transaction format.

In a lock-and-mint bridge, the user sends the original asset to a source-chain contract or address controlled by the bridge. The bridge verifies that deposit, then causes a destination-chain token contract to mint a corresponding amount to the recipient. To return, the user burns or locks the wrapped tokens; after the bridge verifies that event, it releases the original asset. The exact verification mechanism matters: a federation may attest to deposits, while another bridge may use a light client, proof system, or validator set. The token contract alone does not establish that the source asset is safely held or that a valid deposit occurred.

WBTC illustrates a custodial model. It is an ERC-20 token representing Bitcoin, with minting and redemption mediated by merchants and a custodian. The user’s ERC-20 transfer can settle on Ethereum without a Bitcoin transaction, but the link to BTC relies on the custody, mint, burn, and redemption process. For a broader account of a route that exchanges BTC for ETH without making a wrapped BTC token the destination asset, see thor swap. The distinction is useful: cross-chain value movement does not always require representing the source asset as a token on the destination chain.

What does native support require from an integrator?

Native support means an application transacts with the asset on the chain where that asset is native. For Bitcoin, a native BTC deposit is a Bitcoin transaction; an ERC-20 representation of BTC is not. A cross-chain application may coordinate activity across chains, but it must still account for each chain’s confirmation rules, transaction construction, address format, fee asset, and settlement state.

For a direct native-asset swap, one system can accept the source asset on its chain and arrange delivery of the destination asset on its own chain. THORChain, for example, routes supported assets through liquidity pools paired with RUNE: the source asset is exchanged into RUNE, then RUNE into the destination asset, and the destination chain’s vault sends the resulting native asset. The user sees one route, but the mechanism depends on pool depth, network confirmation, and the vault’s ability to make the outbound transaction. This pattern supports exchange between native assets; it does not give an Ethereum contract a native BTC balance that it can call.

Native access therefore does not eliminate integration work. The application may need chain-specific deposit detection, finality handling, retries, refund paths, and asynchronous state. A destination contract cannot assume that an external-chain event is final merely because a service reported it. Integrators must define what counts as sufficient source-chain confirmation, what happens if an outbound transaction is delayed, and how users can inspect the transaction on each chain.

Which model fits a particular product?

Choose the model that matches the application’s execution environment and the failure modes it can explain. A destination-chain lending market needs a token its contracts can transfer, account for, and liquidate on that chain. A wallet or swap interface can instead coordinate native deposits and withdrawals without making a wrapped token available to destination-chain contracts. Some products need both paths, but should keep their asset identities and risk disclosures separate.

Compare the options across the boundaries that affect users and protocol accounting:

• Contract compatibility: A wrapped token can compose with destination-chain contracts that support its token standard. Native assets require the application to operate on the asset’s own chain or use a system that coordinates cross-chain settlement.
• Backing and control: Identify who holds the source asset, who can mint or pause the representation, and how deposits are verified. For native routing, identify the vault or settlement mechanism that receives and sends the underlying assets.
• Liquidity and exit: A wrapped token needs usable destination-chain liquidity and a working redemption route. Native routing depends on source and destination liquidity, plus reliable inbound and outbound processing.
• Failure and recovery: Specify how the product handles a bridge halt, delayed finality, failed outbound transfer, depleted pool, or unavailable redemption path. Show users the status and chain-specific transaction references.

What should an integration verify before launch?

Verify the exact token contract and chain, not just the ticker or display name. A symbol such as BTC does not identify whether a balance is Bitcoin, a custodial ERC-20, or a bridge-issued representation. Record the contract address, decimals, chain identifier, and any permitted upgrade or pause controls. For bridged assets, review the verification path from source-chain event to destination mint, the authority that can change that path, and how the system prevents replay or duplicate minting.

Then test the operational edge cases against the actual route. Confirm how the application detects deposits, distinguishes pending from final, handles chain reorganizations where relevant, and reconciles amounts after fees. Exercise a delayed or failed withdrawal and verify the user can determine whether funds remain in a contract, await an attestation, or need a retry. Publish the redemption conditions and the party or mechanism responsible for completing it.

For most applications that need assets inside destination-chain contracts, a well-supported wrapped token is the practical fit because it composes with existing token interfaces. That convenience transfers risk to the representation’s backing and bridge controls. If the product only needs to exchange or route assets across chains, native settlement can avoid creating another token claim, while adding cross-chain coordination and liquidity dependencies. Integrators should choose based on the product’s execution needs and make the resulting trust boundary visible.