> ## 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. # Getting Started with LayerZero V2 on Solana > Get started with Getting Started with on Solana. Step-by-step tutorial for building omnichain applications on LayerZero V2. LayerZero enables secure... 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?"**](/v2/concepts/getting-started/what-is-layerzero) before continuing.
LayerZero provides sister **Solana Programs** that can communicate with the equivalent [Solidity Contract Libraries](/v2/developers/evm/overview) you deploy on the Ethereum Virtual Machine (EVM). These programs, like their solidity counterparts, simplify calling the [LayerZero Endpoint](../../concepts/protocol/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](https://solana.com/developers/evm-to-svm/complete-guide) or [60 Days of Solana by RareSkills](https://www.rareskills.io/solana-tutorial). 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](https://solana.com/docs/core/accounts) 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 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](https://solana.com/docs/terminology#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 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)](https://solana.com/docs/core/pda#breadcrumbs) 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](https://solana.com/docs/core/tokens#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 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 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](https://solana.com/docs/programs/deploying#overview-of-the-upgradeable-bpf-loader), 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 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"](https://neodyme.io/en/blog/solana_upgrade_authority/#intro) 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](https://solana.com/docs/programs/overview) 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**](https://neon-labs.org/) or [**Solang**](https://solang.readthedocs.io/en/latest/) will **NOT** work with the Solana LayerZero Endpoint, because the LayerZero Rust Endpoint does not match 1:1 the Solidity Endpoint interface.