‍

Neon’s composability libraries act as a **Babel fish for blockchains -** a universal translator imported in a Solidity contract’s “ear”, allowing EVM projects to interact directly with Solana programs without rewriting code in Rust or using bridges.

These libraries work alongside precompiled contracts to abstract away Solana’s complex architecture and let developers:

- Format and send native Solana instructions from Solidity
- Create and manage Solana accounts and token mints
- Call DeFi protocols like Raydium from within the EVM

Currently, five libraries are available: System Program, SPL Token Program, Associated Token Program, Metaplex, Raydium CPMM Program.

These are just the beginning - everyone is welcome to build and extend their own libraries! For example, if your project needs an Orca integration instead of Raydium, you can follow the same patterns we used or reach out for support.

Each library includes helper functions, getters, and custom errors tailored to Solana’s architecture.

Use cases integrating these libraries include:

• Aave flash loan + Orca swap: Borrow on Neon EVM, swap on Orca, repay in one atomic tx
• Memecoin Launchpad: Create SPL tokens and liquidity pools on Raydium, fully controlled from Solidity

‍

We often hear that blockchains exist in silos. Their fragmentation keeps ecosystems apart, preventing dApps on one chain from easily accessing users and liquidity on another.

Even though crypto has transcended geopolitical borders, blockchains still resemble countries, or nations - each with its own frameworks and programming languages. Much like natural human languages between different countries, these differences create friction in communication.

Breaking down language barriers has always been high on humanity’s to-do list. When prehistoric tribes started trading, saying “Hi, I’m not here to kill you but to exchange these pretty seashells for your mammoth’s tooth” was the basis of creating a common trading ground with a larger userbase bringing their ‘liquidity’ to the table - instead of getting a spear in the face.

While natural languages have gradually evolved to support translation, international trade, and diplomacy, blockchain languages - from Solidity to Rust - remain largely isolated. They reflect the execution environments and logical assumptions of their home chains, making cross-chain communication about more than just syntax: it’s about logic, tooling, and trust.

Fiction, however, has long dreamt of a technological breakthrough that could remove language barriers ones and for all. In The Hitchhiker’s Guide to the Galaxy, the answer is the Babel fish - a tiny creature you insert into your ear, instantly granting you universal translation. With it, the messiness of language is gone, and trade, cooperation, and interstellar hitchhiking become possible.

What if blockchains could take a lesson from fiction, and instead of relying on brittle bridges or duplicating codebases, or waiting for millennia for Solidity & Rust to evolve, we could create a translation system where contracts on one chain can speak natively to programs on another?

That’s exactly the idea behind Neon’s composability libraries: not a patchwork workaround, but a native way for Solidity contracts to interact with Solana programs without the need to rewrite code, wrap assets, or trust external bridges. It’s a Babel Fish for blockchain logic - a translator that knows the grammar of both chains.

‍

Neon’s composability libraries are a key part of how Solidity contracts can interact with Solana. They work together with precompiled contracts to let EVM-based apps read from and write to Solana - all from within standard Solidity code.

The composability mechanism relies on two components:

• Libraries, which prepare Solana-specific logic, format the instructions, fetch data from Solana, throw back custom errors, help with Solana-specific calculations, etc.
• Precompiled contracts, which execute the instructions within Solana runtime

The libraries abstract away the complexity of Solana’s specific requirements and make it accessible through Solidity. They include:

• Helper functions to format instructions to be executed by Solana programs
• Getter functions to get data from Solana accounts
• Custom errors to handle reverting execution on Solana
• Predefined Solana constants: program IDs, accounts public keys, etc.
• Solana accounts rent management
• Swaps, slippage calculations, and more operations

You simply import these libraries into your Solidity contracts. Neon also provides an NPM package for easy integration into your development workflow (see a short instruction below in “How to use the libraries” section).

How does this work? You can say that interaction with Solana happens with the help of the libraries through the precompiles.

• You start with a caller contract, written in Solidity.
• And you simply import composability libraries like SPL Token Program library or System program library to generate the Solana-specific instructions covering all possible considerations, such as which accounts to create for your operations, and what Solana expects to get in an instruction.
• Then the libraries wrap the logic to call a precompiled contract which encodes Solana instructions and executes them natively and directly on Solana.

At the moment of writing, Neon has five composability libraries that allow to interact with native and custom Solana programs:

• System program
• SPL Token program
• Associated Token program
• Metaplex program
• Raydium program

This list doesn’t cover all possible Solana integrations but the good news is that you can use them as templates to build your own libraries. If you’re working with a different protocol (like Orca, Mango, or anything else on Solana), our existing libraries can serve as a blueprint.

Each library consists of three parts: a set of helper functions, getter functions, and custom errors.

• Helper functions build and format the instructions in a way that Solana expects to receive them. You can say that they are the brain of this Babel fish that translates Solidity code into Solana-specific logic.For example, a helper function that formats the transfer instruction will get the senderATA (the sender's associated token account to be debited), recipientATA (the recipient's associated token account to be credited), and the amount of tokens to be transferred.It will then build the required accounts for these parameters, specify which accounts are signers, which are writable, and do the necessary calculations to convert littleEndians to bigEndians, expected by Solana.

function formatTransferInstruction(
        bytes32 senderATA,
        bytes32 recipientATA,
        uint64 amount
    ) internal view returns (
        bytes32[] memory accounts,
        bool[] memory isSigner,
        bool[] memory isWritable,
        bytes memory data
    ) {
        accounts = new bytes32[](3);
        accounts[0] = senderATA;
        accounts[1] = recipientATA;
        accounts[2] = LibSPLTokenData.getSPLTokenAccountOwner(senderATA);

        isSigner = new bool[](3);
        isSigner[2] = true;

        isWritable = new bool[](3);
        isWritable[0] = true;
        isWritable[1] = true;

        // Get amount in right-padded little-endian format
        bytes32 amountLE = bytes32(SolanaDataConverterLib.readLittleEndianUnsigned256(uint256(amount)));
        data = abi.encodePacked(
            bytes1(0x03), // Instruction variant (see: https://github.com/solana-program/token/blob/08aa3ccecb30692bca18d6f927804337de82d5ff/program/src/instruction.rs#L506)
            bytes8(amountLE) // Amount (right-padded little-endian)
        );
    }

‍

• Getter functions allow to fetch the necessary data from Solana. For example, to find out the 32 bytes public key of the token's mint authority:

function getSPLTokenMintAuthority(bytes32 tokenMint) internal view returns(bytes32) {
	(bool success, bytes memory data) = QueryAccount.data(
		uint256(tokenMint),
		4,
		32
		);
	require(success, LibSPLTokenErrors.TokenMintDataQuery());
  return data.toBytes32(0);
}

‍

• Custom errors translate what might have gone wrong in the process for us to be able to debug (e.g. when the mint authority was set or passed incorrectly, we get error InvalidMintAuthority(bytes32 tokenMint, bytes32 mintAuthority, bytes32 invalidAuthority); )

Let’s zoom in on each library and see how it helps your Solidity contract become fluent in Solana-speak.

‍

As all Neon libraries, the System Program Library consists of three main components: helper functions, getters, and custom errors.

LibSystemProgram library provides helper functions for formatting instructions to be executed by Solana's System program - a native Solana program responsible for creating and managing accounts.Since Solana’s System Program handles tasks like account creation, ownership assignment, and space allocation, the library includes helper functions that allow to prepare each of those instructions, and more:

• createAccountWithSeed: creates a new Solana PDA (program-derived account) which public key is derived from a base public key, a program id and a seed. A payer account pays for the rent exemption balance of the created PDA based on the size of the storage allocated to the account.
• transfer: transfers an amount of SOL to another Solana account.
• assignWithSeed: assigns a Solana PDA (program-derived account) to a Solana program.
• allocateWithSeed: allocates storage space to a Solana PDA (program-derived account).

The following data fields are stored by System accounts and can be queried using the LibSystemData part of the library:

bytes32 pubkey
uint64 lamports
bytes32 owner
bool executable
uint64 rent_epoch

‍

This library also provides a set of custom errors that may be thrown when using LibSystemProgram and LibSystemData in your contracts. You can get, for example, System account data query errors and errors related to float64 to uint64 conversion.

‍

This library provides helper functions for formatting instructions to be executed by Solana's SPL Token program. Roughly speaking, it handles everything token-related and is fully compatible with SPL token standard requirements.

In LibSPLTokenProgram, you’ll find helpers for most of the token operations you can think of - initializing mints accounts, minting, transferring, or burning tokens, etc:

• initializeMint2: initializes a Solana account as a SPL token mint. Such an account holds data related to a SPL token (see LibSPLTokenData.SPLTokenMintData).
• initializeAccount2: initializes a Solana account as a SPL token account. Such an account holds data related to a SPL token holder (see LibSPLTokenData.SPLTokenAccountData).
• mintTo: mints an amount of tokens to an initialized SPL token account.
• transfer: transfers an amount of tokens to an initialized SPL token account.
• setAuthority: updates a SPL token mint's MINT or FREEZE authority or a a SPL token account's OWNER or CLOSE authority.
• approve: delegates an amount of tokens belonging to a SPL token account to a third party Solana account.
• revoke: revokes token delegation previously granted to a third party Solana account.
• burn: burns an amount of tokens from a SPL token account.
• closeAccount: closes a previously initialized SPL token account.
• syncNative: syncs the token balance of a Wrapped SOL token account to reflect its SOL balance (minus rent exemption balance).

If we want to get data from Solana accounts using getters from this library, we should keep in mind that some of the data fileds are stored by SPL token mint accounts, and some - by SPL token accounts.

‍

bytes4 mintAuthorityOption
bytes32 mintAuthority
uint64 supply
uint8 decimals
bool isInitialized
bytes4 freezeAuthorityOption
bytes32 freezeAuthority

    

bytes32 mint
bytes32 owner
uint64 balance
bytes4 delegateOption
bytes32 delegate
bool isInitialized
bytes4 isNativeOption
bool isNative
uint64 delegatedAmount
bytes4 closeAuthorityOption
bytes32 closeAuthority

    

‍

A set of custom errors that may be thrown when using this library includes SPL Token mint/account data query errors, token mint & token account authority errors, and delegated token claim errors.

‍

This library provides helper functions for formatting instructions to be executed by Solana's Associated Token program, which have to do with creating an Associated Token Account (ATA_).

While the System Program and SPL Token Program libraries cover many account-related operations, a separate library is required for creating canonical ATAs. This is because ATA creation follows a specific convention on Solana - derived deterministically from the token mint and the owner's public key and handled by the Associated Token Program.

Neon’s composability libraries faithfully reflect Solana’s architecture, which is why ATA creation is implemented in its own dedicated Associated Token Program library with the following helpers:

• create: creates and initializes a canonical Associated Token account on Solana. Such an account holds data related to an SPL token holder.
• createIdempotent: creates and initializes a canonical Associated Token account on Solana. Such an account holds data related to an SPL token holder. Using the createIdempotent instruction allows to create the ATA only if it doesn't already exist, and avoids throwing an error if the ATA already exists. An error will be thrown, however, if the ATA already exists but its owner account is different from the one specified in the instruction.

Accordingly, getters allow to fetch data about the ATA, such as the 32 bytes token account public key derived from the token mint account public key, the user public key, and the programId.

‍

This library provides helper functions for formatting instructions to be executed by Solana's Metaplex program. It lets you create and manage token metadata using the Metaplex standard:

• createMetadataAccountV3: creates a new token metadata account associated with an already initialized token mint account and store provided token metadata on it. A token metadata account can be mutable, meaning that it is possible for the specified updateAuthority account to update the metadata held by the account in the future.
• updateMetadataAccountV2: updates an existing mutable token metadata account, storing new token metadata on it.

The following data fields are stored by token metadata accounts and can be queried using the LibMetaplexData:

string tokenName;
string tokenSymbol;
string uri;
bool isMutable;
bytes32 updateAuthority;

‍

Custom errors can let you know that a metaplex account already exists, or there’s been a validation error, etc.

‍

This library connects your Solidity contracts to Raydium DEX, so that you can create liquidity pools, add/remove liquidity, lock positions, collect fees, and perform swaps using Raydium’s concentrated liquidity pools.

The helper functions cover the main instructions needed to interact with liquidity pools on Raydium:

• createPoolInstruction - Deploying CPMM pool on Raydium for selected tokens pair. This method also returns the needed lamports amount for the instruction to be processed successfully in Solana, this amount contains several account creations plus the pool creation fee paid to Raydium.
• addLiquidityInstruction - Adding liquidity for selected tokens pair.
• withdrawLiquidityInstruction - Withdrawing liquidity from selected tokens pair.
• lockLiquidityInstruction - Locking liquidity position. This method also returns the needed lamports amount for the instruction to be processed successfully in Solana, this amount contains several account creations plus a fee if withMetadata is set to true.
• collectFeesInstruction - Collecting fees for locked LP position. This instruction can be sent to Solana only if there is already existing locked LP position and there are some pending fees to be collected.
• swapInputInstruction - Swapping exact token input amount, example - swap 100 tokensA for X tokensB.
• swapOutputInstruction - Swapping tokens to exact token output amount, example - swap X tokensA for 100 tokensB.

Getter functions in this library allow not only to query different accounts & data, but also do some calculations such as swap input or output amount, convert LP amount to tokens amounts, and more:

• getPoolData - Returns the data of Raydium CPMM pool.
• getConfigData - Returns the data for requested utils index.
• getTokenReserve - Returns pool token reserve for selected token mint.
• getPoolLpAmount - Returns the pool's LP amount.
• lpToAmount - Converts LP amount to reserves amounts.
• getSwapOutput - Returns a swap quote of provided exact input amount.
• getSwapInput - Returns a swap quote of provided exact output amount.

Custom errors here let us know if we had the wrong pool ID, if the token address is empty, is there’s insufficient input or output amount for a swap, etc.

‍

With these libraries, you can build powerful composable use cases, for example:

Borrow tokens from an EVM protocol, automatically create all the required Solana accounts behind the scenes, perform a swap using a Solana program, and repay the borrowed tokens, all in one atomic transaction using Neon’s composability libraries (more about the use cases below).

But as we mentioned earlier, to make use of the libraries, you’ll need caller contracts. Let’s take a look at what those contracts might look like in practice.

‍

Within Neon’s composability libraries GitHub repo, you’ll find a set of example caller contracts implementing typical use cases and best practices for these libraries.

Roughly speaking, all these contracts follow the same pattern:

• Authentication: we derive the required ATA from the msg.sender
• We format the instructions
• We prepare, or build the instruction
• And we send it to CALL_SOLANA precompile for execution

Sometimes, you might find that seemingly similar operations are performed differently in these example contracts - this is intentional, as each approach reflects how Solana's architecture handles those operations under the hood.

One such area is token account management.

Unlike the EVM, where token balances are stored in mappings within the token contracts, Solana uses a more complex account-based model where each token holding requires a dedicated account. There are multiple ways to create and manage these accounts depending on your use case.

To understand how token accounts are created and managed using these libraries, we can look at two caller contracts: CallSPLTokenProgram and CallAssociatedTokenProgram.

1. When it comes to creating token accounts, the CallSPLTokenProgram contract has methods to create and initialize SPL token mints and arbitrary token accounts as well as to mint and transfer tokens using those accounts. It has a built-in authentication logic ensuring that users remain in control of created accounts.

Arbitrary token accounts are derived using a seed which includes the token account owner's public key and an arbitrary nonce (among other parameters). By using different nonce values it is possible to derive different arbitrary token accounts for the same owner which can be useful for some use cases.

2. However, there exists a canonical way of deriving a SPL token account for a specific owner , and this token account is called an Associated Token account. Associated Token accounts are used widely by applications running on Solana and it is generally expected that token transfers are made to and from Associated Token accounts.

The CallAssociatedTokenProgram contract provides a method to create and initialize canonical Associated Token accounts for third party Solana users. This method can also be used to create and initialize canonical Associated Token accounts owned by this contract.

‍

Instalation

npm install @neonevm/call-solana

https://www.npmjs.com/package/@neonevm/call-solana

‍

Usage

Once you have installed the package, you can use the Solidity libraries by importing them in your contracts:

‍

pragma solidity 0.8.28;

‍

import { LibSPLTokenData } from "@neonevm/call-solana/composability/libraries/spl-token-program/LibSPLTokenData.sol";

‍

contract CallSPLTokenProgram {  

/// @param tokenAccount The 32 bytes SPL token account public key  

/// @return token account balance as uint64  

 function getSPLTokenAccountBalance(bytes32 tokenAccount) external view returns(uint64) {    return LibSPLTokenData.getSPLTokenAccountBalance(tokenAccount);

 }

}

‍

For more details, see documentation.

‍

The following use cases are real interstellar hitchhikers, seamlessly traveling between Ethereum and Solana using Neon’s composability libraries as their Babel fish.

‍

In this project, a Solidity contract on Neon EVM requests a flash loan from an Aave V3 fork and uses it directly on Solana’s Orca DEX:

1. The contract borrows USDC using a flash loan.
2. It swaps USDC for SAMO on Solana via the Orca program.
3. Then swaps back to USDC in a second Orca transaction.
4. Finally, it repays the flash loan and fees - all within one atomic transaction.

This only works because Neon’s composability libraries act as a translator: the contract uses ATA helpers and SPL token utilities to manage Solana token accounts exactly as Solana expects while staying entirely in Solidity.

‍

The Memecoin Launchpad is another project that uses multiple Neon composability libraries to launch tokens and bootstrap liquidity directly on Solana.

It uses:

• SPL Token Program Library to mint the underlying SPL token and transfer it on Solana
• Associated Token Program Library to create token accounts (ATAs) for WSOL and the new token
• Raydium Program Library to create a liquidity pool and lock LP tokens using native Solana instructions

Thanks to these libraries, the entire token launch, sale, and liquidity setup happens natively on Solana but is controlled entirely from Neon EVM using familiar Solidity syntax.

‍

Most cross-chain solutions today rely on:

• Wrapped assets (like Wormhole’s wrapped ETH on Solana)
• Off-chain relayers (that listen to events on one chain and submit txs to another)
• Generalized messaging protocols (e.g., LayerZero, Axelar, etc.)

These systems often come with:

• High latency (cross-chain transactions can take 5–15 minutes)
• Security tradeoffs (relayer compromise, bridge hacks)
• Limited programmability (you can send a message, but not directly execute native program logic)

By contrast, Neon composability libraries offer:

• Atomicity: Solana instructions and EVM logic run in a single transaction
• Security: No external bridges
• Interoperability: Full access to Solana native and custom programs like Raydium, SPL Token, Metaplex right from Solidity

And the best part? Anyone can contribute to this new paradigm. The libraries we’ve published are designed to be forked, remixed, or built from scratch for your own Solana integrations.

Composability libraries unlock a new paradigm: runtime-level interoperability, not just asset bridging or message passing.

With Neon:

• Developers write once in Solidity and use EVM tooling
• Users interact via MetaMask
• Solana’s DeFi ecosystem becomes accessible as if it were native to Ethereum

The Babel fish didn't just translate - it let you understand and participate. That’s what Neon’s composability libraries are doing for the cross-chain future.

___________________________

‍

Learn more:

Composability Docs

Composability Libraries GitHub repo

Install npm package

Want to build your own composability library? Start from our examples or just reach out.

Need help integrating the libraries into your project? We’re happy to assist on Discord.

‍