This post contains a proposal of the ERC-20 token support for gas fees feature rollout for Aurora engine. The rollout consists of two stages. The ERC-20 to be used as gas tokens should be whitelisted, the proposal which tokens to whitelist and the update to the behaviour of the default RPC (https://mainnet.aurora.dev/) is presented.
Within the post I frequently use MYTOKEN. This notation means any arbitrary ERC-20.
Unlike Ethereum, gas fees on Aurora represent a payment from the user to a chosen RPC, not an unknown validator (see official docs). Current Aurora architecture forces RPCs to accept payment for relaying the user transaction in ETH. This is fully compatible with Ethereum, however, introduces exchange rate risks: ETH<>NEAR for actual payment for the tx execution, ETH<>USD for admin salaries and servers.
Allowing RPCs to choose the payment mechanism allows for more flexible business models for RPCs. For example:
- RPCs that would like to reduce the risks of ETH <> USD conversion may charge users is stablecoins: USDC / USDT,
- RPCs that would like to reduce the risks of ETH <> NEAR conversion may charge users in NEAR,
- RPCs that would like to incentivise their users to use the affiliated token MYTOKEN may charge users in this token.
Obviously, any combination of the above models may be adopted by the RPC: say, an RPC may accept ETH for compatibility, but allow for MYTOKEN gas payments with a discount.
To our best knowledge the tech of arbitrary ERC-20 usage as a gas token is not yet adopted on any of the major EVM-compatible networks.
Among all possible method to implement the above tech, we consider only the ones that are fully compatible with web3 RPC and Ethereum protocols (including pre-EIP-1559). Thus, we cannot add additional fields in transaction description like
The core problem in UI and overall Ethereum logic from the standpoint of ERC-20 gas tokens is non-zero value transactions. According to the Ethereum protocol, a transaction has
value field that describes the amount of ETH attached to the transaction which is to be transferred from the sender to recipient. An example of such transaction is wrapping ETH using WETH contract (see typical tx here). Thus, all the contracts with non-zero value methods expect ETH to be transferred to them, not something different. So, once a contract is deployed, it’s expected value token cannot be changed.
On the other hand, a standard UI communication to the user makes gas token indistinguishable from the base token – ETH. So, in case user would set up Aurora with MYTOKEN being a gas token the above mentioned
deposit WETH contract call will be displayed as the call that will consume 0.2 MYTOKEN, which would be extremely misleading.
Things get even worse with contracts that are deployed by developers that use MYTOKEN as their gas token. These developers (and all of their tools) should expect that their base token is MYTOKEN, which means that non-zero value transactions are expecting MYTOKEN transferred. While other contracts deployed may expect other tokens as value tokens.
The positive news about this problem is that in modern blockchains, there are almost no non-zero value transactions, excluding base token transfers and swaps (which in turn usually do wrapping of the base token into ERC-20, thus may be substituted with corresponding ERC-20 swaps). Example of such transaction may be the registration of the relayer for the Rainbow Bridge, that require 5 ETH as a safe deposit. According to our analysis such transaction constitute less than 0.1% of all transactions on Aurora.
Solution consists of the following key points:
- Introduce in Aurora Engine contract
Map<address, gasTokenAddress>, which would hold the gas token chosen by the EOA and
Map<address, valueTokenAddress>, which would hold the expected value token for smart contracts. These map dictates the logic of the non-zero value transactions. A constant low value for ETH should be chosen.
- Introduce a precompile
changeGasToken(address newGasToken). A constant low value for ETH should be chosen.
- In case an EOA with non-ETH gas token is calling
transfertransaction, execute the respective
gasToken.transfermethod with relevant events emitted.
- In case an EOA with non-ETH gas token is trying to execute non-zero value transaction, fail the execution
- Smart contracts’
valueTokenAddressshould inherit the
gasTokenAddressfrom the EOA that is deploying them and it should be not updatable after setup.
- All existing Aurora EOAs’ gas token should be mapped as ETH
- All existing Aurora smart contract value token should be mapped as ETH
- RPC should return the answer to
eth_getBalancebased on the EOA’s chosen
transfer(from, to, value)transaction should trigger
Important: As suggested below, the possible gas tokens should be whitelisted in the beginning. So, in case the user would try to set the wrong
gasToken through a precompile, an error should be thrown. In future, once the whitelist requirement would be lifted, there won’t be any protection from improper setting of the
gasToken. However, in such a case, a user still would be able to recover his account back to ETH with a zero gas
changeGasToken precompile call – for this he would need to find an RPC that would accept such call.
On the user side the solution should be implemented quite simply: during the setup of the wallet, a user can specify any token to be used as a base token and execute the respective
changeGasToken precompile call to set this token as gas token. Obviously, the user should check that the RPC that he uses accepts the gas payments in this token. Though, being at the first sight a complicated procedure, all the described moves can be done in several clicks during the network setup.
Since the ERC-20
transfer method behaviour may be quite complicated, the possible gas tokens should be whitelisted. This whitelist should include only ‘simple’ tokens. For the rollout of the first stage we propose to add to the whitelist only ETH and AURORA token.
We also propose to set the default gas token for new EOAs that start transacting on Aurora Mainnet to AURORA.
Default Aurora Mainnet RPC (https://mainnet.aurora.dev/) should be updated to support URL parameter
gas. Through this parameter, the RPC may control, whether the expected user gas token matches the actual user gas token specified through the precompile and return the error in case the user is trying to execute the non-zero value transaction otherwise.
We consider such a solution for RPCs a best practice and recommend all the RPCs to implement such behaviour to add additional protection for the users.
For all existing default RPC users we recommend to set up two networks: Aurora Mainnet (ETH) and Aurora Mainnet (AURORA), which will represent the same Aurora Mainnet, but with different base tokens. However, switching the networks in the wallet is not enough to switch the gas token, it influences only the user interface of the wallet.
In order to switch the gas token, we propose to implement a lightweight embeddable gas token switching module (similar to embeddable Rainbow Bridge) that can easily let users to switch base tokens and, in case of the usage of default RPC, automatically detect inconsistency in actual gas token and user-assumed gas token and propose to switch the networks.
- Users that use AURORA as gas token won’t be able to execute non-zero value transactions before switching the gas token back to ETH
- Users that use AURORA as a gas token won’t be able to see their balance of ETH (no problems with wETH or other ERC-20s).
Stage 1 solution can be enhanced further through the following logic:
valueTokenAddressshould be available within the execution of the transactions inside EVM. This would require the passage of the respective Map inside the EVM.
- In case during the execution, a non-zero value transaction creates non-zero value calls to the contracts with the same
gasTokenAddressof the initiated EOA, this transaction can be executed. Otherwise, transaction should fail.
This update would allow for a more rich experience for the users without the need of switching between gas tokens. However, it requires work inside the EVM codebase (which is not the case for the stage 1).
Once the stage 1 of the solution is rolled out and tested we expect more tokens to be added to the whitelist. First of all, major stablecoins and NEAR, bridged over the Rainbow Bridge to Aurora. Over time the requirement of the whitelist may be removed.
2 Feb: updated Important part in Solution, stage 1 description