Closed karim-en closed 1 year ago
Karim please adhere to the rules of the PR and do include the rest of the information in the description of the PR. There a number of areas missing as it is a requirement for all code changes to include a full completion of the PR template.
Description
When users bridge from Ethereum to Aurora Cloud (some specific silo), we need to verify that the recipient, are whitelisted in that specific Silo (if this whitelist mode is enabled). This is required to prevent non-whitelisted users from receiving tokens on the silo and breaking permission requirements, also having their tokens stuck. When a transfer happens and the recipient (and sender if feasible) don't satisfy our whitelisting requirements, that transfer is blocked, meaning that the recipient won't receive his tokens on the Silo.
It's also important that when the transfer is blocked, we instead transfer blocked tokens to our fallback address for tokens. This will help to make the manual recovery easier and won't add a significant security risk (as opposed to fallback just to the Silo/Aurora account itself and using admin access for the recovery).
Performance / NEAR gas cost considerations
There are insignificant gas cost increases. That is because we read from the storage the ERC20 fallback address in the execution of the
ft_on_transfer -> receive_erc20_tokens
method.Testing
The integration tests that test the new logic have been added.
Additional information
Implementation:
set_silo_params
to init/enable/disable the silo mode.set_fixed_gas_cost
is left for backward compatibility, but it can't be used to enable/disable the silo mode anymore.ft_on_transfer -> receive_erc20_tokens
call, if it is not, then replace the passedrecipient
with thefallback_address
How should this be reviewed
The reviewer should focus on the changed components that are described in the
implementation
section, and verify that the implementation is backward compatible, and the integrity of the storage was preserved.