LayerZero OFT (Omnichain Fungible Token) is a standard for moving token value across chains while preserving one intended global supply. A transfer debits tokens on the source chain and credits the recipient on the destination. Direct OFTs and adapters implement that accounting through different contract and custody arrangements.
The details decide how much trust that promise requires. A direct OFT and an adapter-based deployment can achieve related outcomes through different custody and minting arrangements. Neither automatically gives every network the same market liquidity.
The source debit comes first
For a direct burn-and-mint OFT, a cross-chain transfer burns the transferable amount at the source. A verified message then allows the trusted destination contract to mint the corresponding amount for the recipient.
During delivery, part of the value is in transit. Counting only live wallet balances at that moment can make the supply look lower than the intended total. After successful credit, the spendable amount has moved to the destination. OFT technical reference.
In a hypothetical transfer, chain A begins with 700 tokens and chain B with 300. Burning 100 on A leaves 600 there and 100 in transit. When B credits the transfer, its balance becomes 400 and the in-flight amount returns to zero. The intended total remains 1,000 throughout, counting value in transit.
The real contracts have to preserve that accounting under retries, failures and administrator actions. A pretty diagram assumes correct implementation. A security review has to test those assumptions.
Debit here, credit there
OFT accounting aims to move economic supply across chains without creating an independent extra allocation.
Adapters keep an existing token
An issuer may already have a token contract it doesn't want to replace. An OFT adapter can connect that token to the messaging flow. In a common arrangement, the original tokens are locked in the adapter while the destination credits a representation. Returning through the route burns that representation and releases the locked balance.
The escrow introduces a custody point in the token system. You need to know which contract holds the original asset, who can affect it and how remote supply relates to that reserve. Counting the locked originals and remote representations as separate economic supply would double-count the same value. OFT patterns and extensions.
An adapter can also hold mint and burn permissions instead of using escrow. “Uses OFT” tells you the family of transfer pattern. It doesn't identify the custody model, so an adapter deserves its own description in an asset comparison.
Look for the exact deployment architecture. An issuer's official contract list and the configured counterpart contracts help establish which token you're holding. A name or ticker can be copied by an unrelated contract.
A peer defines who can credit value
Token deployments need to recognize their trusted counterparts. If a destination accepts messages from an unintended remote sender, valid protocol messaging can still reach the wrong application authority.
The issuer also sets route-level verification and execution settings. Those choices can differ between directions or chains. A well-reviewed deployment on one network doesn't establish the safety of every later route. OApp technical reference.
For an asset you intend to hold, inspect who controls those settings. A multisig, delay and monitoring process can limit some operational risks, but they need to exist in the actual deployment. Architecture diagrams aren't evidence of key custody.
The DVN and Executor guide explains the verification choices. The LayerZero introduction provides the broader message flow if you're encountering peers and endpoints for the first time.
Decimal precision is part of the transfer
Blockchains can represent token amounts with different decimal precision. A cross-chain token needs a shared unit of account so that one deployment doesn't misread the amount sent by another.
The OFT design normalizes transferable amounts through shared decimals. Amounts smaller than that shared precision can remain with the sender as rounding residue, often called dust. OFT decimal accounting.
For example, with six shared decimals and a source token supporting greater precision, a request for 1.123456789 tokens becomes a transferable amount of 1.123456. The remaining 0.000000789 stays with the sender. This is illustrative arithmetic, not a fee charged by the bridge.
This is a good example of a small technical detail with a direct financial consequence. The system needs to preserve economic value while translating between representations. The destination shouldn't receive a larger balance because the contract interpreted the unit incorrectly.
Shared supply leaves separate markets
Suppose the same asset exists on two networks. The accounting can remain consistent while one network has deep markets and the other has little trading activity. The transfer mechanism doesn't create bids, market makers or collateral demand by itself.
A price gap can persist when arbitrage is expensive, slow or restricted. Cross-chain fees, transfer delays and investor permissions affect the cost of closing that gap. A route being technically available doesn't guarantee that a trader can use it at the required size.
An issuer can also use limits to reduce the impact of abnormal transfer activity. Those limits may improve risk control while making an immediate large arbitrage trade impossible. The financial and operational design need to be evaluated together.
This distinction is especially useful for RWA products. Fund size, global token supply and liquidity in a particular pool answer different questions. The Treasury comparison keeps them separate when considering an exit.
Issuer controls travel with the asset
An OFT deployment can include custom transfer controls. For a tokenized financial product, the issuer may need to preserve eligibility, sanctions-related restrictions or other holder rules across supported chains.
That requires policy at the application level. A message can be valid while the intended recipient fails an issuer's eligibility check. The system must define what happens then, including the recovery path and who can intervene.
Ondo's institutional bridge description provides a concrete case of an issuer specifying multiple required verification providers. Its structure illustrates how an asset-specific bridge can make choices beyond the basic token standard. Ondo institutional bridging.
Read the current configuration before relying on the historical example. A published launch design describes that launch, and production settings can change. Ondo vs Centrifuge places distribution tools in the wider business comparison.
A transfer followed by another action
OFT can carry additional instructions for a destination application. Receiving a token and using it in another contract introduces another stage, with its own possibility of failure. Omnichain composers.
Consider an RWA token arriving at a lending application. The token transfer could finish while the deposit fails because the market no longer accepts that asset. The recipient needs a clear status and a route to recover or use the received balance.
The interface should expose that distinction. Treating the whole experience as one success or failure hides useful information and can lead users to repeat an action that already completed in part.
Rebasing and transfer fees need different accounting
A yield token can change its holder balance through rebasing. A fee-on-transfer token delivers less than the sender transfers. LayerZero's standard OFT accounting does not support those behaviors without changes: its debit and credit logic assumes lossless transfers. The implementation must reconcile actual balance changes.
For a yield-bearing asset, identify the wrapper and accounting used before treating an OFT integration as compatible. OFT technical reference.
Before you trust a new deployment
Check the official contracts, the peer relationship and the custody pattern. Then inspect the verification configuration, transfer limits and administrator powers. Finally, test the route you expect to use for redemption or further application activity.
OFT supplies a common pattern for moving token value between networks. The deployment decides how that pattern serves a particular asset. For another approach to cross-chain token infrastructure, continue with LayerZero vs Chainlink CCIP.