The new Neon EVM whitepaper explores composability, a Neon EVM feature enabling seamless interaction between Ethereum-compatible dApps and Solana without code rewrites.
Composability was designed to overcome key challenges in Ethereum-Solana interaction, caused by fundamental architectural differences, such as how each chain handles storage, accounts, token standards, and transaction execution.
The whitepaper gives a detailed account of composability’s technical design, the motivation behind its development, and its potential to address key challendges in Ethereum-Solana interaction. It brings together several core components of Neon EVM that enable Ethereum dApps to interact with Solana seamlessly.
At its core, composability:
Lets Solidity contracts send direct calls to Solana.
Maintains transaction atomicity: if one step fails, everything rolls back.
Handles account models, token standards, and SOL provisioning under the hood.
Allows Solidity contracts to construct and send Solana-formatted instructions, which are executed natively by Solana programs.
The whitepaper describes the architecture of these components and explains how composability creates a unified framework for interaction between Ethereum-compatible smart contracts and Solana programs - either native (SystemProgram, SPL Token Program, etc.), i.e. built by Solana Foundation, or other Solana programs built by independent developers.
In this article, we’re going to break down the key concepts defined in the whitepaper and use an example to clearly illustrate how the composability execution flow works in practice.
Ethereum and Solana are two powerhouses in the blockchain with complementary strengths: Ethereum provides robust developer tooling and a vast developer community, whereas Solana offers rapid transaction speeds and high efficiency through parallel processing of transactions.
However, these ecosystems have historically been isolated due to fundamental architectural differences:
Neon EVM composability overcomes these architectural gaps, enabling developers to:
Composability is the technical capability enabling EVM-compatible smart contracts deployed on Neon EVM to directly invoke and manage interactions with native programs on Solana.
From a practical perspective, composability means that your smart contract can interact with any existing program on Solana. It acts like a gateway to the entire Solana ecosystem - whether it's a native program like SystemProgram, SPL Token, staking program, etc., or a custom program built by other developers, such as decentralized exchanges (DEXes), lending protocols, or vaults.
For example, one of the simplest use cases would be performing a token swap through a DEX on Solana or depositing tokens into a vault - all directly from your smart contract, without needing custom integrations for each use case.
Composability encapsulates several crucial Neon EVM’s principles and components created specifically to resolve the discrepancies in Ethereum and Solana architectures and allow Ethereum dApps to seamlessly interact with Solana. These are:
Neon EVM has created a custom precompiled contract called ICallSolana
at address 0xFF00000000000000000000000000000000000006
. This precompile handles critical operational responsibilities, including:
msg.sender
.msg.sender
).The ICallSolana
precompile gives developers a typical Solidity interface to send instructions to Solana in a way that Solana expects them. It abstracts away the differences between the chains by internally managing interactions via dedicated payer accounts that Neon EVM creates to use on Solana.
The ERC20forSPL standard allows Solidity contracts to:
ERC20ForSPL exposes an ERC-20-compatible Solidity interface, allowing Ethereum-based smart contracts and user interfaces to interact with SPL tokens using familiar function signatures such as transfer(address,uint256)
, transferFrom(address,address,uint256)
, and balanceOf(address)
.
Underlying Solana account operations remain entirely abstracted from the Solidity developer’s perspective.
Solana's accounts are very different from Ethereum’s storage model. Neon EVM handles this with:
Token balances, transfers, approvals, and other token operations performed through ERC20ForSPL translate directly into modifications of Solana-associated token accounts (ATAs) and program-derived addresses (PDAs).
This structured management ensures secure, predictable handling of assets and account states across platforms.
Every cross-chain interaction via composability is atomic. If any part fails, the entire transaction rolls back.
It’s possible to have a revert in Solidity even after composability requests. The difference is that in Solidity, you can anticipate that a request to an external contract might fail and handle this failure by choosing to skip the request entirely or proceed and handle the failure response.
When it comes to instructions sent to Solana through the composability feature, there is no such option. For example, you cannot handle a swap slippage protection overflow and then decide to perform some action based on that instruction’s failure. If this happens, the entire Neon EVM transaction is reverted.
This ensures consistent state across Ethereum and Solana execution contexts. Developers receive transaction receipts indicating final outcomes, aligned with standard Ethereum transaction receipt formats.
This diagram shows what happens when an end user interacts with a dApp that has Neon EVM’s composability and can call any Solana program through this feature.
Let’s call the end user Johnny and say that he wants to swap USDC to SOL in his Ethereum-looking dApp that he’s used to.
Johnny opens a dApp, connects his wallet and selects:
Swap: 100 USDC → SOL
Network: Neon EVM
Swap via: Solana DEX (e.g. Orca)
He clicks “Swap” and chills.
Under the hood, the dApp sends a transaction to a Solidity smart contract deployed on Neon EVM.
To prepapre the transaction, the Neon proxy:
The proxy assembles this information into a properly formatted Solana transaction.
Solidity-defined operations are translated into Solana-compatible instructions through a precompiled contract interface called ICallSolana
.
ICallSolana
precompile Johnny swapped his USDC for SOL.
He never had to deal with Solana keys, rent, or tokens manually. The dApp handled everything via Neon EVM composability.
Our use case hero’s - Johnny’s - seamless experience swapping USDC for SOL showcases precisely why Neon EVM composability matters. Without dealing with Solana-specific accounts, keys, or complex integrations, Johnny accessed Solana’s powerful features directly from an Ethereum-based dApp.
The whitepaper dives deep into the intricate technical framework that underlines composability. It explains how composability resolves Ethereum-Solana interaction challenges by addressing fundamental architectural differences between them, such as how each chain handles storage, accounts, token standards, and transaction execution. By detailing mechanisms like specialized precompiled contracts, deterministic payer accounts for SOL provisioning and instruction signing, and robust validation and security protocols, the whitepaper provides developers with practical insights into expanding their EVM dApps to Solana through Neon EVM composability.
If you’re an Ethereum developer who’s wanted to tap into Solana’s speed, this is your on-ramp.
If you’re building cross-chain dApps, composability simplifies everything.
The latest industry news, interviews, technologies, and resources.