A cross-chain token standard is the contract interface that lets one token exist on several blockchains while remaining one asset with one supply. It defines how supply moves between chains and who is allowed to authorize the move.
This page explains what these standards do, the approaches in use today, how they differ on control and verification, and how to choose between them. To issue a token on a cross-chain standard, reach out to our team.
What is a cross-chain token standard?
A cross-chain token standard is a token contract that includes the logic for moving its own supply between chains. A plain token standard describes a balance on one chain, and a cross-chain standard adds an accounting rule that keeps total supply constant plus an authorization rule that decides which incoming instructions the contract will act on.
The second part is what makes it a standard rather than a bridge integration. When the token itself validates instructions, the issuer stays the authority on its own supply: mint and burn rights go to a contract the issuer deploys and controls, rather than to a third party it does not.
Without one, an asset fragments. Each bridge serving a chain mints its own representation, so the alternative is not the absence of a cross-chain presence but an uncontrolled one, where third parties decide how many versions exist and who backs them.
The approaches in use today
Standards differ first by accounting model, and the model determines what the recipient holds.
| Approach | How supply moves | Suits | Constraint |
|---|---|---|---|
| Burn and mint (OFTBurnMint) | Burn on source, mint on destination | New tokens with permissioned mint and burn | The token must expose mint and burn to the standard |
| Self-burn and mint (OFTBurnSelfMint) | Holder-approved burn, then mint on destination | Tokens with permissionless self-burn and permissioned mint | Requires an approval step from the holder |
| Escrow and mint (OFTLockUnlock) | Escrow on source, mint on destination | Existing tokens that cannot mint or burn | One escrow backs the whole mesh |
| Native gas wrapping (OFTNative) | Wraps the chain's own gas asset | Assets like ETH, where no token contract is in play | No token contract in the loop |
Those four are accounting models. An adapter is a separate axis: it keeps the existing token contract in place and puts the cross-chain logic alongside it, using either escrow or delegated mint and burn, so an adapter can implement more than one of the models above.
The escrow row carries the rule that is easiest to get wrong. A mesh should hold a single escrow, because minted supply on every other chain redeems against it, and several independent escrows can leave a redemption pointing at a chain with no inventory to release even though every message involved was valid.
An accounting model on its own does not settle who verifies an incoming instruction. That makes verification a separate question from the interface, and it is the question the next section covers.
How they differ on control and verification
Two questions separate standards more than the accounting model does.
- Who holds mint authority? If an external contract can mint the asset, supply depends on that contract's correctness and its administrators. If the token grants mint and burn only to a variant it controls, authority stays with the issuer.
- Who verifies the incoming instruction, and can the issuer change it? Where verification is configurable per asset, the issuer sets the bar for its own risk instead of inheriting one set for everything.
Under LayerZero's security stack model, verification is configured by the application, per pathway and per direction: required DVNs that must attest to every message, an optional set, and a threshold of that set. The Endpoint that routes messages is immutable and holds no application logic, so the entry point an issuer reviews at launch stays fixed. Message libraries are append-only, and which library and which DVNs apply stay the issuer's choice.
For issuers that need controls layered on top, the token core and the cross-chain variant are separable. An upgradeable token can carry separate mint and burn roles, three-mode access control covering open, allowlist, and blocklist operation, pause and unpause split across different roles, and namespaced storage so upgrades and modules do not collide. The variant is then granted mint and burn rights against that token, which keeps compliance controls and transfer logic in separate layers.
How to choose one
Four questions settle it.
- Does the token already exist? A new token can use burn and mint directly. A live token needs an adapter or an escrow model.
- Can the token mint and burn? If not, escrow is the available path and the single-escrow rule applies.
- Does the asset carry eligibility or blocking requirements? If so, the standard has to sit on a token core that enforces them on every chain.
- Who must be able to verify transfers, and can that be evidenced? For a regulated asset, the answer has to be nameable and reviewable.
Two token behaviours fall outside default support. Fee-on-transfer and rebasing tokens do not work with standard debit and credit accounting, which assumes the amount sent equals the amount received, so supporting them requires an implementation that reconciles against actual balance changes.
FAQ
What is an OFT?
An Omnichain Fungible Token, the cross-chain token standard used with LayerZero messaging. One asset exists across chains under one supply, with a send debiting the source chain and a receive crediting the destination.
How does a cross-chain standard differ from a wrapped token?
A wrapped token is minted by a third party against a locked original, so the holder holds that party's representation. Under a standard, the token on each chain is the issuer's own contract and no representation is created.
How do standards handle chains with different decimal precision?
By converting to a shared precision before sending and reconstructing the local amount on arrival. Any remainder below the shared precision is floored off and refunded rather than lost.
Can an existing token adopt a standard without redeploying?
Yes. An adapter connects the existing contract using either escrow or delegated mint and burn privileges, so the original token address stays in place.
Can a stablecoin use a cross-chain token standard?
Yes, and issuers commonly layer controls on top: allowlist or blocklist enforcement, pause, and rate limits, held by roles the issuer controls.
Issue a token on a cross-chain standard
The choice comes down to whether the token already exists, whether it can mint and burn, what controls it must enforce, and who the issuer needs as verifiers. Those four answers select the variant.
To work through them for a specific asset, reach out to our team, or start at Developers.