Not a bug
Problem:
Every Ethermint-based/Evmos-based chains are using eth_secp256k1 and Coin Type=60 so the delivered address will be different with the other non-EVM compatible chains. Two cases can happens:
- Users sending funds from an EVM-compatible chains, so address will be compatible and users can access to their funds.
- Users sending funds from non-EVM-compatible chains, with different
eth_secp256k1|| Coin Type, the address is in-compatible so they can not access to their funds.
But, this won't usually happens, can say rare due just from mistake of front-end developers or sometime user when manually convert address.
Solution:
Can choose one of the following options:
- Re-use
x/recovery module from Evmos.
- Implement a light-weighted module that invokes "refund-to-sender" in certain conditions.
- Just ignore it.
In case of decided to implement a recover funds method, the following condition should be match.
- Account must not sent any transaction before (nonce = 0).
- Only base accounts are considered as source of funds that recoverable (non-contract, non-module, non-vesting,...)
- Check ERC-20 token pairs to detect balance of already converted by IBC middleware.
Not a bug
Problem:
Every Ethermint-based/Evmos-based chains are using
eth_secp256k1andCoin Type=60so the delivered address will be different with the other non-EVM compatible chains. Two cases can happens:eth_secp256k1||Coin Type, the address is in-compatible so they can not access to their funds.But, this won't usually happens, can say rare due just from mistake of front-end developers or sometime user when manually convert address.
Solution:
Can choose one of the following options:
x/recoverymodule from Evmos.In case of decided to implement a recover funds method, the following condition should be match.