The Omnichain Fungible Token (OFT) Standard is a canonical smart contract specification from LayerZero that allows a single ERC-20-like token to be natively transferred, spent, and accounted for across multiple blockchains. Unlike traditional bridges that lock a native asset on one chain and mint a separate wrapped representation on another, an OFT maintains a unified logical supply. The contract uses a burn-and-mint mechanism: when a user initiates a cross-chain transfer via sendFrom, tokens are debited (burned) on the source chain, a message is delivered through LayerZero's Endpoint, and an equivalent amount is credited (minted) to the recipient on the destination chain. This ensures that the total supply across all chains remains constant and that the token's fungibility is preserved without fragmenting liquidity into multiple wrapped assets.
Omnichain Fungible Token (OFT) Standard
What is the Omnichain Fungible Token (OFT) Standard?
The OFT Standard is a token contract specification built on LayerZero that enables a single, unified supply of fungible tokens to exist across multiple blockchains without wrapping or intermediate assets.
The standard defines a strict interface for the core lifecycle functions: sendFrom, credit, and debit. The debit function is called internally on the source chain to remove tokens from circulation, while credit is invoked by the LayerZero Endpoint on the destination chain to create them. This pattern places a critical security dependency on the correct implementation of these internal accounting functions. The OFT Standard is distinct from the OFT Adapter pattern, which retrofits an existing, non-LayerZero-aware ERC-20 token into the omnichain framework by pairing it with a separate lock-and-mint adapter contract. A native OFT embeds the cross-chain logic directly, offering a simpler trust model, while the adapter introduces an additional contract and upgrade path that asset issuers must secure.
For asset issuers, exchanges, and custody providers, the OFT Standard fundamentally changes token reconciliation and supply auditing. Because the total supply is distributed across multiple chains, verifying the integrity of the global supply requires summing the totalSupply() of all OFT contract instances on every supported chain and confirming they match the expected constant. Any discrepancy in a credit or debit implementation can lead to an inflation or deflation bug with cross-chain consequences. Chainscore Labs can conduct OFT implementation audits that verify the mathematical integrity of the burn-and-mint logic, review the security of the LayerZero security stack configuration, and perform cross-chain supply reconciliation testing to ensure that a token's omnichain accounting is provably correct.
OFT Standard Quick Facts
A reference table for asset issuers, exchanges, and custody providers to understand the core mechanics, trust assumptions, and operational impact of the Omnichain Fungible Token standard.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Supply Model | Token supply is unified across chains via native burn-and-mint, not lock-and-mint. | Asset issuers, custodians, exchanges | Verify total supply reconciliation logic across all deployed chains. |
Core Interface | Standardizes sendFrom, credit, and debit logic for cross-chain transfers. | OApp developers, bridge integrators | Audit custom send and receive logic for compliance with the canonical interface. |
Security Stack | OFT inherits the OApp security model; the token owner configures DVNs and Executors. | Risk teams, protocol architects | Assess the chosen DVN set and threshold for each path to model trust assumptions. |
Adapter vs. Native | Existing ERC-20 tokens use a lock-and-mint OFT Adapter; new tokens can be native OFTs. | Token issuers migrating to omnichain | Evaluate the adapter's upgrade path and proxy risks versus a native OFT deployment. |
Rate Limiting | OFTs can enforce per-path message limits to contain the blast radius of a bridge exploit. | DeFi protocol operators, risk managers | Configure and monitor rate limits aligned with the token's liquidity profile on each chain. |
Versioning | Breaking changes exist between OFT V1 and V2; V2 introduces composability improvements. | Teams maintaining deployed token contracts | Plan a migration path and conduct an upgrade impact assessment for V1 deployments. |
Fee Model | Cross-chain message fees are estimated via the quote function and paid in the source chain's gas token. | UI builders, exchange integration teams | Surface accurate fee estimates to users and account for gas volatility on the source chain. |
Core Mechanism: Burn, Mint, and Unified Supply
How the OFT Standard uses a burn-and-mint model to maintain a single, unified token supply across all connected chains.
The Omnichain Fungible Token (OFT) Standard enforces a unified supply model through a canonical burn-and-mint mechanism. Unlike a lock-and-mint bridge architecture that fragments liquidity into wrapped assets, a native OFT maintains a single logical supply across all chains. When a cross-chain transfer is initiated via the sendFrom function, the specified token amount is permanently destroyed on the source chain. LayerZero's messaging protocol then delivers a packet to the destination chain, where the OFT contract's lzReceive function triggers the minting of an equivalent amount of tokens, ensuring the total supply across all connected chains remains constant.
This mechanism places the OFT contract itself in the role of a decentralized token minter and burner, requiring it to inherit and correctly implement internal _debit and _credit functions. The _debit call atomically burns tokens from the sender's balance on the source chain, while the _credit call mints them to the receiver on the destination chain. This design eliminates the need for a centralized custodian holding a locked supply, but it introduces a critical operational dependency: the security of the total supply is now directly tied to the integrity of the LayerZero messaging protocol and the application's chosen Decentralized Verifier Network (DVN) security stack. A faulty verification could lead to unauthorized minting and an irrecoverable inflation of the total supply.
For asset issuers, exchanges, and custody providers, this model demands rigorous supply reconciliation processes. The total supply is no longer verifiable by querying a single chain's totalSupply() function; it must be computed as the sum of supplies across all deployed OFT instances. This cross-chain accounting complexity is a primary risk vector. Chainscore Labs can conduct OFT implementation audits that specifically verify the correctness of _debit and _credit logic, assess the security stack configuration to prevent unauthorized minting, and build monitoring systems for real-time supply reconciliation across all canonical chain deployments.
Who Is Affected by the OFT Standard?
Impact on Token Issuers
Asset issuers adopting the OFT standard must fundamentally redesign their token's supply model. Instead of fragmented supplies across chains, the OFT enforces a unified supply where tokens are burned on the source chain and minted on the destination, or vice versa for native mint-and-burn OFTs.
Key considerations:
- Supply reconciliation becomes a cross-chain accounting problem. Issuers must verify that
totalSupply()across all chains equals the intended circulating supply at all times. - Upgrade paths from V1 to V2 OFT introduce breaking changes. Teams with deployed V1 tokens need a migration strategy that preserves state and user balances.
- Admin key management is security-critical. The owner can set peers, caps, and DVN configurations, making compromise a total loss scenario.
Chainscore can audit OFT implementations for supply integrity, verify upgrade paths, and review admin key management procedures.
Implementation and Integration Impact
Operational impact areas for teams deploying, integrating, or supporting the Omnichain Fungible Token standard.
Supply Reconciliation and Accounting
The OFT standard uses a unified supply model where tokens are burned on the source chain and minted on the destination. Exchanges, custodians, and data providers must not double-count supply across chains. Implement balance tracking that sums minted supply across all deployed chains and verifies it against the total burned amount. Chainscore can perform independent supply reconciliation audits to verify on-chain integrity.
Security Stack Configuration
Every OFT deployment must call setConfig to choose a Decentralized Verifier Network (DVN) and optional Executor. The security of cross-chain transfers depends entirely on this configuration. A misconfigured or weak DVN set can lead to unauthorized minting. Teams should document their chosen security stack and have it reviewed before mainnet deployment.
Rate Limiting for Exploit Containment
OFT contracts should implement the protocol-level rate limiter to cap the value transferable within a time window on each path. This is a critical circuit-breaker that limits the blast radius of a bridge exploit or DVN compromise. Risk teams must calibrate limits based on token liquidity and volatility. Chainscore can help design and audit rate-limit parameters aligned with your risk tolerance.
Exchange and Custody Integration
Centralized exchanges and custodians listing OFT tokens must handle deposit and withdrawal logic that spans multiple chains. This requires monitoring burn events on each source chain and crediting users on the canonical chain, or supporting multi-chain balances natively. Integration failures can lead to lost deposits or double-spend scenarios. Chainscore can review exchange integration architectures for OFT compatibility.
OFT vs. OFT Adapter Trade-offs
Native OFTs give the issuer full control over the token contract and supply logic but require a new deployment. The OFT Adapter wraps an existing ERC-20 token using a lock-and-mint pattern, preserving the original contract but introducing an additional adapter contract with its own upgrade and security considerations. Teams must evaluate which pattern fits their upgrade governance and legacy integration requirements.
Upgrade Path and Version Migration
The OFT standard has evolved from V1 to V2 with breaking changes. Teams on older versions must plan a migration strategy that may involve token swaps, proxy upgrades, or coordinated multi-chain redeployments. Each approach carries different risks for token holders and integrators. Chainscore can provide an upgrade impact assessment and migration planning support.
Risk and Compatibility Matrix
Evaluates the key technical and operational risks for asset issuers, exchanges, and custody providers integrating or deploying the Omnichain Fungible Token (OFT) Standard.
| Risk Area | Failure Mode | Severity | Affected Actors | Mitigation and Action |
|---|---|---|---|---|
Supply Reconciliation | Mint/burn logic on a remote chain fails or is exploited, causing the total supply across all chains to not equal the initial supply on the home chain. | Critical | Asset issuers, exchanges, custodians, auditors | Implement off-chain supply reconciliation monitoring that sums total supply across all deployed chains. Chainscore can audit the mint/burn logic and build a supply verification dashboard. |
Security Stack Misconfiguration | An OFT is deployed with a weak or single-verifier DVN, allowing a compromised verifier to forge a packet that mints tokens on a remote chain. | Critical | Asset issuers, DeFi protocols, risk teams | Verify the DVN configuration for every path using the canonical |
Adapter Upgrade Risk | An OFT Adapter contract is upgradeable and its admin key is compromised, allowing an attacker to drain the backing token vault. | Critical | Asset issuers, token holders | Evaluate the upgrade governance for the adapter contract. Prefer immutable adapters or time-locked, multi-sig governance. Chainscore can review adapter upgrade paths and admin key management. |
Path Unavailability | A chain path is not configured or is blocked by the rate limiter, preventing users from bridging tokens back to the home chain during a market event. | High | Arbitrageurs, liquidity providers, users | Verify that all expected paths are initialized and active. Set rate limits high enough for expected flow but low enough to contain an exploit. Chainscore can review path configuration and rate-limit parameters. |
Executor Liveness Failure | The chosen Executor for a path goes offline, halting message delivery and preventing token | High | Users, DeFi protocols relying on cross-chain OFT actions | Ensure a permissionless executor option is available as a fallback for critical paths. Chainscore can assess the execution liveness guarantees of your OFT deployment. |
Standard Version Incompatibility | A wallet or exchange integrates with OFT V1 logic, but the token has migrated to OFT V2, causing transaction failures or incorrect balance displays. | Medium | Wallets, exchanges, block explorers | Confirm the OFT version of the target token contract. Review the V1-to-V2 migration guide for breaking interface changes. Chainscore can provide an integration readiness review for the specific OFT version. |
Options Misconfiguration | Insufficient gas is passed in execution options for the destination chain, causing the | Medium | OApp developers, UI builders | Use the OptionsBuilder library to estimate and enforce adequate gas limits for destination chain execution. Chainscore can audit options encoding logic in your UI and smart contracts. |
OFT Deployment and Verification Checklist
A structured checklist for asset issuers and protocol engineers to verify the correctness, security, and operational readiness of an Omnichain Fungible Token (OFT) deployment. This process ensures the unified supply model is intact, cross-chain send and receive logic functions as expected, and the security stack is correctly configured before mainnet funds are at risk.
What to check: Verify that the deployed contract inherits from the canonical OFT or OFTAdapter Solidity source and matches a specific, audited version tag from the official LayerZero repository.
Why it matters: Using an unofficial, modified, or outdated OFT implementation can introduce supply bugs, broken composability, or incompatibility with standard OFT tooling and explorers. The distinction between a native OFT and an OFT Adapter (lock-and-mint) has fundamentally different security invariants.
Confirmation signal:
- The deployed bytecode on each chain matches the build artifact from the canonical release tag.
- The contract correctly identifies itself via a public
oftVersion()or equivalent function. - A diff between the deployed source and the canonical source shows no unexpected modifications.
Canonical Resources
Use these resources to verify the current Omnichain Fungible Token standard, inherited contract behavior, deployment tooling, endpoint configuration, and cross-chain message status before shipping or listing an OFT.
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos

Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
Frequently Asked Questions
Common questions from asset issuers, custody providers, and integration teams evaluating or deploying the Omnichain Fungible Token standard.
A native OFT is a token contract deployed with the OFT standard from genesis, where the contract itself mints and burns tokens across chains, maintaining a unified supply. There is no locked liquidity on a canonical chain.
An OFT Adapter wraps an existing ERC-20 token. It uses a lock-and-mint model on the token's home chain and a burn-and-unlock model on remote chains. The original token supply remains locked in the adapter contract on the home chain, introducing a custody risk that does not exist for native OFTs.
Why it matters: Custody providers and exchanges must treat the adapter contract as a critical component. A vulnerability in the adapter or an upgrade that changes its behavior can directly impact the backing of all wrapped representations.
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.


