OFTs Internal Route LayerZero
Omnichain Fungible Tokens
Omnichain Fungible Tokens (OFTs) allow a token to exist seamlessly across multiple blockchains while maintaining a single, unified identity.Powered by the LayerZero messaging protocol, OFTs eliminate the fragmentation caused by traditional bridging methods like wrapped assets. There are two primary ways how OFT functionality is implemented:
Essentially, an OFT contract extends familiar standards (ERC20) with built-in cross-chain capabilities. These typically work via burn/mint or lock/release mechanisms, all orchestrated through LayerZero Endpoints.
Crucially, the overall OFT standard provides solutions for enabling both new and existing tokens to operate seamlessly across multiple chains.
Native OFT Implementation New Tokens
By ensuring a single, canonical token contract exists on each chain (managed via burn/mint), dApps can integrate the token without worrying about different wrapped versions, leading to a smoother developer and user experience across the omnichain ecosystem.
-
Key characteristics:
- It is typically used for new tokens.
- It’s a minimal extension of a standard token contract (e.g., ERC20 ).
- The
burn/mintfunctions for cross-chain transfers are built directly into the token contract itself.
-
When sent cross-chain via LayerZero :
- The token contract on the source chain burns the tokens.
- The corresponding contract on the destination chain mints an equivalent amount.
- This process ensures a single token identity across networks.
-
Since the
burn/mintlogic is embedded directly:- Deploying or upgrading tokens using this standard requires coordinated updates across all chains where the token exists.
- This ensures consistent behavior and supply management throughout the token’s omnichain presence.
| Description | |
|---|---|
| Use Case | Typically used for new tokens being deployed natively across multiple chains from the start (pre-Token Generation Event - TGE). |
| Supported Routes | StargateV2:taxi StargateV2:bus |
| Key Feature | Native Integration: No adapter contracts needed. Cross-chain capability is inherent to the token itself. |
Adapter-Based OFT Implementations Existing Tokens
While the Native OFT Implementation embeds logic directly into the token, Adapter-Based Implementations utilize separate, external smart contracts to enable cross-chain functionality for associated tokens. This approach is highly flexible and serves several purposes, most commonly bringing existing tokens (ex. established ERC20s with immutable contracts) into the omnichain ecosystem without requiring modifications to their original code.
The most common pattern is the OFT Adapter (Lockbox). It uses an Adapter contract deployed
alongside the original token on its source chain. When the token is sent cross-chain via
LayerZero, it’s locked within this Adapter/Lockbox. LayerZero relays a
message to the destination chain, where a corresponding OFT Representation is minted.
Returning involves burning the OFT Representation and signaling LayerZero to release the
original token from the Lockbox.
However, the Adapter pattern is versatile. Other specialized adapters exist to cater to different needs, such as:
Mint and Burn Adapter:Adapters managing mint/burn logic externally.Gas Adapter:Adapters enabling cross-chain transfers for native gas tokens.Lockbox Mint and Burn Adapter: Adapters combining these mechanisms.
These variations allow a wide range of assets, including those with specific technical constraints or requirements, to gain native cross-chain transfer capabilities via LayerZero and Stargate. This section focuses on the common Lockbox pattern, while subsequent sections may detail specialized adapters.
By utilizing Adapter patterns, established and specialized assets can be seamlessly integrated into Stargate and the broader omnichain ecosystem. This allows users to transfer familiar tokens natively without dealing with fragmented, bridge-specific wrapped versions, enhancing liquidity and user experience.
Short summary
| Feature | Description |
|---|---|
| Use Case | Primarily used for existing tokens (especially immutable ones) to enable cross-chain functionality. |
| Supported Routes | StargateV2:taxi StargateV2:bus |
| Key Feature | External Adapter Contract: Enables cross-chain transfers without modifying the original token contract. |
Lockbox OFT Adapter Existing Tokens
The OFT Adapter (Lockbox) pattern is the most common adapter-based solution, primarily designed to enable cross-chain functionality for existing tokens, especially those with immutable contracts (like many standard ERC20s) that cannot be upgraded to include native cross-chain logic.
This pattern involves deploying a separate OFT Adapter contract on the token’s original (“source”)
chain. This adapter acts as a “Lockbox”:
- To send tokens cross-chain, the user transfers their original tokens into the Lockbox contract.
- The Lockbox contract interacts with the LayerZero Endpoint to send a message to the destination chain.
- On the destination chain, an equivalent amount of a corresponding OFT Representation token is minted to the user.
To bring tokens back to the source chain:
- The user burns the OFT Representation on the destination chain, triggering a LayerZero message back.
- Upon receiving the message, the Lockbox contract on the source chain releases the original tokens back to the user.
This mechanism effectively makes existing tokens behave natively cross-chain without requiring any changes to the original token’s code.
Short summary
| Feature | Description |
|---|---|
| Use Case | Enabling existing/immutable tokens for cross-chain transfers without modifying their original contract. |
| Supported Routes | StargateV2:taxi StargateV2:bus |
| Key Advantage | Lock/Release original token in source chain Adapter; Mint/Burn OFT representation on destination chains. |
OFT Mint and Burn Adapter (MABA) Existing Tokens
The OFT Mint and Burn Adapter (MABA) is another specialized adapter pattern. Unlike the Lockbox
adapter which locks tokens, the MABA interacts directly with a base token’s mint() and burn()
functions to manage cross-chain supply, facilitated by LayerZero messaging.
This pattern involves deploying an external MintAndBurnAdapter contract alongside the main token
contract on each chain. Crucially, the base token contract must:
- Possess externally callable
mint()andburn()functions. - Grant specific authorization (e.g.,
MINTER_ROLE,BURNER_ROLE) to its corresponding MABA contract instance on that chain.
When a cross-chain transfer is initiated, the MABA contract on the source chain calls the base
token’s burn() function. LayerZero relays the message, and the MABA contract on the destination
chain calls the base token’s mint() function.
This approach offers modularity, as the cross-chain logic resides entirely within the adapter, which can potentially be updated or replaced without altering the core token contract. It’s useful for tokens that already have controlled mint/burn capabilities or anticipate future changes in minting authority.
Short summary
| Feature | Description |
|---|---|
| Use Case | Enabling existing/immutable tokens for cross-chain transfers without modifying their original contract. |
| Supported Routes | StargateV2:taxi StargateV2:bus |
| Key Adventage | Tokens needing external/modular control over cross-chain mint/burn; planning for future minter changes. |
OFT Gas Adapter Existing Tokens
The OFT Gas Adapter is a specialized adapter designed to address a unique challenge: making a blockchain’s native gas token (like ETH on Ethereum, AVAX on Avalanche, MATIC on Polygon) behave as an Omnichain Fungible Token (OFT).
These native assets typically do not conform to token standards like ERC20 on their own chains and require a special mechanism for cross-chain transfers via LayerZero.
This pattern uses a dedicated Gas OFT Adapter contract deployed on the source chain. This adapter
handles:
- Wrapping/Locking: When a user wants to send native gas tokens cross-chain, they send them to
the
Gas OFT Adapter. The adapter securely holds or “wraps” these native tokens. - Messaging: The adapter signals the LayerZero Endpoint to send a message to the destination chain.
- Minting Representation: On the destination chain, an equivalent amount of a corresponding OFT Representation token (usually an ERC20 standard token) is minted to the user.
Returning the asset involves burning the OFT Representation on the destination chain and triggering
a LayerZero message back to the source chain’s Gas OFT Adapter, which then unwraps or releases the
original native gas tokens to the user.
This enables fundamental network assets to move seamlessly across chains, participating in the omnichain ecosystem as if they were standard OFTs.
Short summary
| Feature | Description |
|---|---|
| Use Case | Enabling a blockchain’s native gas token (non-ERC20 on source) to be transferred cross-chain as a standardized OFT. |
| Supported Routes | StargateV2:taxi StargateV2:bus |
| Key Adventage | Wrap/Lock native gas token in source chain Adapter; Mint/Burn standardized OFT representation on destination. |
OFT Dual Adapter Complex Liquidity / Use With Caution
The OFT Dual Adapter represents a more complex configuration within the adapter-based OFT framework. Unlike standard adapters that manage transfers between one source and multiple destinations (or vice-versa), the Dual Adapter setup allows for the inflow of liquidity from two different source chains into a single, unified OFT representation on one destination chain.
This pattern typically involves deploying standard OFT Adapter (Lockbox) contracts on two distinct
source chains. Both of these source chain adapters are configured via LayerZero
to mint/burn the same OFT representation on the single target destination chain.
The primary challenge and use case for this setup revolves around intricate liquidity management between the two source chain lockboxes. For example:
- Tokens are locked in the Adapter on Source Chain A and minted on the Destination Chain.
- Tokens are locked in the Adapter on Source Chain B and minted (as the same token) on the Destination Chain.
- If a user attempts to withdraw liquidity back to Source Chain A (by burning on Destination), the system must ensure sufficient corresponding liquidity exists specifically in the Source Chain A lockbox. A large withdrawal could fail if the required original tokens are locked in the Source Chain B adapter instead.
Because of this added complexity and the potential for issues like undercollateralized lockboxes during withdrawals, this pattern is generally advised against unless absolutely necessary for specific, carefully managed liquidity strategies.
Short summary
| Feature | Description |
|---|---|
| Use Case | Enabling existing/immutable tokens for cross-chain transfers without modifying their original contract. |
| Supported Routes | StargateV2:taxi StargateV2:bus |
| Key Adventage | Specific complex liquidity aggregation scenarios; consolidating assets from two sources into one destination. |