Before we introduce the utility of NEON, let’s take a quick look at why we developed the Neon EVM protocol.
What problem does Neon EVM solve?
Because Ethereum and Solana have different transactional structures by design, there has never been a meaningful solution that allows Ethereum dApp developers to take advantage of the transactional innovations offered by Solana.
So, just as mobile app developers had to develop for both Android and iOS to access both markets, till now, Ethereum dApp developers have had to custom develop to access Solana’s L1 market. Neon EVM protocol changes this.
Neon EVM is an Ethereum Virtual Machine on Solana that allows developers to scale Ethereum dApps by using Solana as the settlement layer.
In the mobile app space, Xamarin, Flutter, among other tools, provide cross-platform mobile app development. Similarly, Neon EVM brings dApp developers a robust cross-L1 blockchain development solution: allowing them to bring their dApps from Ethereum to Solana with minimal reconfiguration of the codebase.
What opportunities does Neon EVM Protocol create?
Neon EVM protocol provides dApp builders an opportunity to scale existing Ethereum dApps by using Solana as the L1 settlement layer. Furthermore, this protocol enables dApps to access tokens traditionally tied to the native L1 from EVM to Solana and vice versa. For the first time, Ethereum native dApps have access to both SPL tokens and the user base on Solana via one protocol.
What is the utility of NEON, the native token of Neon EVM?
The Neon EVM economy is fee-based. The Neon token, NEON, is an SPL utility token with 2 functions:
- Payment of gas fees
The Neon Proxy Operator accepts payment from the user in NEON tokens to pay the gas fees required for transaction execution. - Governance
Owners of NEON may engage in the Neon DAO governance activities.
Payment for Neon transactions
A Neon transaction is formed according to Ethereum’s standards. Within an Ethereum transaction, the user specifies what they are willing to pay for the gas spent on the transaction. In Neon EVM, this fee is taken in NEON to pay the entity that submits the transaction on Solana: the Neon EVM Operator (we will be bringing you more on Operators in upcoming articles). The Operator is an independent entity that provides a public endpoint that accepts Neon Transactions. They then process those transactions and submit them to a Solana Virtual Machine (SVM).
The cost of Neon transaction execution in Neon EVM is calculated according to Solana rules for Solana transaction execution. This enables the cost of gas in Neon EVM to be significantly lower than on Ethereum or an Ethereum-native L2, as it’s based on Solana’s gas price.
The Solana gas price is determined by fee parameters that include the number of compute units required and the number of signatures a transaction contains. By implementing Neon EVM to transact on Solana, the number of signatures is always set to 1: that of the Neon EVM Operator in charge of the transaction.
The fees paid in SOL tokens by the Neon EVM Operator fall into two categories:
- The fee to the Solana leader for executing the Solana transaction*
- A fee to the Neon DAO treasury: the body responsible for managing the design and function of Neon EVM
Governance
The Neon DAO manages the treasury to secure the future design and function of Neon EVM. This includes setting up Neon EVM parameters and agreeing on redesign and updates to the Neon EVM Program. For example, should incentivization strategies require modification, e.g. variables such as the size of the deposit required from Neon Proxy Operators who undertake iterative Neon transactions, the DAO governs the change process.
