Enable usage of ERC-20 as gas tokens

[Alex]

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.

Motivation

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.

Complications

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

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, stage 1

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 transfer transaction, execute the respective gasToken.transfer method 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’ valueTokenAddress should inherit the gasTokenAddress from 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_getBalance based on the EOA’s chosen gasTokenAddress.
• transfer(from, to, value) transaction should trigger gasTokenAddress.transfer(to, value) by from

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.

Rollout of stage 1

General notes

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.

Updates to the default RPC behaviour

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.

Known issues

• 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).

Solution, stage 2

Stage 1 solution can be enhanced further through the following logic:

• The valueTokenAddress should 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 valueTokenAddress as gasTokenAddress of 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).

Additional thoughts

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

[jma_dao]

I read all of it in my email, it sounded familiar

Great.

[shot]

What is the process for becoming an ERC-20 Aurora “gas” token?

[Alex]

Hello, @shot!
I would see this as a proposal to the DAO, since the DAO is governing the protocol. So, a process should look like a forum post with the explanation of the change, then once the temperature check is done, a vote initiated in the DAO, and once approved, then Aurora Labs can implement an additional token to be used as a gas token.

[Sanjin]

Do we as a AuroraDAO community plan to additionally increase the value of aurora token by automatic burning mechanism everytime the gas fees are paid in eth or any other token other than AURORA?

[Alex]

@Sanjin sure, this may be considered

[Sanjin]

Thanks for your answer, hope this can be proposed officialy.

[Sanjin]

thanks for your answer Alex, do you know if this will be proposed in the near future?

Thanks.

Sanjin

[Sanjin]

Hi Alex, I saw latest update on burning mechanism. Hope the collected Eth will buy back Aurora as well and burn it. However you proposed idea is as well great.

Sanjin

[israel_igboze]

A great one here.

Is this in process or its a proposal to be implemented in future?

Given thst using Aurora as Gas token will make proper sense of the token, for me its a good one.

Thanks, thanks