LayerZero v2 OFTs

Omnichain Fungible Tokens (OFTs) are individually configurable asset-specific Token Bridges. This means that an asset is usually locked or burned at its origin to start the bridging. Then a witness event of this is emitted, verified and relayed to the destination by third parties. Finally, an Executor submits a transaction at the destination chain to mint the bridged asset.

The shared feature among all OFTs is the messaging interface, which always uses the LayerZero message protocol (or arbitrary message bridge, AMB). Apart from the OFT token standard provided by LayerZero, which extends the ERC-20 standard, implementation details are highly customizable and vary widely.

Each OFT contract is a LayerZero OApp and can be configured to use custom security settings when interacting with the AMB. Among these OApp configuration parameters are the DVN(s) (verifiers who will read and verify the interchain messages), the executor (who will execute the transaction on the destination chain and pay for gas), and the minimum block confirmations needed. These can be set by the Oapp / OFT owner or a delegate that they can define in the EndpointV2 contract. Additionally, the OFT owner can often use other admin functions on the OFT contract that are specific to the ERC-20 implementation (similar to other ERC-20 tokens, like arbitrary minting or pausing functions) and not related to LayerZero.

In the case of the Executor failing to deliver the bridge message, the user can try to deliver the message to the destination themselves, either if it was already verified and committed onchain or if the user has access to the signed verifier message (e.g. through the layerzeroscan API).

OFTs can either be natively multichain or they can use an adapter. Native OFTs are burned at their origin and minted at their destination when bridging. Adapter OFTs have a main chain, where they are locked in an adapter escrow. This mints a ‘native’ OFT version of the locked token that can then be bridged on all chains by burn-minting. To receive the original locked token back, a user would have to return to the main chain and unlock it from the adapter escrow.

Each crosschain transaction is emitted on the origin chain and must be picked up and verified by preconfigured verifiers (aka DVNs). If they agree on a message, it is considered verified and can be executed at the destination.