Layer zero OFT standard supports direct OFTs and adapter-based integration
Layer zero OFT standard supports a direct mint-and-burn design for a new token while an OFTAdapter connects an existing token without rewriting it. The deciding condition is control over issuance. A direct OFT owns its debit and credit logic; a standard adapter escrows the original asset on its home chain and pairs with OFTs elsewhere. Both patterns use the same cross-chain message interface, decimal normalization and pathway configuration, yet they place custody and authority in different contracts.
Bottom line: Choose a direct OFT for a new controllable supply and an adapter when an existing token contract must remain unchanged.
Token control decides the architecture
Token control determines whether bridge logic can live inside the asset contract or must sit beside it.
A newly designed token can inherit the OFT implementation and make minting, burning and cross-chain messaging part of one contract. That route avoids a separate escrow contract. It also makes the OFT deployment the token address on each network. The issuer must still define supply policy, secure mint authority and configure every directional pathway before transfers begin.
An established token may already have a fixed address, live integrations or immutable code. A standard OFTAdapter leaves that contract untouched and adds the OFT interface in a separate deployment. The adapter points to the underlying token, while remote direct OFTs represent the same global asset. This split preserves the original token contract but adds an escrow balance and another administrative surface.
A token that exposes controlled mint and burn functions creates a third choice. A MintBurnOFTAdapter keeps the messaging layer separate without using a lockbox. Its suitability therefore depends on existing token permissions, not simply on whether the token is already deployed.
Direct OFTs combine asset and bridge logic
Direct OFT contracts expose token behavior and OFTCore messaging through one deployment on each supported network. During a send, the source contract removes the normalized amount from circulation through its debit logic. The paired destination contract credits the recipient by minting the corresponding amount. No separate underlying token or escrow inventory sits between those actions. This compact structure reduces contract count, although token administration and pathway administration remain security-sensitive responsibilities.
Standard adapters preserve an existing token
A standard OFTAdapter is a separate OFTCore contract that references an existing token. Its token() method returns the underlying token address rather than the adapter address. The adapter can therefore provide cross-chain send and receive behavior while the original contract remains unaware of cross-chain messages. Existing local transfers continue through the original token contract.
On an outbound transfer from the original token's network, the sender first authorizes the adapter to spend the amount. The adapter pulls the normalized amount with transferFrom and holds it in escrow. A paired direct OFT on the destination then mints the equivalent amount after the message is accepted and executed. The escrowed units are no longer in the sender's circulating balance, so the destination credit does not duplicate spendable supply.
The return direction reverses the economic actions. A remote direct OFT burns the amount being sent home, then the adapter releases that amount of the underlying token to the recipient. The adapter needs sufficient locked inventory for that release. This is why the location and uniqueness of the lockbox matter to the mesh rather than only to one pathway.
One lockbox for the global mesh
A standard OFTAdapter design calls for only one lockbox in a global token mesh.
Separate standard adapters would hold separate pools of the same underlying asset while OFT messages treat the deployments as one connected supply. A return message could seek release from a lockbox that did not receive the original backing. Insufficient inventory would then prevent the intended credit, even though tokens were locked elsewhere. One canonical lockbox keeps the backing pool and the path back to the original token aligned.
Multiple direct OFT deployments do not create the same inventory split because they burn on debit and mint on credit. Those contracts can connect to the single adapter and to one another through configured peers. Confirm that each endpoint ID maps to the intended peer in both directions; the lockbox rule does not correct a bad peer map.
Mint-and-burn adapters split logic without escrow
A MintBurnOFTAdapter remains an adapter because Layer zero logic lives outside the token contract. It calls a separately authorized minter and burner instead of transferring units into escrow. The underlying token must expose compatible mint and burn operations, and the adapter must hold only the permissions needed to invoke them. Multiple mint-and-burn adapters can participate because no independent lockbox has to fund a return transfer. The tradeoff moves from escrow custody to privileged supply control.
How do both patterns preserve one global supply?
Both patterns preserve one global supply by making the source debit precede the destination credit for the same OFT message.
With direct OFTs, the source burn lowers supply on one network before the destination mint restores it elsewhere. With a standard adapter, locking removes the underlying units from circulation while a destination OFT mints their cross-chain representation. A return transfer burns that representation before the adapter unlocks the original units. Mint-and-burn adapters use the direct economic action, but keep it behind a separate messaging contract.
The supply invariant describes authorized balances, not instant completion. A source transaction may finish before destination verification and execution. During that interval, the debited units are unavailable on the source and not yet credited to the recipient. This delay does not create extra supply, although it does leave the transfer incomplete until the destination action succeeds.
Custom fees, rate limits or access rules can change the amount or eligibility of a send. Those extensions must run within the debit and credit model without allowing a destination credit that lacks a corresponding source debit. Direct and adapter contracts share that requirement even though they implement the debit differently.
Shared precision before debit
Decimal normalization runs before burning or locking, so the architectural choice does not alter the conversion rule. Each deployment knows its local token decimals and uses a common shared-decimal precision for messages. The source converts the local amount into shared units, while the destination converts those shared units into its own local representation. This lets networks with different local precision describe the same economic quantity.
When local precision exceeds shared precision, the conversion rate is 10^(localDecimals - sharedDecimals). The implementation floors the requested amount to a multiple of that rate before the debit. The excluded remainder, commonly called dust, stays with the sender rather than entering the cross-chain message. The minAmountLD field rejects the send when the calculated amount to be received falls below the caller's minimum.
Every deployment must use compatible shared precision, and local decimals cannot be lower than that value in the standard EVM implementation. The shared amount is encoded in a 64-bit unsigned integer, so supply scale and precision must fit that range. Deployments on environments with smaller local integer types also need to ensure that reconstruction into local units cannot overflow.
Which evidence distinguishes the two patterns?
Source-side balance evidence distinguishes them: a direct path reduces token supply, while a standard adapter path increases escrow. In this hypothetical comparison, every amount and decimal setting is illustrative. The source uses nine local decimals, the destination uses six and the shared precision is six. No custom token fee applies, and the token is lossless and non-rebasing. A sender requests 12.345678905 units with a minimum receipt of 12.345678 units.
The decimal boundary has a conversion rate of 1,000 source units per shared unit. Normalization floors the request to 12.345678 units. The remaining 0.000000905 unit never enters the message and stays in the sender's balance. The message amount becomes 12,345,678 shared units.
Under the hypothetical direct path, the source burns 12.345678 units and the destination mints 12.345678 units. Expected evidence consists of the source debit, one OFT message identity and a destination credit for the same normalized amount. Observing all three states confirms that the input crossed the decimal boundary and reached its intended token balance.
Under the hypothetical lockbox path, the adapter transfers 12.345678 underlying units from the sender into escrow. The paired destination OFT then mints 12.345678 units. The expected source state is an escrow increase rather than a supply burn, while the expected destination state remains the same credit.
The transfer trace is complete when the destination credit matches the normalized amount. If escrow rises or a direct burn occurs without that credit, another source send would create another debit. The missing handoff should be located in the existing message path before any new transfer is submitted.
Approval, custody and authority boundaries
The IOFT interface exposes approvalRequired() so an integration can discover whether it must request an underlying token allowance. A standard lockbox adapter returns true because it pulls tokens with transferFrom. A direct OFT does not need approval for a separate underlying asset because the OFT is the token. MintBurnOFTAdapter also reports that no underlying approval is required because it uses mint and burn authority.
Custody risk concentrates in the standard adapter's escrow balance. Reviews should cover the immutable underlying token reference, debit and credit accounting and any extension that could move locked inventory. Direct OFTs replace that escrow concern with native mint authority. Mint-and-burn adapters add a privileged boundary between the messaging contract and the token's minter or burner.
Pathway administration applies to every pattern. Owners and delegates can control peers, message libraries, verifier configuration and execution options through their respective permissions. A secure token contract does not compensate for a peer that points to the wrong remote deployment. Conversely, sound pathway settings cannot repair an adapter that can mint, burn or release tokens without proper authorization.
Lossless accounting and token behavior
The default lockbox adapter assumes that transferring an amount into or out of escrow changes balances by that exact amount. Fee-on-transfer and rebasing tokens violate this lossless assumption, so the base implementation does not support them safely. A custom adapter must override debit and credit logic to measure actual balance changes and carry the reconciled amount through the OFT receipt. Merely changing the displayed quote does not repair inconsistent on-chain accounting.
Custom OFTs may also deduct token-denominated fees, enforce rate limits or apply access controls. Those features are extensions rather than inherent differences between direct and adapter patterns. The implementation should report the actual amount sent and expected amount received through quoteOFT(), then enforce minAmountLD during the debit. The separate quoteSend() call prices Layer zero messaging and destination execution for the selected path.
Rebasing deserves separate treatment because balances can change without a transfer. Even a pre-transfer balance check may be insufficient if the accounting model allows supply or holder balances to move independently. Supporting such a token requires an explicit design for how cross-chain backing and credits respond to those changes, not a generic adapter deployment.
Deployment and maintenance consequences
Both patterns require an OFT-capable contract on every network in the mesh. Each deployment must be bound to its local endpoint, assigned the correct remote peers and configured with compatible message libraries, verifier rules and execution options. These settings are directional. A working outbound route does not prove that the reverse route has the intended peer or security configuration.
Direct deployment testing should cover mint and burn authorization, decimal conversion, total supply behavior and OFT messaging as one contract system. Standard adapter testing adds the underlying token address, allowance flow, escrow solvency and both lock-to-mint and burn-to-unlock directions. Mint-and-burn adapter testing should prove that only the intended adapter path can invoke the token's privileged functions.
The common IOFT surface keeps integration behavior similar across the choices. Interfaces can query the associated token, detect approval requirements, obtain token and messaging quotes and submit the same send structure. That consistency does not erase the architectural distinction underneath the call. Balance evidence, custody exposure and the authority capable of creating supply still differ.
A new controllable token usually fits the direct pattern because its token and messaging logic can be designed together. An existing token with a fixed contract and no mint authority fits the single-lockbox adapter. An existing token with tightly controlled mint and burn hooks can use a mint-and-burn adapter to avoid escrow. Choosing from those actual permissions determines which risks the deployment must manage.
Answers to common questions
Which token address does IOFT token() return for a standard adapter?
It returns the underlying ERC-20 token address, not the adapter contract address. Wallets and integrations can use that response to identify the asset that needs approval and enters escrow. For a direct OFT, token() identifies the OFT contract itself because token and messaging logic share one deployment. This distinction prevents an interface from asking users to approve or display the wrong contract.
How should an interface use quoteOFT() and quoteSend() together?
Use quoteOFT() to show token-side limits, fee details and expected sent and received amounts, then use quoteSend() to price Layer zero messaging for the same SendParam. The first reveals normalization or custom token deductions; the second returns the messaging fee. Both calls should use the same destination, amount and options so the values describe one send. Refresh quoteSend() close to submission because gas estimates and service fees can change.
Does minAmountLD cap the Layer zero messaging fee?
No. minAmountLD is the minimum token amount that debit logic allows the destination to receive after normalization and any custom OFT deductions. The messaging fee is separate and comes from quoteSend(). If the calculated token receipt falls below minAmountLD, the debit reverts with a slippage error. Raising or lowering that field does not set a ceiling on destination gas or verifier charges.
Which compatibility checks matter when pairing direct and adapter contracts?
Check the IOFT interface and message encoding version, shared-decimal setting, local decimal constraints and peer mapping for both directions. The labels direct and adapter do not establish compatibility by themselves. Each pathway also needs its intended message libraries, verifier configuration and execution options. Confirm token() and approvalRequired() locally for integrations. A correct token address cannot compensate for an incompatible encoding version or a peer that targets the wrong deployment.
May remote direct OFTs send between themselves when the mesh has a lockbox?
Yes, paired direct OFTs on remote networks can send between themselves when their pathway settings permit it. The source remote OFT burns and the destination remote OFT mints, so the standard lockbox does not move for that route. A later transfer back to the original-token network burns remote units and unlocks escrow. Every route still needs compatible decimals and correct peers.
Does a composed destination call favor either OFT pattern?
No. Direct OFT and adapter deployments share OFTCore messaging, so either pattern can carry a compose message when the implementation enables it. The pattern decides token debit, credit and custody; composition queues a separate destination action after the core credit. That action needs its own execution resources. If it fails, the completed token credit is not automatically reversed, so the two outcomes need separate tracking. This distinction is identical for both patterns.
Where can an integration read the actual OFT debit and credit amounts?
Read OFTSent on the source and OFTReceived on the destination. OFTSent records the message GUID, destination endpoint, sender, amount sent and expected amount received. OFTReceived records the same GUID, source endpoint, recipient and credited amount. For a lockbox adapter, compare those events with underlying token transfers into or out of escrow. Direct OFT token transfers instead show the corresponding burn and mint.
· updated