You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current DynamicGenericFeeHandlerEVM.sol implementation of dynamic fee handling for generic messages would not work properly if deployed.
Logic inside function for calculating fee fetches handler based on resourceID and assumes it is compatible IERCHandler interface. This will never be true, as this will always be PermissionlessGenericHandler - that doesn't have function _resourceIDToTokenContractAddress.
This is tight to a bigger problem of DynamicFeeHandler assuming that fee is being paid in token that is transferred - this is not applicable for generic messages. What we actually want is to collect fees in base (native) tokens when executing generic calls.
Implementation details
These are just suggestions and final solution requires deeper dive into solidity code:
We need to add some logic inside DynamicFeeHandler that will decide if the fee is being paid in base (native) token or some erc20 token.
In conjunction with this, the implementation of _calculateFee inside DynamicGenericFeeHandlerEVM.sol needs to be changed to return 0x00..00 address or something like this - this information will be used to decide DynamicFeeHandler as mentioned in the first point.
Testing details
Revisit current tests, as they were written with wrong presumptions, so tests did not catch this.
Add unit tests
Acceptance Criteria
Passing unit tests
The text was updated successfully, but these errors were encountered:
Our current
DynamicGenericFeeHandlerEVM.sol
implementation of dynamic fee handling for generic messages would not work properly if deployed.Logic inside function for calculating fee fetches handler based on resourceID and assumes it is compatible
IERCHandler
interface. This will never be true, as this will always bePermissionlessGenericHandler
- that doesn't have function_resourceIDToTokenContractAddress
.This is tight to a bigger problem of
DynamicFeeHandler
assuming that fee is being paid in token that is transferred - this is not applicable for generic messages. What we actually want is to collect fees in base (native) tokens when executing generic calls.Implementation details
These are just suggestions and final solution requires deeper dive into solidity code:
_calculateFee
insideDynamicGenericFeeHandlerEVM.sol
needs to be changed to return0x00..00
address or something like this - this information will be used to decide DynamicFeeHandler as mentioned in the first point.Testing details
Revisit current tests, as they were written with wrong presumptions, so tests did not catch this.
Acceptance Criteria
The text was updated successfully, but these errors were encountered: