LayerZero Omnichain Token (OFT): How One Token Spans Chains

A LayerZero omnichain token, or OFT, is a token whose supply is coordinated across several blockchains by a messaging layer, so holders can move it between chains without creating separate wrapped copies. It trades simplicity of use for reliance on that messaging system.

The problem OFTs address

Tokens traditionally live on one chain. To use one elsewhere, people used bridges that lock tokens on chain A and issue a wrapped IOU on chain B. Each IOU is a separate asset with its own liquidity, and different bridges produce different IOUs of the same token. That fragments markets and creates confusion about which version is real.

An omnichain design aims for a single token identity. A transfer burns tokens on the source chain and mints the same amount on the destination, with the total across chains staying constant. LayerZero’s documentation describes the V2 protocol and its OFT standard in detail; check it for current mechanics, because configuration options are extensive.

How a transfer works, in outline

1. You call send on the token contract on chain A, naming the destination chain and recipient.
2. The contract debits (burns or locks) your tokens.
3. A message is passed through the messaging layer, verified by configured verifiers.
4. The contract on chain B credits (mints or releases) the same amount.

Where tokens originate matters. In some setups a home chain locks and releases, while other chains burn and mint. Either way, the invariant is that the total circulating amount across chains should match the supply.

How BC1 is described

According to the bitcoin.one whitepaper, BC1 is a LayerZero OFT with 18 decimals and ERC-20 Permit on EVM chains. The full supply of 21,000,000,000 is minted once on Ethereum, which is the home chain. The token is also on BOB, Base and Solana. The presale contracts are on Ethereum, Base and BNB Chain, with a Solana program, and claims happen on Ethereum, Base or Solana.

Chain	Stated role
Ethereum	Home chain, full supply minted, claims
BOB	App chain, vault, staking, liquidity
Base	OFT and presale contract
BNB Chain	Presale contract
Solana	OFT and presale program

Key takeaway: One omnichain token means one supply, but several places where something can go wrong. Check how many chains hold risk, not just how many you can use.

What ERC-20 Permit means

ERC-20 Permit, defined in EIP-2612, lets a holder approve spending with a signed message rather than a separate transaction. It improves convenience, since approval and use can happen in one step. It also means a malicious site can ask you to sign a permit, so read what you sign.

Risks specific to omnichain tokens

• Messaging layer faults. If verification fails or is misconfigured, forged messages could mint tokens. The risk page lists the LayerZero bridge among the technology risks.
• Configuration errors. Peers, limits and verifiers must be set correctly on every chain.
• Upgrade and admin keys. Check who can change settings.
• Fragmented liquidity. Even with one token identity, trading depth varies by chain.
• Oracles. The risk page also names Chainlink and Pyth oracles as dependencies.
• Operational complexity. Each added chain adds more to monitor and more to get wrong.

How this relates to wrapped assets

Wrapped bitcoin, covered in wrapped bitcoin (WBTC), is a claim on bitcoin held elsewhere. An OFT is not a claim on anything held elsewhere; it is a native multi-chain asset. Different trust issues apply, and confusing the two leads to wrong risk assessments.

What to verify yourself

1. Find the token contract address on each chain from the project’s official page, and confirm each on a block explorer.
2. Check the supply on the home chain and the cross-chain peers.
3. Read the audit report once one exists. The project says an external audit is planned, not complete.
4. Look at who holds admin permissions.
5. Test a small transfer before moving anything meaningful.

For how the app side uses these chains, see BOB, a Bitcoin layer 2, and for how the supply is divided, BC1 token supply and allocation. This article is educational, and technology details change, so confirm against the current protocol documentation.

Why a spending app might choose an omnichain token

A consumer app has users on many chains and wants a single token those users can recognise. Issuing separate tokens per chain would split liquidity and confuse holders, and relying on third-party wrapped versions would make the token’s identity depend on bridges the project does not control. An omnichain design lets the project define one supply and let holders pick the chain with the cheapest fees. That is the stated rationale for BC1 having Ethereum, BOB, Base and Solana as launch chains.

The cost is dependency. The token’s safety then rests on the messaging layer and its configuration, in addition to the token contract itself. You can see that the project acknowledges this: the risk page names the LayerZero bridge and the oracles it uses as possible points of failure, and notes the contracts have not been externally audited. For a primary description of the token and its chains, read the bitcoin.one homepage alongside the whitepaper.

Practical tips for moving an omnichain token

Send a small test amount between chains before moving a large one. Confirm the destination chain and address carefully, since a transfer to an address you do not control on the other chain is as irreversible as any other. Expect a transfer to take longer than a same-chain send, and expect a fee paid in the source chain’s native currency. Keep a little of each chain’s native token for fees, or you may end up with tokens you cannot move. And be wary of “bridge” links from strangers: only use interfaces linked from the project’s official domain.

Reading a token page for omnichain red flags

Look for a clear list of contract addresses per chain, a statement of which chain is the home chain and a description of who can change the configuration. Be cautious when a page lists chains but no addresses, when different pages disagree about supply, or when a token claims to be omnichain but only one chain’s contract can be inspected. A confident description of the technology is not evidence of its safe configuration; the contracts themselves are.