Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.layerzero.network/llms.txt

Use this file to discover all available pages before exploring further.

Any data, whether it’s a fungible token transfer, an NFT, or some other smart contract input can be encoded onchain as a bytes array, and delivered to a destination chain to trigger some action using LayerZero. Because of this, any blockchain that broadly supports state propagation and events can be connected to LayerZero, like Solana.
If you’re new to LayerZero, we recommend reviewing “What is LayerZero?” before continuing.

LayerZero provides sister Solana Programs that can communicate with the equivalent Solidity Contract Libraries you deploy on the Ethereum Virtual Machine (EVM). These programs, like their solidity counterparts, simplify calling the LayerZero Endpoint, provide message handling, interfaces for protocol configurations, and other utilities for interoperability:
  • Omnichain Fungible Token (OFT): an extension of OApp built for handling and supporting omnichain SPL Token transfers.
  • Omnichain Application (OApp): the base program utilities for omnichain messaging and configuration.
Each of these programs standards implement common functions for sending and receiving omnichain messages.

​
Differences from the Ethereum Virtual Machine

The full differences between Solidity and Solana are outside the scope of this overview (e.g., see A Complete Guide to Solana Development for Ethereum Developers or 60 Days of Solana by RareSkills.
Skip this section if you already feel comfortable working within the Solana Virtual Machine (SVM) and the Solana Account Model.

​
Writing Smart Contracts on Solana

To create a new ERC20 tokens on an EVM-compatible blockchain, a developer will have to inherit and redeploy the ERC20 smart contract. Solana is different. Direct translation of Solidity contract inheritance to Solana is not possible because Rust does not have classes like Solidity. Instead, the Solana Account Model enables program reusability. Diagram comparing EVM ERC20 token deployment versus Solana SPL token creation, showing that Solana uses a single Token Program to create multiple Mint Accounts rather than deploying separate contracts Rather than deploying a new ERC20 smart contract for every new token you want to issue, you will instead send an instruction to the Solana Token Program and create a new account, known as the Mint Account, which defines a set of values based off the program’s interface (e.g., the number of tokens in circulation, decimal points, who can mint more tokens, and who can freeze tokens). Diagram showing how the Solana Token Program creates Mint Accounts that define token properties like supply, decimals, mint authority, and freeze authority An account on Solana either is an executable program (i.e. a smart contract) or holds state data (e.g. how many tokens you have).
Sometimes you’ll see Solana tokens referred to as “SPL tokens.” SPL stands for Solana Program Library, which is a set of Solana programs that the Solana team has deployed onchain. SPL tokens are similar to ERC20 tokens, since every SPL token has a standard set of functionality.

A Program Derived Address (PDA) can then be used as the address (unique identifier) for an onchain account, providing a method to easily store, map, and fetch program state. For example, a user’s wallet and the SPL Token Mint can be used to derive the Token Account. Diagram illustrating Program Derived Addresses (PDAs) on Solana, showing how a user wallet and SPL Token Mint can be combined to derive a Token Account address To be compatible with the Solana Account Model, the Omnichain Fungible Token (OFT) Program extends the existing SPL token standard to interact with the LayerZero Endpoint smart contract. Architecture diagram showing how the OFT Program extends the SPL Token standard to interact with the LayerZero Endpoint for crosschain token transfers The typical path for Solana program development involves interacting with or deploying executable code that defines your specific implementation, and then having other developers mint accounts that want to use that interface (e.g., the SPL Token Program defines how tokens behave, and the Mint Accounts define the different brands of SPL tokens). The OFT Program is different in this respect. Because every Solana Program has an Upgrade Authority, and this authority can change or modify the implementation of all child accounts, developers wishing to create crosschain tokens on Solana will need to deploy their own instance of the OFT Program that will have their own OFT Store Account. Diagram showing the relationship between a deployed OFT Program and its OFT Store Account, illustrating that developers deploy their own OFT Program instance to maintain control over the Upgrade Authority This decision was made so that tokens minted off of the OFT Program will own their OFT’s Upgrade Authority, rather than depend on LayerZero Labs to maintain a single, mutable OFT Program for all OFT Stores. See “Why Auditing the Code is Not Enough: A Discussion on Solana Upgrade Authorities” for more information on how Upgrade Authorities behave on Solana.
LayerZero Labs may eventually in the future maintain with another entity a version of the OFT Program which users can use to create OFT Store Accounts from, but for now developers should consider deploying their own version of the OFT Program.

​
Writing Solana Programs

Solana Programs are most commonly developed with Rust. LayerZero OApp Programs should also be written in Rust to take advantage of LayerZero Solana libraries. See an Overview of Developing Onchain Programs to learn more about Solana.
While some initiatives exist to enable developers to write Solana programs in Solidity, compiling LayerZero Solidity Libraries using compilers like Neon EVM or Solang will NOT work with the Solana LayerZero Endpoint, because the LayerZero Rust Endpoint does not match 1:1 the Solidity Endpoint interface.