EOS EVM Tokenomics Deep Dive

Author

EOS Network Foundation

Date

Apr 11, 2023

Building Bridges Between EOS EVM and EOS Native dApps

Interoperability was a key part of the EOS EVM design. In addition to ensuring that it’s easy for developers from other Solidity environments to launch their projects on the EOS EVM, it was also important that economic value could flow freely between the native and EVM layers. This is where the EVM’s trustless bridge comes into play.

With the trustless bridge, users don’t have to rely on third-party oracles to move tokens from EOS native to EOS EVM. Instead, they can simply send their tokens to the EOS EVM Contract (eosio.evm) and enter the address of their EOS EVM wallet in the memo field. This will move the asset from the native layer to the designated address on the EVM. When a user would like to move assets back to EOS native, the bridge allows an EVM transaction to trigger a transfer of EOS from the EOS EVM Contract to the user-specified EOS native account with an optional memo. The bridge frontend makes it easy for users to construct these types of EVM transactions.

Bridge Fee Break-Down

All EVM transactions, which includes outgoing bridge transfers, require the user to pay gas fees. These fees cover the regular costs of the system, which are described in further detail in the next section that discusses the EOS EVM Gas Model.

However, an incoming bridge transfer starts as an EOS transaction which then causes the EOS EVM Contract to internally generate an EVM transaction. The internal EVM transaction incurs a cost, but since it was generated by the EOS EVM Contract, there is no mechanism for the user to directly pay for the gas fees of that internal transaction. So instead the EOS EVM Contract covers the costs of that internal EVM transaction by deducting a small bridge fee from the incoming transfer amount. To avoid user confusion from a potentially volatile bridge fee, the bridge fee, while still configurable, is not directly coupled to the actual gas fee calculated. Instead it’s configured so that the system remains profitable on average. At launch, a bridge fee of 0.01 EOS per incoming bridge transfer is configured. But a static bridge fee and a goal of profitability means that the gas limit of the internal EVM transaction is conservatively set to only support Externally Owned Accounts as the destination.

Furthermore, while an EVM transaction executing an outgoing bridge transfer requires the collection of gas fees, the gas fee only covers the computational costs incurred with the EVM. An outgoing bridge transfer can in general trigger arbitrary EOS native smart contract code to execute at the destination account, and none of this additional computation cost is accounted for in the calculated gas fees. For this reason, outgoing bridge transfers can be sent to at most one external EOS account per EVM transaction. That account must either not have a contract deployed on it or it must be on a special egress allow list.

It is possible for a single EVM transaction to have multiple outgoing bridge transfers to different accounts. However, this requires using the more advanced functionality within the EOS EVM Contract where the destination account(s) first open an internal balance within the EOS EVM Contract and at later point in time withdraw funds collected within that balance to their external EOS accounts.

Improving the User Experience for EVM Users

The trustless bridge also removes a prominent barrier for users coming to EOS EVM from other EVM based ecosystems. That is the need to create an EOS native account. While not difficult, the process is foreign to those who are used to interacting with the blockchain through an Ethereum wallet such as MetaMask. Additionally, there is an added cost associated with creating an EOS native account that creates added friction for the end user.

To solve this, if a user only wishes to interact with EOS EVM, they can simply generate a free address in an application like MetaMask and connect it to the EVM. Then, they are able to purchase EOS native tokens on an exchange and send it in and out of the EOS EVM through utilizing the trustless bridge. This makes for a seamless user experience, where the end user is not required to interact with EOS native at all.

Currently, at a technical level, the bridging mechanism only works with the network’s native token, EOS. While not part of the beta launch, the EOS EVM engineers are considering going beyond this and enabling functionality to support other tokens in the future.

EOS EVM Gas Model

The gas model is another important part of the EOS EVM tokenomics. All EVMs require a native token to cover the transaction fee, also known as the gas fee. On the Ethereum network this would be ETH. After much deliberation, it was decided that EOS would serve as the gas token for the EVM, rather than launch a new token. This ensures a simplistic design, while bringing added utility to the EOS token.

Calculating Gas Fees

Because the EOS EVM Contract runs on the EOS blockchain, regardless of what’s going on within the EVM, ultimately EOS native resources such as RAM, CPU, and NET are being leveraged. The resource models of EVM and EOS native are quite different which makes mapping between them tricky, especially in regards to the cost of persistent contract storage.

EOS native uses an ownership model for RAM in which ownership of RAM tokens represent entitlements to a corresponding amount of bytes of persistent storage space for accounts and contracts. These RAM tokens can be bought and sold from an on-chain market with EOS. If the account/contract no longer requires the full storage space entitled by the amount of RAM tokens held on an EOS account, then the free space can be efficiently reused at a later date for other storage. Alternatively, the excess RAM can be sold in the on-chain market for EOS.

The other computational resources on EOS are CPU and NET. However, these are ephemeral resources that are acquired on a regular basis, for example via EOS PowerUp, or by paying for them using EOS.

On the other hand, EVM covers storage cost using gas fees, in the same way it covers the other ephemeral computational costs of the transaction. This simplifies how the costs are paid by the user. But it does provide limited opportunity to recover value if the contract no longer needs to store as much data.

The EOS EVM engineers considered many options for how to handle the mapping between gas fees and the underlying resource costs such as RAM. Ultimately, a decision was made to aim for maximum compatibility and simplicity for the end user, especially during the initial launch. So, the algorithm to calculate gas usage of an EVM transaction is exactly the same for EOS EVM as it is for other popular EVMs. The gas fee the user pays is then the gas usage multiplied by the gas price set in the transaction. This is enforced by the EOS EVM Contract to satisfy a configurable minimum gas price. The gas fee then gets split and routed appropriately to cover the necessary expenses of the system.

Routing Gas Fees from EOS EVM to EOS Native

There are two computational costs associated with processing EVM transactions.

The first cost is the EOS native computational cost for CPU and NET which must be covered by an EOS account that is the first authorizer of the EOS transaction wrapping the EVM transaction. A portion of the EVM transaction’s gas fee can be routed to this EOS account if they claim themselves as the “miner” of the EVM transaction and have opened an internal balance within the EOS EVM Contract.

The percentage of the gas fee routed to the internal balance of this miner is determined by a configurable parameter of the EOS EVM Contract called the miner cut. By setting appropriate values for miner cut and the minimum gas price within the EOS EVM Contract, the miners are expected to receive enough of the portion of the gas fees to cover their average CPU and NET costs as well as the cost of running a limited RPC node focused on accepting valid EVM transactions, wrapping them in EOS transactions, and submitting them to the EOS blockchain. While anyone can act as a miner, the ENF will provide this service to ensure that reliable RPC endpoints expected by wallets such as MetaMask are immediately available starting from launch.

The second cost is the internal EVM operational costs, which primarily consist of the EOS EVM Contract’s RAM consumption. This cost is covered by the remaining portion of the gas fees of EVM transactions that are not routed to the miner. Again, tuning the miner cut and minimum gas price parameters appropriately ensures sufficient fees are collected for the system to remain profitable. These fees accumulate in a special internal balance of the eosio.evm account which can be withdrawn with authorization of its active permission at any point in time.

The purpose of these accumulated fees is first to use them to buy more RAM for the EOS EVM Contract as free storage space shrinks due to additional accounts and contracts created, as well as more contract storage slots used. However, fees in excess of those needed for RAM coverage can be pulled out to cover other operational costs, e.g. subsidizing costs of running reliable RPC nodes for read requests, or can be allocated for future burns.

Increasing the Utility of EOS & Activating a Burn Mechanism

If you’re an EOS token holder, there’s plenty of reasons to be excited about the launch of the EOS EVM. Perhaps the most prominent reason is the added utility that this infrastructure brings to the network’s native token. By also utilizing EOS as the native token for the EOS EVM, a new use case for the token has been added and is expected to be highly utilized as projects begin deploying.

Burning RPC Profits

Additionally, with the beta version of the EVM, the engineers decided not to pursue any model that uses collected gas fees to automatically incentivize others to run full RPC nodes. This may be built out in the future but in the meantime it was decided that the ENF would maintain a reliable RPC endpoint for the community to utilize.

Because the ENF expenses, including RPC nodes, are already being subsidized by the network, the ENF is not required to take a profit from the fees left over after covering the cost of network resources. Instead, this presents an opportunity to create a burn mechanism underneath the gas model. The ENF has made a commitment to burn all of the profit that it collects from running its RPC server. Many other chains in the industry have introduced deflationary models to offset inflation and it’s important that EOS begin to implement similar models as network operations are funded through inflation.

In order to facilitate this, all profits generated from gas fees will be transferred to an account owned by the ENF. On a regular basis, the ENF will burn all of the tokens in this account and let the community know when this takes place. This is another way to ensure that the ecosystem’s tokenomics can remain competitive as EOS evolves.

Independent RPCs

Anyone is welcome to run their own RPC nodes rather than relying on the nodes run by the ENF. But currently the only automated mechanism for those running RPC nodes to get rewarded via the EOS EVM Contract is through the miner cut of the gas fees. This is designed to only cover the minimal costs of getting EVM transactions onto the EOS blockchain but is not designed to support the costs of full RPC services including read requests. However, an ideal goal for the EOS EVM engineers is that the network not rely on the ENF to operate nodes. So, in the future additional incentive models will be explored to address this aspect of the ecosystem.

Get Ready for the Launch of The EOS EVM!

There’s plenty of reasons to be excited for the launch of the EOS EVM and the token economy is only a small part of the tireless work that has been undertaken by the EOS EVM engineers. Important aspects of the EOS EVM tokenomics include:

Increased utility through the use of EOS as the EVM’s native token.
The trustless bridge, allowing EOS to be seamlessly transferred from EOS native to the EOS EVM.
The EOS EVM gas model, which is compatible with what EVM users expect at the frontend but at the backend it routes captured transaction fees to EOS native in order to cover the underlying resources costs associated with that transaction.
The upcoming burn mechanism that will burn all profits collected from running the ENF’s RPC endpoints.

The EOS EVM security audit is complete and mainnet beta is slated to launch on April 14. So, it’s an extremely exciting period for builders in the EOS ecosystem. If you have an idea for something you’d like to build or a project from another EVM that you’d like to launch on EOS, be sure to check out all the technical and financial resources available to the EOS community. Check out the recent testnet announcement for more details on how to get up and running quickly.

Help spread the word of this exciting milestone by sharing this article with your friends and be sure to follow the ENF’s social channels to stay in the loop on EOS EVM’s launch and more.

EOS Network

The EOS Network is a 3rd generation blockchain platform powered by the EOS VM, a low-latency, highly performant, and extensible WebAssembly engine for deterministic execution of near feeless transactions; purpose-built for enabling optimal Web3 user and developer experiences. EOS is the flagship blockchain and financial center of the Antelope framework, serving as the driving force behind multi-chain collaboration and public goods funding for tools and infrastructure through the EOS Network Foundation (ENF).

EOS EVM

The EOS EVM is an emulation of the Ethereum EVM, housed within an EOS smart contract. It offers feature parity to other EVMs in the space but with unmatched speed, performance and compatibility. EOS EVM connects the EOS ecosystem to the Ethereum ecosystem by allowing developers to deploy a wide array of Solidity-based digital assets and innovative dApps on EOS. Developers can use EOS EVM to take advantage of Ethereum’s battle-tested open source code, tooling, libraries and SDKs, while leveraging the superior performance of EOS.

EOS Network Foundation

The EOS Network Foundation (ENF) was forged through a vision for a prosperous and decentralized future. Through our key stakeholder engagement, community programs, ecosystem funding, and support of an open technology ecosystem, the ENF is transforming Web3. Founded in 2021, the ENF is the hub for EOS Network, a leading open source platform with a suite of stable frameworks, tools, and libraries for blockchain deployments. Together, we are bringing innovations that our community builds and are committed to a stronger future for all.