When medieval architects discovered the flying buttress (which has a deceivingly unelegant name), everything changed. Cathedrals could rise taller and lighter, not by tearing down their walls, but by redistributing structural load. The secret wasn’t reinvention, but rather support - a new external structure that let the existing one reach further than it could alone.

Neon does something similar for Web3.

Ethereum and Solana were engineered with different priorities. Ethereum brought the first mature smart-contract ecosystem and an unprecedented developer toolkit, while Solana delivered a new execution model built for speed, parallelism, and low-cost computation.

Separately, they resemble the heavy stone walls and tensioned arches of a Gothic cathedral. Together, through Neon EVM, they become an interlocking structure where each reinforces the other’s contraints.

The result is an architecture that is not merely interoperable - it is structurally synergistic. Neon EVM acts like the flying buttress, reinforcing both chains and enabling architectural expansion without rebuilding the core structure.

‍

Why combine Ethereum and Solana?

We’ve examined this question in earlier pieces, yet the facts remain compelling enough to restate.

Ethereum gave the world the EVM - the most widely adopted smart-contract standard on Earth. Today, the Ethereum ecosystem supports:

• 4,000+ active dApps across DeFi, NFTs, gaming, and infrastructure (DappRadar)
• Over 1,000,000 monthly active developers across Ethereum L1, L2s, and sidechains (Electric Capital Developer Report)

Solana - light, fast, and engineered for parallelism:

• ~400 ms block times (https://docs.solanalabs.com/)
• 3,000-5,000 real-world TPS sustained, with peaks exceeding 20,000 TPS ****during high-load events (Solana Foundation Performance Report)
• Parallel execution, allowing independent state writes to execute concurrently - a foundational reason for Solana’s throughput advantage.

Developers want it all, and they want it now: Ethereum’s dev environment + Solana’s performance. Users, meanwhile, want lower fees, faster execution, and no need to switch mental models or wallets.

So, the question is no longer “Which chain is better?” but rather:

Can Ethereum-native applications gain Solana-level performance without rewriting their contracts or abandoning their tooling?

And the answer is - yes, with Neon.

‍

High-level architecture of synergy

At a distance, Neon looks like a simple promise: Ethereum contracts, Solana performance.

Up close, it’s a carefully layered system with one core idea: EVM execution runs on Solana, and composability turns that execution into native interaction with the Solana ecosystem.

‍

Neon consists of two essential layers working together:

• Neon Proxy - the gateway that accepts Ethereum-style transactions and makes Neon feel like a standard EVM network (JSON-RPC, EVM tooling, gas estimation, off-chain emulation).
• Neon EVM Program - the on-chain engine running on Solana that executes EVM bytecode and can invoke Solana programs.

As we discussed earlier in another article, you can let your users connect with both Ethereum and Solana wallets, but your contracts are still deployed on Neon EVM program that runs on Solana and executes EVM bytecode within Solana runtime.

On top of that execution layer sits what makes the cross-runtime synergy real:

• Composability - Neon’s mechanism that lets Solidity contracts construct and execute Solana-formatted instructions (atomically) as part of a Neon EVM transaction. Consists of composability libraries and precompiled contracts working together.
• Precompiled contracts (especially ICallSolana) - the contract interface Solidity uses to send Solana instructions.
• ERC-20-for-SPL - an interface contract that provides access to native Solana tokens through the ERC-20 standard interface.

‍

EVM transaction with execution on Solana in detail

First, let’s have a look at a standard Neon EVM transaction which is triggered from an EVM dApp and is sent to Solana via Neon.

‍

Executing such a tx on Solana via Neon follows a three-stage process:

1. The user initiates a tx, which is a signed Ethereum-like tx directed to a Neon RPC endpoint.
2. This request is received by the Neon Proxy.2.1 The Neon Proxy processes the request, providing:
   • Gas usage estimate for tx execution
   • Broadcast initiation - wrapping the Ethereum-like tx as a Solana tx, including:
     • The Ethereum transaction payload (nonce, gas parameters, calldata, signature, etc.) is encoded into the data field of a Solana instruction
     • The Solana transaction’s accounts list contains:
       • The Neon EVM program address
       • Neon state accounts
       • Any Solana accounts that will be read or written during execution
     • The program index of the instruction points to the Neon EVM program inside the accounts list

‍

1. At this point, the Ethereum transaction has become a Solana-native transaction carrying EVM execution logic.2.2. The Neon Proxy passes the wrapped tx to the Neon EVM program hosted on Solana. This results in the following:
   • A Solana receipt
   • A corresponding Neon EVM receipt
   2.3 The Neon EVM program then:
   • Unwraps the tx and checks the user's signature
   • Loads the EVM state, including account data and the smart contract's code, from Solana storage
   • Executes the tx inside Solana BPF
   • Updates Solana's state to reflect the new Neon EVM state
2. Solana and Neon EVM undertake a state change.

This completes the tx request.

‍

Composability with Solana

However, execution alone wouldn’t create a true Ethereum-Solana interaction. It’s Neon’s composability mechanism that allows EVM smart contracts to seamlessly call Solana programs through Neon EVM without bridges or code rewrites in Rust.

1) Composability

Neon’s composability is the mechanism that enables Solidity contracts deployed on Neon to directly invoke Solana programs - native programs like the System Program and SPL Token Program, as well as any custom Solana program built by independent teams.

Practically, composability means:

• A Solidity contract can construct Solana instructions (program ID, account metas, instruction data),
• Send them via a Neon-provided interface,
• And have them executed natively on Solana as part of the same Neon EVM transaction.

Two properties matter here the most, because they’re what change “interop” into “architecture”:

1. Atomicity
2. If any Solana instruction fails, the entire Neon EVM transaction fails. There’s no partial success and no “handle the failure and continue” pattern for Solana instructions - execution is all-or-nothing.
3. Abstraction of Solana mechanics
4. Solana’s account model (PDAs, ATAs, rent, signer requirements) is real and strict, but composability is designed so Solidity developers don’t have to manually manage it.

Neon has built several composability libraries to translate EVM logic into Solana-specific instructions. They prepare Solana-specific logic, format the instructions, fetch data from Solana, throw back custom errors, help with Solana-specific calculations, etc.

Read a detailed account of Neon’s composability libraries in this article.

‍

2) Precompiled contracts

‍

The second half of Neon’s composability mechanism is the ICallSolana precompiled contract, which is called by the smart contracts to execute the instructions, constructed with the help of composability libraries.

For Solidity developers, it behaves like a familiar contract interface. But instead of calling another EVM contract, it:

• validates the request,
• executes the instruction on Solana via CPI from the Neon EVM Program to the target Solana program,
• and preserves authority “as if” the Solana call is being made on behalf of the original Ethereum msg.sender.

‍

3) Automatic SPL ↔ ERC-20 token handling with ERC20forSPL

Once you can call Solana programs, the next question is: how do tokens behave?

That’s what Neon’s special hybrid token is for, called ERC-20-for-SPL.

It exposes an ERC-20-compatible Solidity interface (balanceOf, transfer, transferFrom, approve) but the underlying asset is an SPL token. So from Solidity and Ethereum tooling, the token behaves like ERC-20. Under the hood, token operations translate into modifications of Solana token accounts (ATAs) and program-derived state (PDAs), executed via Neon’s composability mechanism.

From a developer’s point of view, ERC-20-for-SPL behaves like any other ERC-20. The remaining question is how these tokens are created and registered inside Neon.

That’s handled by the ERC-20-for-SPL Factory Contract, which acts as the system-level entry point for issuing and managing ERC-20-for-SPL tokens on Neon EVM.

Depending on how the factory is invoked, it can register one of two ERC-20-for-SPL variants:

• Standard ERC-20-for-SPL - wraps an existing SPL token (such as SOL or USDC) and exposes it through an ERC-20-compatible interface on Neon EVM.
• Mintable ERC-20-for-SPL - creates a new SPL token via Solana’s Token Program and registers it behind an ERC-20 interface, with mint and freeze authority managed from Neon EVM.

Together, composability libraries, precompiled contracts, and ERC-20-for-SPL turn Neon EVM from an execution environment into a full interaction layer between Ethereum contracts and Solana’s native programs and assets:

• Composability libraries abstract away Solana’s complex architecture for EVM developers and handle Solana account logic, as well as create and format Solana-specific instructions
• Precompiled contracts handle execution and call Solana programs
• ERC-20-for-SPL makes Solana assets usable through Ethereum’s token model

But all of this would not be possible without the core of Neon’s architecture: the Neon Proxy and the Neon EVM Program.

The Neon Proxy preserves the EVM developer by accepting Ethereum-style transactions, emulating execution, and translating those transactions into Solana-compatible instructions. The Neon EVM Program anchors execution on Solana itself, interpreting EVM bytecode inside Solana’s runtime and committing state changes directly to Solana.

Together, they provide the execution foundation on which composability, precompiled contracts, and ERC-20-for-SPL can operate, ensuring that Ethereum logic runs predictably on Solana, while enabling direct, native interaction with Solana programs and assets.

That combination is what makes Neon more than “EVM on Solana”: it’s a system where execution, interaction, and value movement are designed to work across runtimes without forcing developers or users to cross that boundary themselves.

🚀 Build your first Neon dApp → https://docs.neonevm.org/docs/developing/get-started

📬 Join the Neon Developer Community on Discord or X

‍