Summary

1. Exchange Support

There are still exchanges which don’t support FIL transfer to f410/0x addresses, deposits from 0x/f410 addresses and deposits from smart contracts (including Filecoin’s multisig). The list of exchanges and possible interactions is here.

However, supporting all these interactions is technically possible for exchanges, it’s just a matter of them prioritising this work.

Therefore, there’s nothing for engineering team to do at the moment.

2. Referring to F1-F3 accounts by 0x addresses before they exist on-chain (details)

One of the issue is that user A is not able to transfer funds using Metamask to user B’s F1 address which doesn’t yet exist on chain.

Existing workaround: User A needs to go through a 3rd party tool. Recommended example is going to glif.io, which supports such transfer via FilForwarder contract.

Issue with the workaround: Such transfer is more expensive. Such transfer causes security concerns (”why am I sending to some contract?”)

There are more issues like this. Refer to details.

3. Multiple 0x addresses per smart contract (details)

Detailed analysis from FVM Engineering (@Anonymous)

Pain points we've seen so far:

• Exchanges
  • Many exchanges don't support withdrawing to 0x and/or f4 addresses.
  • Many exchanges don't support receiving funds from smart contracts (has always been an issue for the builtin multisigs as well).
• Tooling
  • We cannot send to an f1-f3 address from Metamask (and/or any tool that only supports 0x). We can send to a masked ID address, but the account must exist on-chain first for that to work (it needs to have an ID address).
    • Caveat: This could be done through a MetaMask Snap (in theory).
• Smart Contracts
  • There's no way to refer to a native account and/or smart contract (f1-f3) that doesn't yet exist on-chain with a 0x-style address. Calling said actors requires precompiles.
  • EVM smart contracts (and accounts) have two possible 0x addresses:
    • One derived from their IDs, one assigned by the EAM.
    • Normalizing said addresses requires calling a precompile.
    • Solidity's msg.sender, msg.origin, etc are always "pre-normalized", this issue only applies to addresses specifies by a user or derived from actor's ID.