Answering with a blogpost to Bill Ackman’s recent “May I meet you?”

(Just type that question on X if you’ve missed the whole saga.)

Nice to meet you, it’s Neon, and I bring everything you need to plug Solana’s speed and liquidity into your EVM dApp, no Rust required.

You’ve been writing Solidity code, debugging, shipping - your entire project’s pipeline sits comfortably on the EVM stack. Now you’re looking at Solana and seeing new growth opportunities.

The default assumption is: rewrite everything in Rust, maintain a second codebase, and build a separate team. But before you roll up your sleeves and spin up an Anchor project, it’s worth looking at the two paths Neon opens instead. Two roads that let you access Solana’s speed, ecosystem, and liquidity without the migration overhead, Rust learning curve, or duplicated engineering effort.

You can keep the EVM tooling you know. You can integrate with Solana.

The only question is which road makes sense for your product.

‍

Road 1: Bring Solana users into your EVM app

You keep your Solidity code. Solana users keep their Solana wallets. The onboarding barrier disappears.

On this path, you make your existing EVM application accessible to Solana’s user base - without rebuilding your stack or maintaining a Solana-native version of your product. You deploy the same Solidity contracts you already use; the difference is that tens of millions of Solana users can now interact with them directly.

This is possible because Neon enables Solana wallets to sign and authorize EVM transactions. A Solana user doesn’t need MetaMask, they don’t need to switch networks, and they don’t need to bridge assets.

From their point of view, your dApp behaves like any other Solana application: they connect Phantom, Solflare, Backpack, or any Solana wallet they already use, sign a transaction, and continue through a familiar flow.

Neon takes that signature, executes your Solidity logic on Solana through the Solana-native SDK, and returns the result.

For many projects, this becomes the fastest way to reach Solana’s audience without building a parallel product or rewriting their app for the Solana stack.

User Flow:

‍

Technical solution behind it

Enabling access for Solana users relies on the following key features:

• Execution of Neon transactions with a Solana signature: Neon allows EVM transactions to be signed with ed25519 keys used by Solana wallets, which is achieved through:
  • Signature Validation Adaptation: Neon’s validator accepts ed25519 signatures.
  • Custom Transaction Types: used to designate Solana-signed Neon transactions.
• Onchain Mempool to enable complex interactions between EVM contracts and Solana programs. Neon’s core team has introduced a "tree of scheduled Neon transactions" that allows for breaking down larger, more complex Ethereum-like transactions into smaller, independent Neon transactions that can be executed in parallel without compromising the overall transaction logic.
• Conditional execution model. Scheduled transactions run only when predefined conditions are satisfied, reducing unnecessary failures and ensuring users pay only for successful execution.

‍

Example: Solana wallet users interacting with your EVM app

A good example of Road 1 in practice is the Solana Native Swap Demo, which shows how a Solana wallet (Phantom, Solflare, Backpack, etc.) can interact with EVM smart contracts deployed on Neon EVM without ever switching to an EVM wallet or bridging assets.

In the demo, PancakeSwap-style contracts are deployed on Neon, liquidity pools are created, and ERC20-for-SPL tokens are set up for testing. The frontend then lets a Solana user connect their wallet, initiate a swap, and sign the underlying Neon EVM transaction using their Solana keypair.

Behind the scenes, the flow looks like this:

1. A Neon EVM transaction is prepared (for example, a token swap through a router contract).
2. The Solana wallet signs that transaction with an ed25519 signature.
3. The signed transaction is submitted to the Neon network through Solana.
4. Neon executes the Solidity logic and returns the result back to the UI.

From the user’s point of view, it behaves like any other Solana application. From the developer’s point of view, it’s a standard EVM contract running on Neon with Solana-native signing.

The full demo is available here. Run it from the repo and let us know your thoughts in our Discord developers’ chat.

‍

Road 2: Bring Solana programs to your EVM users

You keep your Solidity code. Users keep their EVM wallets & access Solana programs without bridges.

If the goal is to expand your protocol’s reach to Solana’s liquidity and infrastructure while keeping your existing UX unchanged, Road 2 gives you a way to do that without reinventing your stack or retraining your users.

For many teams, the biggest barrier to exploring Solana isn’t the tech - it’s the users. Your audience already lives in MetaMask or another EVM wallet. They understand your signing flow and your UI. Changing their wallet habits is often harder than changing your backend.

By deploying your existing Solidity contracts on Neon EVM, your code begins executing inside Solana’s runtime through Neon’s precompiled contracts and composability libraries (learn about composability libraries here on our blog).

From that point on, your dApp can interact with SPL tokens, use Solana’s AMMs and liquidity pools, and call Solana programs directly. Neon’s ERC20-for-SPL interface takes care of the token-standard mismatch, and the composability layer handles the cross-runtime call logic.

To the user, none of this complexity is visible, they continue using your app exactly as they did before, signing transactions with the same EVM wallet they always have.

User Flow:

‍

How Neon executes EVM logic on Solana (high-level)

Neon consists of multiple core components that work together to pass Ethereum-like transactions to Solana. The key components include:

• Neon Proxy: acts as a gateway that accepts users' Ethereum-like transactions. It wraps the Ethereum transaction as a Solana transaction and passes the wrapped transaction to the Neon EVM program hosted on Solana.
• Neon EVM Program: executes the Ethereum-like transactions inside Berkeley Packet Filter (BPF) within the Solana environment. It allows EVM applications to interact natively with SPL tokens and Solana Programs.

‍

Example: Call a Solana Program (Orca) directly from your Solidity contract

One of the clearest demonstrations of Road 2 is the ability to execute a swap on Orca directly from your Solidity app using Neon’s composability feature.

At a high level, your app first fetches a price quote from Orca and reviews it (amounts in/out, slippage threshold). Based on the quote, it builds a standard Solana transaction containing Orca’s swap instruction.

Normally, an EVM contract wouldn’t be able to execute this instruction, but Neon’s composability method takes that Solana instruction and routes it through your Solidity contract. Neon wraps the instruction, executes it inside Solana’s runtime, and returns the result to your EVM environment.

From the developer’s perspective, it feels like calling any other external function from Solidity - the complexity of invoking a Solana program (including generating instructions & creating accounts) is handled entirely by Neon.

Here’s what that flow looks like in code:

const quote = await swapQuoteByInputToken(
   whirlpool,
   TokenB.mint, // devUSDC
   DecimalUtil.toBN(amountIn, TokenB.decimals), // Input Token Mint amount
   Percentage.fromFraction(10, 1000), // Acceptable slippage (10/1000 = 1%)
   ctx.program.programId,
   ctx.fetcher,
   IGNORE_CACHE
);
console.log(quote, 'quote');

console.log("estimatedAmountIn:", DecimalUtil.fromBN(quote.estimatedAmountIn, TokenB.decimals).toString(), "TokenB");
console.log("estimatedAmountOut:", DecimalUtil.fromBN(quote.estimatedAmountOut, TokenA.decimals).toString(), "TokenA");
console.log("otherAmountThreshold:", DecimalUtil.fromBN(quote.otherAmountThreshold, TokenA.decimals).toString(), "TokenA");

console.log('Executing executeComposabilityMethod with Orca\\\\'s swap instruction ...');
solanaTx = new web3.Transaction();
solanaTx.add(
   WhirlpoolIx.swapIx(
       ctx.program,
       SwapUtils.getSwapParamsFromQuote(
           quote,
           ctx,
           whirlpool,
           ataContractTokenB,
           ataContractTokenA,
           new web3.PublicKey(contractPublicKey)
       )
   )
);

[tx, receipt] = await config.utils.executeComposabilityMethod(
   solanaTx.instructions[0],
   0,
   TestCallSolana,
   undefined,
   user1
);
console.log(tx, 'tx');
console.log(receipt.logs[0].args, 'receipt args');
}

‍


You can find a complete Orca swap walkthrough in our docs.

‍

Why these roads exist

The idea of “just migrate to Solana” sounds simple until you actually consider what that means for an EVM team.

Moving to Solana usually requires learning Rust, maintaining a second codebase, running two completely different toolchains, recreating basic standards like ERC-20 and ERC-721, and essentially doubling the surface area for bugs and maintenance.

It’s not a migration; it’s a full parallel universe your team suddenly has to inhabit.

Teams rarely have the time or resources to rebuild everything in Rust while maintaining their existing EVM stack. These two Neon pathways exist because they offer a practical fast-track: a way to access Solana’s performance and liquidity without abandoning the ecosystem, tooling, and mental models your team already relies on.

Instead of rewriting contracts, rebuilding infrastructure, or splitting your engineering resources, Neon gives you a fast-track to extend what you’ve built into a new ecosystem.

‍