Omnichain Native Assets: Burn-and-Mint and the Cross-Chain Supply Invariant

The real question is not movement, but supply accounting

Cross-chain assets do not physically move from one blockchain to another. A protocol can only remove spendable rights on one ledger and create spendable rights on another ledger. Wrapped tokens, lock-and-unlock pools, and burn-and-mint transfers are different ways to implement that debit and credit operation. Their security difference is not cosmetic. It determines where the balance sheet sits, who can create claims, how failures are attributed, and whether global supply can be audited after something goes wrong.

For a cross-chain swap interface, this distinction is not academic. A user entering [AllSwap cross-chain swap](/exchange-swap) wants to know whether the destination asset is redeemable, whether the quote includes real bridge cost, whether an abnormal route can refund, and whether the router is treating a wrapped claim as if it were a native asset. This article analyzes cross-chain asset movement through a supply invariant model. Wrapped tokens concentrate risk in custody reserves. Lock-and-unlock shifts risk to inventory and release permissions. Burn-and-mint removes a persistent reserve pool but turns issuer authorization, message verification, and minting rights into the critical control plane.

No model is categorically safe. The engineering question is narrower: which failure mode is observable, rate-limited, and attributable enough for a router to price it correctly?

System boundary and threat model

The scope is fungible asset transfer across multiple chains. It does not cover NFT uniqueness, centralized exchange internal ledgers, or offchain market making except where those systems affect settlement. The relevant actors are the asset issuer, the source-chain contract, the destination-chain contract, the cross-chain message verification layer, and the router or solver that selects an execution path.

The attacker does not need to break cryptography. A realistic attacker can observe source-chain events, delay or replay messages, induce users to select the wrong representation, exploit bridge verification bugs, abuse decimal conversion, drain inventory on one side of a lock-and-unlock pool, or use a source-chain reorg to make a destination-chain mint inconsistent with the original burn. Operational mistakes matter as much as adversarial behavior: an unlimited minter role, a stale peer registration, or a token-pool configuration mismatch can be enough to break the supply invariant.

We can model each chain `i` with four quantities:

- `C_i`: circulating token units available to users on chain `i`; - `L_i`: token units locked in escrow on chain `i`; - `B_i`: token units burned on chain `i` while a destination credit is pending; - `P_i`: pending cross-chain liabilities that have not reached final credit or refund.

A minimal global invariant is:

`sum(C_i) + sum(L_i) + pending_liability = canonical_supply`

The formula is simple; the hard part is proving it from onchain state and verifiable logs. A target-chain `totalSupply()` only says how many units a local contract has minted. It does not prove those units are redeemable into an issuer-recognized asset. For wrapped assets, the stronger condition is closer to `wrappedSupply <= reserveBalance - disputedClaims`. For a burn-and-mint system, it is closer to `mintedByBridge <= burnedOnRemote + approvedPendingAllowance`. A router that only reads a token balance but ignores the reserve or authorization model is confusing tradability with redeemability.

Three asset primitives as state machines

A wrapped-token bridge usually follows `lock -> attest -> mint wrapped -> burn wrapped -> release`. The original asset enters a custody contract, and the destination chain receives a claim token. This design works even when the original token contract cannot be modified. The trade-off is obvious: the reserve becomes a high-value target. If the custody contract, validator set, upgrade key, or release logic fails, the destination wrapped asset can become undercollateralized. Bridge exploits have repeatedly shown why this balance-sheet concentration is dangerous.

Lock-and-unlock looks more conservative. The protocol locks assets on the source side and releases already available inventory on the destination side; the reverse route does the opposite. This model fits existing tokens that cannot grant mint and burn rights to a bridge. LayerZero OFT Adapter designs and Chainlink CCIP token pools both support variants of this path. The weakness is inventory planning. The destination side must have releasable liquidity, and both directions need capacity controls. LayerZero’s value-transfer documentation explicitly treats debit and credit combinations as supply invariants, because an arbitrary lock/unlock pairing can fail if the remote side has not planned credit capacity.

Burn-and-mint follows `burn -> attest -> mint`. The source-chain asset is destroyed or removed from circulation, then the destination chain mints the same economic amount after message verification. Circle CCTP is the clearest production example for USDC: a user burns native USDC on the source domain, Circle’s attestation service signs the message after the required confirmation policy, and the destination domain mints USDC through the message receiver flow. ERC-7802 also narrows the token interface to `crosschainMint` and `crosschainBurn`, allowing authorized bridge contracts to operate through a standard mint/burn surface.

The operational summary is blunt: wrapped tokens ask whether reserves still exist; lock-and-unlock asks whether inventory matches demand; burn-and-mint asks whether mint authority is constrained correctly. A cross-chain router should not compare only fees and speed. It should treat these asset semantics as part of route quality.

The distinction changes real path selection. A route from Ethereum to an L2 may produce destination USDC through CCTP, through a bridge-wrapped USDC followed by a DEX conversion, or through a solver that fronts local liquidity and rebalances later. All three can show “receive USDC” in a simplified interface. Their failure surfaces are not the same. The first route depends on attestation and mint permissions. The second depends on bridge reserves and DEX depth. The third depends on solver credit, rebalancing discipline, and local inventory.

Engineering the supply invariant

A cross-chain token system needs at least four invariants.

The first is conservation. For a transfer amount `a`, the source side must complete `debit(a)` before the destination side executes `credit(a')`. If both chains use the same decimal precision, `a'` should equal `a`. If decimals differ, the system needs explicit rounding rules. Chainlink CCIP’s token-pool documentation calls out precision loss and version-specific decimal handling because it is not a UI detail. In large or frequent transfers, rounding error becomes real economic loss. If a router does not expose `a - a'` as cost, the quote is incomplete.

The second invariant is uniqueness. A cross-chain message must execute once. Implementations normally derive a message identifier from fields such as source domain, destination domain, nonce, sender, recipient, token, and amount, then mark it as consumed on the destination side. Wormhole NTT keeps onchain state for attestations, peer registrations, rate limits, transceiver registries, and replay prevention. CCTP’s MessageTransmitter and TokenMessenger flow similarly revolve around message emission, attestation, receipt, and forwarding to the mint logic. The goal is to prevent one remote debit from being credited twice.

The third invariant is permission scope. The entity that can mint should be a minimal, bounded set. A burn-and-mint system should not be implemented as “the bridge has unlimited global mint authority.” A safer design binds permissions to token, remote domain, trusted peer, amount window, and revocation process. If one route or one peer becomes suspicious, governance should be able to pause that path without freezing every chain. NTT’s rate limiting and custom transceivers, CCIP’s token-pool architecture, and CCTP’s attestation layer are all attempts to make the control plane narrower than a raw minter role.

This is also where issuer policy becomes a protocol parameter. An issuer may support one chain through native issuance, another through a burn-and-mint protocol, and a third only through third-party wrapped liquidity. A router that treats those outputs as one fungible bucket is throwing away the most important security signal. Permission scope should therefore be indexed as structured data: who can mint, which remote contracts are trusted, what the current allowance or throughput cap is, and whether the route can be paused independently.

The fourth invariant is observability. Operators and users need to answer which burns are finalized but not minted, which locks entered a destination queue but were not released, and which messages are pending because of rate limits, decimal conversion, gas limits, peer misconfiguration, or verification failure. A mature system treats `pending`, `credited`, `refunded`, `expired`, and `challenged` as first-class states. Without those states, the user only sees “processing,” and the protocol team sees a pile of unrelated events.

Observability is not only a support feature. It is part of the safety model. If pending claims cannot be enumerated by token, route, source domain, destination domain, and age, then an incident response team cannot decide whether to pause one path, raise a cap, retry a message, or warn users. The same index should feed public route quality at a coarser level, even if the operational dashboard remains private.

A debit/credit execution model

The cross-chain transfer flow can be reduced to a state machine:

1. `quote(route, amount)` reads asset type, transfer primitive, fee, finality window, rate-limit state, and precision loss. 2. `debit(source, amount)` burns or locks the source-side asset and emits event `E`. 3. `finalize(E)` waits until the source chain reaches the required finality policy. 4. `attest(E)` verifies the event, amount, nonce, recipient, token, source domain, and destination domain. 5. `credit(destination, proof)` verifies the proof, checks replay state, and mints or unlocks the destination asset. 6. `settle_or_refund()` retries, refunds, or escalates if the credit step exceeds the timeout window.

The destination logic can be expressed as a simple guard sequence:

`if consumed[msgId] == true: revert`

`if amountAfterDecimals == 0: revert`

`if !trustedPeer[sourceDomain][sender]: revert`

`if rateLimitExceeded(token, sourceDomain, amount): queue_or_revert`

`consumed[msgId] = true`

`credit(recipient, amountAfterDecimals)`

The order matters. Replay state should be written before any externally risky path. Decimal conversion should happen before minting or unlocking. Rate limits should apply on inbound and outbound flows. Peer checks should bind the remote domain and remote contract, not just an address-shaped value. Otherwise, the system may pass local unit tests while failing under cross-chain retries, source-chain reorgs, destination execution callbacks, or VM-specific address formats.

One subtle implementation issue is address normalization. EVM addresses, Solana public keys, Move object IDs, and Cosmos account formats do not share one native byte layout. A message format that accepts “recipient” as an untyped byte array must still bind it to the destination domain and token contract. Otherwise, a packet can be syntactically valid while semantically targeting the wrong asset account or adapter. This is why cross-chain token systems should treat domain-specific encoding as consensus-critical logic, not as SDK convenience code.

Refund handling also needs an explicit model. In lock-and-unlock, a refund can often unlock the source-side escrow because the original asset still exists in custody. In burn-and-mint, the source asset has already been destroyed. A “refund” may require destination mint failure proof, issuer-side compensation, or a new mint path inside the same issuance system. Burn-and-mint reduces long-term reserve risk, but increases the importance of pending-liability accounting.

Failure modes by primitive

Wrapped tokens fail when reserves diverge from claims. The reserve contract can be drained, an administrator can release funds incorrectly, or a bridge validator set can approve a fraudulent withdrawal. The destination token may still trade, but its redemption basis is gone. Another wrapped-token failure is fragmentation: one original asset may have several bridge-issued representations, each with different liquidity, risk, and acceptance in DeFi. A router must distinguish canonical USDC, bridge-wrapped USDC, and synthetic routing outputs instead of grouping them by ticker.

Lock-and-unlock fails when inventory is not where demand appears. A source-side lock can succeed while the destination side cannot release because the release pool is empty, a peer is misconfigured, the rate limit is exhausted, or the destination execution gas is insufficient. Multi-hop lock/unlock paths compound the problem. Each intermediate pool adds another inventory constraint; those constraints multiply rather than cancel.

Burn-and-mint fails around authority and finality. If a burn is accepted before the source chain is final, a reorg can erase the source-side debit after the destination side has minted. If mint authority is assigned too broadly, an attacker does not need to steal reserves; they can inflate supply directly. If decimal conversion, fee-on-transfer behavior, or rebasing logic is handled as nominal amount rather than shares or net economic value, the destination mint may diverge from the real source-side debit. CCIP’s guidance for rebasing tokens, fee-on-transfer tokens, and mixed decimals exists because ordinary ERC-20 assumptions are not strong enough for cross-chain accounting.

Rate limits are supply firewalls

Many products frame rate limits as a user-experience compromise. For cross-chain assets, they are a supply firewall. If a verification layer or trusted-peer configuration fails, unlimited mint throughput can turn one mistake into global supply corruption. A per-token, per-domain, per-direction capacity limit reduces the blast radius to a bounded time window.

A serious design should limit at least three quantities: maximum transfer size, total notional per time window, and unsettled pending notional. A route may be technically valid but economically unattractive if its pending liabilities are already large. For a non-custodial cross-chain swap, the router should include this state in route scoring. A route with higher fees but available native inventory may be better than a cheaper route stuck behind a saturated burn-and-mint queue. This is why [AllSwap fees](/fees) and routing explanations should distinguish gas, destination execution cost, message verification, liquidity availability, and failure-recovery cost.

Monitoring can stay simple and still be useful. Useful metrics include `pending_notional` per route, `mint_velocity` per domain, `reserve_coverage_ratio` for lockbox routes, destination execution failure rate, and the number of messages that exceed the expected finality window without credit. These metrics do not need to expose internal operational secrets. They can still influence routing weight and reduce the chance that a large order enters a path whose failure radius is already too high.

How AllSwap should interpret native and wrapped outputs

In a user interface, “USDC to USDC” looks straightforward. At protocol level, the router must distinguish native issuer assets, issuer-authorized burn/mint assets, single-bridge wrapped assets, multi-bridge wrapped assets, and solver-fronted synthetic outputs. The first two usually provide stronger redemption semantics. The third depends on bridge reserves. The fourth also introduces liquidity fragmentation and price dislocation. The fifth may be fast, but it adds solver credit and rebalancing risk.

For an AllSwap-style routing layer, asset semantics should be part of scoring, not hidden in a footnote. The scoring function should ask whether the output token is canonical, whether the token contract is recognized by the issuer or target ecosystem, whether the route uses burn/mint or lock/unlock, how much inventory is available, whether a rate-limit queue is active, whether pending notional is high, and whether failed transfers have a verifiable refund path.

The result does not have to be a single binary “safe” label. A better route score is multi-dimensional: execution price, expected arrival time, asset canonicality, refund clarity, reserve or mint-authority risk, and downstream usability. Two users may rationally choose different paths. A small user may prefer immediate cheap settlement through a wrapped route. A treasury or market maker may prefer slower issuer-authorized minting because the received asset is accepted by lending venues and internal accounting systems. The router should preserve that distinction instead of collapsing it into one displayed amount.

This does not turn the product into a bridge-audit dashboard. It prevents inaccurate promises. Common assets such as USDT, USDC, and TRX carry different meanings across chains. A user entering through [/swap/usdt-erc20](/swap/usdt-erc20), [/assets/usdc](/assets/usdc), or another asset page should not be forced to infer whether the output is native, issuer-authorized, bridge-wrapped, or synthetic. Professional users care because the next action may be lending, market making, liquidation, or treasury settlement. If the target protocol accepts only canonical USDC, a bridged representation is not equivalent even if the UI says the amount arrived.

Open problems

Issuer control and open interoperability remain in tension. CCTP-like issuer paths reduce wrapped-reserve risk, but they concentrate trust in attestation and minter authorization. Open bridge designs are more composable, but they are harder to audit as one global supply system.

Cross-chain token standards are still fragmented. ERC-7802 standardizes the minimal crosschain mint/burn interface. LayerZero OFT, Wormhole NTT, and Chainlink CCIP token pools define their own managers, pools, registries, and message verification paths. A router must understand those semantics before it can score risk precisely.

Finality remains a hard boundary. Ethereum, Solana, Aptos, Sui, Cosmos appchains, and L2s do not share one finality model. “Wait N confirmations” is not a rigorous cross-chain rule. Asset systems need finality windows as explicit token-route parameters.

Real tokens are not ideal ERC-20 objects. Decimals, rebasing, fee-on-transfer behavior, blacklists, pausable contracts, and issuer policy can all break a naive conservation formula. The invariant must be defined over shares, net amount, or issuer-recognized accounting units when nominal token units are not stable.

Refund semantics remain under-standardized. A burned source asset cannot simply be rolled back. Users need a verifiable pending claim, retry mechanism, or compensation path. Without that layer, burn-and-mint merely exchanges custody-pool risk for pending-liability risk.

References

[1] Circle CCTP Documentation, Circle, 2026, https://developers.circle.com/cctp

[2] CCTP Technical Guide, Circle, 2026, https://developers.circle.com/cctp/references/technical-guide

[3] CCTP Supported Blockchains and Domains, Circle, 2026, https://developers.circle.com/cctp/concepts/supported-chains-and-domains

[4] Omnichain Fungible Token Standard, LayerZero, 2026, https://docs.layerzero.network/v2/concepts/applications/oft-standard

[5] Value Transfer Implementations, LayerZero, 2026, https://docs.layerzero.network/v2/concepts/value-transfer-implementations

[6] Native Token Transfers Architecture, Wormhole, 2026, https://wormhole.com/docs/products/token-transfers/native-token-transfers/concepts/architecture/

[7] Cross-Chain Token Standard Token Pools, Chainlink CCIP, 2026, https://docs.chain.link/ccip/concepts/cross-chain-token/evm/token-pools

[8] ERC-7802 Token With Mint/Burn Access Across Chains, Ethereum Improvement Proposals, 2024, https://eips.ethereum.org/EIPS/eip-7802

[9] Cross-Chain Bridge Hacks Emerge as Top Security Risk, Chainalysis, 2022, https://www.chainalysis.com/blog/cross-chain-bridge-hacks-2022/