Neon EVM’s Mainnet Upgrade: Paving a Solana-Native Future for Ethereum dApps

In the evolution of technology, transformative advancements often occur through deliberate, strategic progress.

On January 24, 2025, Neon EVM Mainnet Upgrade introduced major developments, refining the process of building, deploying, and scaling decentralized applications in the ecosystem. With the introduction of our pivotal features—EIP-1559 support and the Solana Signature SDK—Neon EVM Mainnet lays the foundational step for a new chapter: one where Ethereum-compatible applications go Solana-native.

A Journey that Fast-tracks into a Solana-Native Environment

For too long, Ethereum developers faced a dilemma: leverage the rich tooling and familiar solidity of the EVM or dive into Solana’s blazing fast, high user-base blockchain—often at the cost of rewriting their dApps in Rust and further maintaining Solidity and Rust stacks.

Neon EVM changes that narrative.

We introduced our new whitepaper on December 8, 2024—the first step toward realizing the Solana-native vision for EVM builders. Here we aim to connect Ethereum’s developer-friendly tooling with Solana’s high-performant environment. A world where Solana wallets interact with Ethereum-compatible smart contracts, and developers can focus on innovation rather than technical roadblocks.

The whitepaper proposes an architect where Solana-native integrations are not merely possible—they’re intuitive and foundational.

With the Mainnet upgrade, this vision translates into a reality.

Key features of Neon EVM Mainnet upgrade inlcude:

1. Solana-native wallet support and Signature SDK
2. EIP-1559 implementation
3. Enhanced block.timestamp fix
4. Save HEAP in the Solana Account

A Closer Look at What’s Coming

Four major features being released are:

1. Solana-Native Wallet Support and SDK

For the first time, users will be able to interact with dApps on Neon EVM using their Solana-native wallets, such as Phantom, Backpack, and Solflare. This feature eliminates the need for EVM-specific wallets, creating a frictionless experience where users can execute Neon EVM transactions with their Solana wallets.

For builders, this means the ability to tap into the highly active Solana user base from their EVM application without having to redeploy it on Solana.

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 presented 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.

Previously, connecting to Neon EVM required additional steps that added friction to the Solana user experience:

Before Solana Signature Wallet SDK:

1. Add Neon RPC to Wallet: Users needed to configure their wallets by adding the Neon RPC endpoint from ChainList.
   
2. Transfer liquidity: Transferring assets from Solana or other EVM-based chains to Neon EVM necessitated using services like NeonPass or deBridge.
   
3. Manage multiple wallets: Executing transactions required EVM-compatible wallets such as MetaMask. Solana users, accustomed to wallets like Phantom or Solflare, had to manage multiple wallets, leading to a fragmented user experience.
   
4. Interact with Neon dApps: After completing the above steps, users could finally interact with dApps in the Neon EVM ecosystem. However, the complexity of the preceding processes often deterred less tech-savvy users and hindered widespread adoption.

Now, with the new Solana Signature SDK, the process is streamlined for seamless interaction:

After Solana Signature Wallet SDK:

1. Connect your Solana wallet directly to the EVM dApp UI (deployed on Neon EVM).
   
2. Interact with Neon dApps: execute and sign transactions from your Solana wallet using SOL as the gas token.

This upgrade makes the experience much more intuitive and efficient for Solana users by eliminating unnecessary steps and enabling native functionality.

By abstracting away complexities, Neon EVM is making it easier for Solana’s growing user base to tap into Ethereum dApps without additional onboarding barriers.

Simply put: No wallet switching. No convoluted workflows. Just one smooth, user-first experience.

2. EIP-1559 implementation

Neon EVM’s adoption of EIP-1559 is directed towards enhancing user and developer experience. While this fee model was first introduced in Ethereum’s London Fork, we bring this update today, and you may wonder, why. Well, primarily because prior to the peak of the Solana congestion/workload in early and mid-2024, the priority fee feature was not actively used, and there was little point in applying EIP-1559. However, today’s scenario is different, and priority fee is actively used in the Solana environment.

Neon EVM’s integration is not just about alignment—it’s about optimizing our vision towards Solana-native architecture for EVM dApps.

EIP-1559 introduces a dual-parameter fee system, with maxFeePerGas and maxPriorityFeePerGas. This system simplifies how fees are calculated and improves predictability. Users can set a maximum fee they are willing to pay, along with an optional tip to prioritize their transactions. Eliminating reliance on a single gas price ensures a more transparent and fair approach to handling fees.

In our implementation, the fee dynamics have been tailored to bridge the Ethereum and Solana ecosystems:

• Base fees for fair transactions: The baseFeePerGas serves as a predictable cost covering Solana’s network fees and an operator’s margin.
  
• Priority fees for speed: The priorityFeePerGas allows users to add a premium for faster transaction processing, giving them control over execution speed.

By incorporating these mechanisms, Neon EVM aligns with Ethereum’s tooling and wallets, such as MetaMask and Web3.js. Developers benefit from easier onboarding, while users gain clarity and control over transaction costs.

3. Enhanced block.timestamp: Removing Earlier Limitations

Previously, block.timestamp in Neon EVM faced a key limitation tied to its synchronization with Solana’s unique infrastructure. Unlike Ethereum, which guarantees consistent timestamping of blocks, Solana’s architecture introduced variability, meaning block.timestamp did not behave consistently on Neon EVM as expected in traditional Ethereum environments. Developers had to rely on workaround solutions or custom implementations, creating additional complexity for time-sensitive applications like DeFi protocols or gaming mechanics.

Following this Mainnet update, Neon EVM has resolved these inconsistencies, offering full functionality for both block.timestamp and block.number. These updates ensure parity with Ethereum’s native behavior, eliminating prior gaps and unlocking new opportunities for developers, including:

• Consistency: The updated block.timestamp now operates in a predictable, Ethereum-compatible manner, aligning Solana’s high throughput with the precision required by Ethereum dApps. This makes the migration of Ethereum dApps seamless, as developers no longer need to rewrite or modify their code to accommodate Solana-specific timestamp behavior.
  
• Mechanisms: EVM dApps may now implement accurate time-based DeFi mechanisms like interest accrual, staking rewards, or liquidation windows without workaround logic, opening use cases for builders.

4. Save HEAP in Solana Account

This functionality addresses a critical aspect of storage and performance optimization within the Solana network. In the context of Solana, the HEAP refers to dynamic memory used during program execution.

The HEAP is used when executing Solidity contracts on Neon EVM. Previously, the state of this memory was not preserved between iterations of contract execution, which could limit efficiency and functionality for certain dApps. Now, with the "Save HEAP" feature, the HEAP's state is saved directly within a Solana account, making it accessible across iterations. This enhancement enables:

• State persistence: Solidity contracts can now carry forward their execution context across multiple transactions or iterations.
  
• Improved resource management: Leveraging Solana accounts for HEAP storage ensures efficient resource use and supports more complex dApp functionality.

This feature improves how Solidity dApps handle memory-intensive operations on Neon EVM.

Why These Updates Matter

Neon EVM’s mission is clear: to provide the fastest and most accessible gateway for EVM developers to tap into Solana’s vibrant ecosystem. With Solana’s continuous innovation, including notable developments like the Firedancer validator client, Neon EVM stands at the forefront of delivering Ethereum-compatible applications to the blockchain (Solana) primed for mass adoption.

This Mainnet upgrade is a step in this direction. With plans to expand the technical roadmap, enhance community engagement, and address the needs of both developers and users, we continue on the path of enabling robust infrastructure.

Are you building?

For those interested in building, read our developer handbook. You may reach out to us on Discord or email our BD Lead at [email protected]. Don’t miss a beat: follow Twitter for the latest updates.

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.

Disclaimer: Solana is a trademark of the Solana Foundation. The use of the word ‘Solana’ in our materials solely reflects the Neon EVM products’ or services’ compatibility with the Solana network.