Logistics manager tracking shipments on tablet, QR codes and shipping containers visible, warehouse background, operational work moment.
Protocols

Omnichain Fungible Token (OFT) Standard

Canonical specification for the OFT contract, covering sendFrom, credit, and debit logic, unified supply model, and the distinction from the OFT Adapter pattern. Affects asset issuers, exchanges listing omnichain tokens, and custody providers.
introduction
UNIFIED CROSS-CHAIN TOKEN SUPPLY

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 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.

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.

PROTOCOL SPECIFICATION AT A GLANCE

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.

AreaWhat changesWho is affectedAction

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.

technical-context
SUPPLY RECONCILIATION MODEL

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.

ACTOR-BY-ACTOR IMPACT ANALYSIS

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-impact
OFT DEPLOYMENT CHECKLIST

Implementation and Integration Impact

Operational impact areas for teams deploying, integrating, or supporting the Omnichain Fungible Token standard.

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

OFT DEPLOYMENT AND OPERATIONAL RISKS

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 AreaFailure ModeSeverityAffected ActorsMitigation 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 getConfig interface. Do not accept the default without review. Chainscore can provide a due-diligence report on the chosen security stack.

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 sendFrom operations from completing on the destination chain.

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 lzReceive call to fail and the token transfer to be stuck in an inflight state.

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.

PRE-DEPLOYMENT AND POST-DEPLOYMENT VERIFICATION

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.
Chains We Build On

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 logo
    Ethereum
  • Arbitrum logo
    Arbitrum
  • Optimism logo
    Optimism
  • Polygon logo
    Polygon
  • Avalanche logo
    Avalanche
  • Cronos logo
    Cronos

Non-EVM ecosystems

  • Solana logo
    Solana
  • Sui logo
    Sui
  • Aptos logo
    Aptos
  • Hedera logo
    Hedera
  • Stellar logo
    Stellar
  • NEAR logo
    NEAR

Additional ecosystems

  • Polkadot logo
    Polkadot
  • Cosmos logo
    Cosmos
  • TON logo
    TON
  • Cardano logo
    Cardano
  • Algorand logo
    Algorand
  • Tempo logo
    Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

OFT STANDARD FAQ

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.

Trusted by Industry Leaders

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

ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
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.
L
Lee Erswell
CEO, Telos Foundation
how to get started

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.

01

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

02

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

03

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

04

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Start a build

Need a blockchain engineering team?

Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.