Wrapped asset

Reading depth

Each view includes the earlier layers; the complete engineer or auditor page is shown by default.

BeginnerCore purpose and mental modelPractitionerAdds mechanisms and economicsEngineer or auditorAdds state and verification

Dependency check

Advanced detail assumes prerequisite knowledge

Before using practitioner mechanisms or engineer and auditor checks, review any unfamiliar dependency. These paths come from canonical depends_on relationships; Web3 Academy does not track completed lessons.

Review 4 dependencies

• AssetRequired through Asset versus claim

  1. Wrapped asset
  2. Asset versus claim
  3. Asset

• ClaimRequired through Asset versus claim

  1. Wrapped asset
  2. Asset versus claim
  3. Claim

• TokenRequired through Asset versus claim

  1. Wrapped asset
  2. Asset versus claim
  3. Token

• Asset versus claimDirect prerequisite

  1. Wrapped asset
  2. Asset versus claim

A wrapped asset is a token representation designed to make another asset usable through a different token interface, contract, or blockchain.

Category: Money and assetsCircle category cue

System record

Start with the economic purpose, participants, resources, and entitlements before studying implementation detail.

Why it exists

Wrapping lets an asset enter applications or networks whose interfaces cannot use the original asset directly, while preserving a conversion path.

Traditional-finance analogy

Depositary receipt is the closest comparison recorded for this concept.

Where the analogy stops

• Some wrappers are same-chain smart contracts with deterministic conversion, while others rely on custodians, bridges, validators, or issuers.
• The wrapper can add contract, bridge, liquidity, and governance risks even when the referenced asset itself remains unchanged.

Main actors

• ActorWrapper holder
• ActorDepositor and redeemer
• ActorWrapper contract, custodian, or bridge
• ActorAdministrator or verifier when applicable

Assets and claims

Assets — controlled or transformed resources

Assets are resources the mechanism moves, holds, values, or transforms.

• AssetUnderlying asset
• AssetWrapped token units

Claims — entitlements and corresponding dependencies

Claims are rights to value, repayment, redemption, control, or another party's performance; each depends on an obligation or system that must honor it.

• ClaimConversion or redemption claim on the underlying asset

A wrapped asset is a token that represents another asset so the represented value can be used through a different interface, contract, or blockchain.

Why it exists

Applications expect particular token interfaces and networks cannot normally read or transfer each other’s native state. Wrapping creates a compatible unit and a conversion path. It also creates a new claim whose safety depends on how the original asset is locked, accounted for, and released.

Traditional-finance analogy

A depositary receipt is a useful analogy: the holder trades a representation while another system accounts for the underlying asset. The analogy is limited because some wrappers are deterministic same-chain contracts, while others add a custodian, bridge, validator set, administrator, or separate chain.

Three wrapper models

Table: Three wrapper models

Model	Conversion authority	New dependencies
Same-chain contract wrapper	A contract accepts and returns the native or underlying asset	Contract correctness and local-chain execution
Custodial wrapper	An institution holds the underlying and issues tokens	Custody, issuer solvency, operations, and legal redemption
Bridge wrapper	A cross-chain mechanism locks or accounts for value and issues a representation elsewhere	Message verification, validators, both chains, bridge contracts, and liveness

Do not infer one model’s trust assumptions from another model’s token name or nominal conversion ratio.

Step-by-step wrapping lifecycle

1. Select the underlying asset, destination interface or chain, and conversion authority.
2. Lock, receive, or otherwise account for underlying units under the wrapper’s custody model.
3. Validate the received amount, fees, token behavior, and any cross-chain finality condition.
4. Mint no more wrapped units than the accountable conversion rule permits.
5. Allow wrapped units to transfer or compose while keeping the underlying and claim ledgers distinct.
6. On redemption, consume wrapped units before releasing the matching underlying value exactly once.
7. Reconcile remaining underlying, wrapped supply, pending claims, and any shortfall.

Assets, claims, and state changes

The underlying asset remains distinct from the wrapped token. The wrapped token is a direct asset at its own on-chain ledger layer and a redeemable claim on the wrapper system when valid units can be converted back into underlying value.

Table: Assets, claims, and state changes

Event	Underlying accounting	Wrapped-token accounting	Required property
Wrap or deposit	Locked or received amount rises	Supply rises	Issuance cannot exceed accountable deposits
Transfer	Usually unchanged	Holder balances change	Authorization and conservation hold
Unwrap or redeem	Locked amount falls	Supply falls	Burned units settle exactly once
Shortfall or inaccessibility	Available amount falls or cannot move	Supply may initially remain unchanged	Loss is surfaced rather than hidden

Capital flow moves the underlying into or out of custody. Claim flow follows wrapped-unit minting, transfer, and burning. Control flow identifies contracts, custodians, bridge verifiers, and administrators that can authorize conversion. Return flow is absent from wrapping itself; any yield must arrive from a separate activity with its own payer and risk. Risk flow reaches holders if accountable underlying assets are missing, inaccessible, frozen, or released through an invalid message.

Return source and loss allocation

Wrapping alone does not create a return. Any apparent yield must come from a separate activity such as staking, lending, reserve investment, fees, or token incentives. That activity can also change redemption value or add another claim layer.

A contract bug, custody shortfall, bridge compromise, chain reorganization, freeze, or redemption pause can leave wrapped units trading below the underlying. First-loss protection is not implicit; without an explicit reserve, equity layer, insurer, or guarantor, holders can absorb the loss.

Engineer or auditor lens

Test conservation between deposits and supply, conversion ratios, decimals, fees, rounding, reentrancy, replay protection, message finality, rate limits, pauses, upgrades, privileged minting, and one-time redemption. Reconcile every chain and custody ledger under the selected model. These are review properties, not claims that a particular wrapper has been verified.

The canonical WETH9 contract is a narrow same-chain example: it accepts native ether through deposit, mints an equal token balance, burns on withdraw, and returns ether. That example does not establish the safety or accounting model of custodial or cross-chain wrappers. The contract source was reviewed 2026-08-10.

Common misunderstandings

• “Wrapped and underlying are the same asset.” They are separate ledger positions connected by a conversion mechanism.
• “One-to-one minting means risk-free.” The underlying can be inaccessible, misaccounted, stolen, frozen, or released incorrectly.
• “All wrappers are bridges.” Same-chain wrappers need no cross-chain verifier; bridge wrappers do.

Continue with claim tokens to compare wrappers with broader protocol-defined entitlements.

Machine-readable model

Key equations

Canonical expressions come from the structured concept record. KaTeX renders the notation, while the plain-text expression and variable table keep its meaning and units inspectable without JavaScript. Read the narrative above for the model's domain, assumptions, and rounding rules.

This concept does not require one canonical equation. Its mechanism and state transitions remain the authoritative explanation; do not invent a formula merely to make the topic look quantitative.

Assurance contract

Security properties

These structured statements define desired behavior. Their stable IDs can bind tests, invariants, specifications, audit findings, or proof results without turning descriptive review advice into an assurance claim.

Desired · not evaluated: No test, audit, or proof result is implied until scoped evidence is linked to this property.

1. SP-01Desired · not evaluated

   Wrapped supply does not exceed locked or otherwise accountable underlying units under the selected model

2. SP-02Desired · not evaluated

   Deposit and withdrawal accounting conserve the conversion ratio subject to explicit fees and rounding

3. SP-03Desired · not evaluated

   Redemption consumes wrapped units exactly once

4. SP-04Desired · not evaluated

   Custody, bridge verification, and administrator powers are explicit when conversion is not purely local

Prerequisites

Direct dependencies recorded by this concept's canonicaldepends_on relationships.

• TokenPath 3

  A token is a programmable ledger entry that represents units a blockchain system can track and transfer.

• Asset versus claimPath 4

  The asset-versus-claim distinction asks whether a token is the resource itself or a right whose value depends on another asset or obligor.

Learn next

Concepts that directly depend on this one, ranked by the recommended learning path. Check each page for additional prerequisites.

• Bridge riskPath 40

  Bridge risk is the possibility that cross-chain messages or asset representations become unauthorized, duplicated, delayed, censored, or no longer backed.

Knowledge check

Quiz

Answer in your own words, then open the model answer.

What problem does Wrapped asset exist to address?

Model answer

Wrapping lets an asset enter applications or networks whose interfaces cannot use the original asset directly, while preserving a conversion path.

Mark as understood