Coin-centric option for egress fee model

[Joshua2Mars]

For stable coins like USDT, we may collect the egress fee in USDT for withdrawing USDT from EVM

[Joshua2Mars]

According to the user behavior patterns in the EVM ecosystem, apart from Gas fees, other fees such as Bridge fees are also coin-based, meaning that users pay fees in the corresponding token based on their intended token usage.

Therefore, it would be ideal for us to support two modes of collecting Egree fees.

• One mode is the current approach, where Egree fees are collected in the native token along with Gas fees.

• The other mode is to collect the main token of the user's interacting contract. For example, if it's a cross-chain transaction involving USDT, we would collect the fee in USDT, and if it's a cross-chain transaction involving USDC, we would collect the fee in USDC.

[stephenpdeos]

Updated requirements based on discussion 10/19

• There must be an updateable list of tokens that use a coin-centric model wherein their related egress fees are in the token of interest instead of EOS. The first example will be USDT.
• There must be a configurable egress fee for each token using the coin-centric model
• There must be a variable established to control the minimum value transfer of a given token managed at the contract level and reinforce via FE. This value will initially be set to the egress fee in order to protect users and deliver easiest movement of tokens within EOS ecosystem. If the minimum value is not satisfied, the ERC-20 contract should revert the bridgeTransfer call.
• There must be a method to manage egress fee values in relation to a given destination account or list of destination accounts. One example may be a list of exchanges directly integrated with EOS EVM and another may be exchanges that support in-line transfers, but are not yet directly integrated with EOS EVM.
• There must be a way to override the default egress fee for the (token symbol, destination EOS account) pair.

[stephenpdeos]

For the initial implementation, we will focus on the following requirements and others will be tracked in follow-on issue, #35

Acceptance criteria

• There must be an updateable list of tokens that use a coin-centric model wherein their related egress fees are in the token of interest instead of EOS. The first example will be USDT.
• There must be a configurable egress fee for each token using the coin-centric model
• There must be a variable established to control the minimum value transfer of a given token managed at the contract level. This value will initially be set to the egress fee in order to protect users and deliver easiest movement of tokens within EOS ecosystem. If the minimum value is not satisfied, the ERC-20 contract should revert the bridgeTransfer call.

Future requirements to be considered as part of solution delivered

• There must be a method to manage egress fee values in relation to a given destination account or list of destination accounts. One example may be a list of exchanges directly integrated with EOS EVM and another may be exchanges that support in-line transfers, but are not yet directly integrated with EOS EVM.
• There must be a way to override the default egress fee for the (token symbol, destination EOS account) pair.