Token Economy

All EVMs require a native token to cover the transaction fee, also known as the gas fee. The EOS EVM native token is the EOS token.

EOS EVM Bridge

Interoperability is a key part of the EOS EVM design. Therefore the EVM design allows the economic value to flow freely between the native and EVM layers. This is where the EVM’s trustless bridge comes into play.

With the trustless bridge, users do not 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, and because 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. 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 is 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, that executes 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.

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

EOS EVM Gas Model

The gas model is another important part of the EOS EVM economy. 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. The EOS token serves as the gas token for the EVM. This ensures a simplistic design, while bringing added utility to the EOS token.

Gas Fees Calculation

Because the EOS EVM Contract runs on the EOS blockchain, regardless of what happens 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 the 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 at 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 PowerUp, or by paying for them with 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 mapping between gas fees and the underlying resource costs such as RAM aims for maximum compatibility and simplicity for the end user, especially during the initial launch. 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.

Gas Fees Route from EOS EVM to EOS Native

There are two computational costs associated with processing EVM transactions.

The EOS Native Computational Cost

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, at the launch of the network, 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 Internal EVM Operational Cost

The second cost is the internal EVM operational cost, 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.