Enabling Solana Users to Access EVM dApps Running on Solana

With the release of this whitepaper, Neon EVM introduces several features that unify user experience between Solana and EVM dApps deployed on Neon. This release follows the vision described in the Solana Network Extension approach and describes how Neon EVM infrastructure evolves.

The concepts described in the paper, which will be implemented into an SDK, are:

• Solana Signature Support: Enables Solana users to sign Neon EVM transactions with their existing Solana wallets, eliminating the need for EVM signatures and wallets.
  
• On-Chain Mempool: Introduces an on-chain system to schedule and execute Neon EVM transactions efficiently without relying on external tools.
  
• Associated Neon Accounts: Creates Neon accounts that abstract Solana addresses, and enables seamless interaction between Solana users and Neon EVM.
  
• Controlled Tree of Neon Transactions: Implements a method for atomic and parallel execution of transactions, managing state changes and aggregating results for complex interactions.
  
• Intent-Based Execution: Provides a mechanism to handle transaction intents, improving interoperability between EVM contracts and Solana programs despite Solana's limitations.

Read full whitepaper here

The Challenge: Unlocking Ethereum dApps for Solana Users

Solana and Ethereum are among the leading L1 blockchains, each with a vibrant dApp ecosystem and performance strengths. Yet, these two environments have not interacted with each other, primarily due to differences in programming languages, development tools, and infrastructure.

While Neon EVM allowed EVM dApps to access Solana tokens for Ethereum-like users, the previous solution involved the management of multiple wallets. Executing transactions on Neon EVM has required EVM signatures using the secp256k1 elliptic curve, necessitating the use of EVM wallets like MetaMask. This requirement presents a significant obstacle for Solana users accustomed to the ed25519 signatures used in Solana and the inability to use Solana wallets like Phantom, Backpack, and Solflare.

With the solution presented below, EVM developers can natively tap into the Solana user base by reducing fragmentation and simplifying onboarding.

Exploring “Solana-Native” features

The whitepaper sheds light on various Solana-native features. Five key features to focus on include the following:

Solana Signature Support within Neon EVM

To eliminate the need for Solana users to manage additional EVM wallets, Neon EVM modifies its transaction validation process to accept Solana's ed25519 signatures. This adaptation involves:

• Signature Validation Adaptation: Adjusting Neon EVM to recognize and validate ed25519 signatures.
  
• Custom Transaction Types: Utilizing the transaction type property to define custom transaction types compatible with Solana signatures, adhering to EIP-2718 for typed transaction envelopes.

Technically, the EVM address (ethAddress) for a Solana user is derived using the Keccak-256 hash function applied to the Solana public key (solanaPublicKey). The address derivation formula is:

This method takes the last 20 bytes of the hash to form the EVM-compatible address, ensuring a unique and collision-resistant mapping. Solana signatures are then verified using Solana native cryptographic libraries within Neon EVM, ensuring secure validation.

Benefits

• Solana users can sign Neon transactions using their existing Solana wallets, such as Phantom/Backpack/Solflare. This integration reduces the steps required for users to interact with EVM dApps on Solana and keeps assets within the familiar Solana wallet environment.
  
• The use of a Solana wallet removes the need to migrate funds, maintaining SOL as a gas token and Solana network RPC. From the user's perspective, an asset swap is executed by sending SPL tokens and receiving back the SPL tokens for the selected asset.

Create Associated Neon Accounts to Unify Asset Management

Neon EVM addresses liquidity fragmentation by integrating the Solana and Neon EVM ecosystems, enabling users to interact with EVM-compatible dApps without unnecessary asset transfers. Previously, users relied on NeonPass to move SPL Tokens from Solana wallets to Neon EVM accounts, which complicated asset management and fragmented liquidity. This has now been simplified with the introduction of the ERC20forSPL contract, which connects the two ecosystems seamlessly.

Users with Solana wallets manage their SPL Tokens through Associated Token Accounts (ATAs). Neon EVM maps their Solana public keys to EVM-compatible addresses using Keccak-256 hashing, creating an Associated Neon Account that includes fields for the EVM-compatible address, Solana public key, transaction counter, chain identifiers, and internal balance.

When users interact with dApps on Neon EVM, the ERC20forSPL contract first checks their internal balance. If insufficient, it queries the user’s ATA on Solana to retrieve the necessary SPL Tokens. This process eliminates the need for NeonPass transfers and allows users to operate in Neon EVM while keeping their assets on Solana.

Benefits

• Simplified Asset Management: Users retain control over their assets in their Solana wallets without requiring intermediate transfers (e.g., via NeonPass).
• Reduced Transaction Costs: By leveraging on-chain balance queries and avoiding redundant transfers, users experience lower costs when interacting with EVM dApps.

Efficient Transaction Management with On-Chain Mempool

Efficient transaction scheduling and execution management are crucial for a smooth user experience. Neon EVM implements an On-Chain Mempool to store and manage scheduled Neon transactions. This allows Solana users to schedule Neon EVM transactions directly from their Solana wallets, with Neon proxies detecting and executing these transactions on their behalf.

The TreeAccount is a specialized account with scheduled Neon transactions, balances, and execution states. It includes the following:

• Payer's EVM Address: The EVM address associated with the Solana user.
• Last Slot: The last Solana slot in which the account was modified.
• Chain ID: Identifier for the chain namespace.
• Gas Limits: Maximum gas allowed for execution.
• Balance: Funds reserved for transaction execution.
• Transaction List: Scheduled Neon transactions with execution details.

The transaction scheduling protocol involves the user submitting a Neon EVM transaction to the Neon EVM program, which validates and adds it to the on-chain mempool. Neon proxies then monitor the mempool and execute transactions accordingly.

For larger transactions exceeding Solana's size limits, only the transaction hash is stored on-chain, and the full transaction is sent off-chain to Neon proxies. This approach allows for scalability and efficient handling of larger transactions without compromising network performance.

Benefits

• The on-chain mempool enhances scalability, ensures transaction integrity, and maintains the atomicity of state changes. Users benefit from efficient transaction management, and developers can leverage this system to create more complex and responsive dApps

Controlled Transaction Trees for Complex Interactions

To overcome Solana's immediate state application and lack of support for transaction reverts—which hinder complex interactions between EVM contracts and Solana programs—Neon EVM introduces a Controlled Tree of Neon Transactions. This mechanism manages complex interaction scenarios by organizing transactions in a tree structure, where each node represents a Neon transaction, and parent-child relationships define execution dependencies.

Key features include:

• Atomic Transactions: Each Neon transaction is atomic, storing state changes upon finalization.
• Parallel Execution: Transactions without dependencies can be executed in parallel, optimizing performance.
• Result Aggregation: Contracts can generate multiple transactions and aggregate results in subsequent transactions.

Benefits

• This innovation enables developers to build more complex and integrated applications, overcoming limitations by enabling atomic and parallel execution with controlled state changes.
• It enhances the robustness of interactions and improves user experience by preventing entire transaction failures due to a single error.

Intent-Based Execution for Conditional Transactions

Neon EVM incorporates Intent-Driven Execution, providing users and developers with the flexibility to execute transactions based on specific conditions or market states. Intents are defined as simple EVM code specifying execution conditions, adhering to static call rules (cannot modify state). Neon proxies evaluate these intents before executing transactions. If the conditions are not satisfied, the transaction is skipped without cost to the user.

This feature enables:

• Automated Trading Strategies: Execute trades only when market conditions meet certain criteria.
• Conditional Operations: Perform actions like token swaps when specific events occur on-chain.

Benefits

Intent-based execution provides greater control over transaction execution, improves resource efficiency, and reduces unnecessary costs for users. It enhances the flexibility and responsiveness of dApps to real-time conditions.

Conclusion

A call for feedback and collaboration: This whitepaper starts the Solana-native evolution of Neon EVM, seeking input from different perspectives and fostering developer participation among the Ethereum and Solana communities.
Here, we release our first draft and invite the builder community to contribute actively and start assessing the implementation on your dApps. The whitepaper can be accessed here.

The whitepaper translates into practice with the first feature—the upcoming release of our Solana Signature Wallet SDK. The Solana signature functionality is complete on the EVM side and partially implemented on the Proxy side—currently in testing and audits. Also, watch out for use cases and demo releases soon!

Join us in building the future of dApps on Solana. Explore Neon EVM today!

About Neon EVM
Neon EVM is the first of its kind—a Network Extension on Solana—designed to seamlessly integrate Ethereum Virtual Machine (EVM) compatibility into Solana’s high-performance ecosystem. By operating natively within Solana’s base layer, Neon EVM provides Ethereum developers with a fast, high-throughput pathway to deploy their EVM dApps on Solana, without the need to rewrite their contracts in Rust.

For more information about Neon EVM and future updates, visit neonevm.org and connect with the community on Twitter or Discord.