Unveiling Composability Whitepaper: A Unified Framework for Ethereum–Solana Interaction

TL;DR

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.

Why composability matters

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:

• Account models: Ethereum uses contract storage, whereas Solana employs explicit account-based data storage.
• Token standards: Ethereum’s open and extensible token architecture (i.e. one can choose between ERC-20, ERC-777, etc.) versus Solana’s unified SPL tokens (in Solana, there’s one central factory provided by the Solana Foundation called the SPL Token Program, through which almost all Solana tokens are minted).
• Atomicity and execution management: Differences in how transactions and states are handled and reverted.

Neon EVM composability overcomes these architectural gaps, enabling developers to:

• Build dApps that seamlessly connect to both Ethereum and Solana functionalities.
• Directly invoke Solana-native programs using familiar Solidity workflows.
• Avoid complex bridging solutions or external synchronization mechanisms.

What exactly is composability

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 overview

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:

1. Precompiled contract interface

Neon EVM has created a custom precompiled contract called ICallSolana at address 0xFF00000000000000000000000000000000000006. This precompile handles critical operational responsibilities, including:

• Solana instruction encoding and execution via CPI: Solidity contracts send formatted Solana instructions to the composability precompile (0xFF00…06), which validates the input. Neon EVM securely executes these instructions via Cross-Program Invocations (CPI) to the specified Solana program ID, acting on behalf of the original Ethereum msg.sender.
• Dynamic account discovery and management: Precompile extensions automatically identify and resolve Solana accounts required for specific instructions, including program-derived addresses (PDAs), associated token accounts (ATAs), and explicitly defined accounts specified within Solidity calls.
• SOL provisioning via payer accounts: Precompile extensions internally handle SOL provisioning via dedicated payer accounts deterministically associated with the original Ethereum caller (msg.sender).
• Secure signer authorization: Precompile extensions manage these signer requirements through associated payer accounts, ensuring instructions are correctly authorized without private-key exposure.
• Atomicity and error management: Transactions invoking Solana instructions either execute fully or revert entirely upon encountering any execution error.
• Off-chain transaction emulation support: Precompile contracts integrate with the off-chain Neon proxy layer, supporting pre-transaction emulation and validation processes.

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.

2. ERC20ForSPL

The ERC20forSPL standard allows Solidity contracts to:

• Check balances of SPL tokens
• Transfer tokens
• Set allowances

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.

3. Account handling

Solana's accounts are very different from Ethereum’s storage model. Neon EVM handles this with:

• PDAs (Program Derived Addresses) for secure, deterministic storage.
• ATAs (Associated Token Accounts) for token balances.
• Payer Accounts that automatically cover SOL costs (rent exemption, signer requirements).

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.

4. Atomic execution

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.

Composability execution flow

Let’s break down a transaction execution flow with a composability request

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.

1. Neon EVM Users interact with a dApp

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.

2. Composability request construction via precompile

Under the hood, the dApp sends a transaction to a Solidity smart contract deployed on Neon EVM.

To prepapre the transaction, the Neon proxy:

• dynamically identifies required Solana accounts (including PDAs and associated token accounts),
• determines necessary instruction data (i.e. Program ID, list of read & write accounts, the instruction data),
• and encodes transaction details based on the Ethereum transaction submitted by users or smart contracts.

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.

3. Execution on Solana through ICallSolana precompile

• Neon EVM securely executes the encoded Solana instructions as an atomic transaction.
• Under the hood of the composability request:
  • 100 USDC is deducted from a PDA-controlled SPL token account linked to Johnny’s EVM address.
  • The equivalent amount of SOL is returned to a native Solana account, which is also a PDA (program-derived address) linked to Johnny’s EVM address.
  • These PDAs are securely derived from Johnny’s Ethereum address and require no private key - they are fully controlled by the Neon EVM program.

4. Transaction Resolution

• Once the Solana instructions finish executing, the transaction resolution is returned to the Neon EVM smart contract, which finalizes its own execution.

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.

Conclusion

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.