[Reposted from FVM Forum] Ecosystem Supported WFIL contract

[trruckerfling]

[reposted from OP @amiller68, Dec 2022]

As of Jan 2022, the FVM Forum will be merging into the Filecoin Community Discussion here, as FVM and Filecoin often go hand-in-hand for builders

Standard WFIL

TL;DR: well-supported WFIL is an easy lift and value add to the FEVM

If the FEVM wants to support DeFi use cases it needs to adopt ERC20 tokens support.
If the Network wants these tokens to be exchangeable with FIL, it needs to implement an ERC20 wrapper around FIL.
This token contract would require no staking or liquidity, and just makes FIL usable in standard DeFi use cases.
Rather than developers deploying a bunch of different versions of WFIL, the PL team should deploy its own and advertise that as the standard WFIL on the Filecoin FEVM.
This contract can either be deployed at Mainnet Launch or implemented as a Native Actor.

Following discussion from Forum:

(@scotthconner) Good idea. Wondering if we can literally just lift WETH solidity contract? What would be the benefit of making it native versus using FEVM?|

(@amiller68) Yep. See this contract for implementation: figswap-contracts/WFIL.sol at main · banyancomputer/figswap-contracts · GitHub
Maybe none, I was mostly musing. Might be best to keep FVM clean and just deploy as an FEVM standard.

(@anorth ) I am of the opinion that a wrapped Filecoin token should be implemented as a native actor, when FVM milestone 2 permits the deployment of native actors. It would implement the FRC-46 fungible token standard, but with a bit of library work should also be able to implement ERC20 in order to support calls directly from hosted FEVM actors. It could also possibly be upgraded to support future guest VM environments too (though there’s a risk tradeoff with upgradeable actors/contracts).
The Filecoin Foundation (not PL) may be able to sponsor and endorse such an actor.
However, this path would not result in a wrapped FIL until after user-programmed native actors are possible, which is some time after the FEVM launches. Unfortunately, that probably means that some people will deploy EVM-based wrapped Filecoin tokens in the meantime, fragmenting the space and possibly locking in an inferior non-native approach (depending again on upgradeability possibilities for the built-in EVM actors support FEVM contracts).
It would be nice to find some path to avoid that fragmentation yet support wrapped tokens early on. Perhaps a FIP could be proposed to the Filecoin core devs and foundation to do such a thing as a built-in actor. It’s probably too late for that to land with FEVM launch, though.

(@hammertoe) Given, as you say, someone is likely to deploy an ERC-20 wFIL on FEVM, should we not just embrace that and go ahead and create an “official” one sooner, rather than later. Then migrate to a native actor later on?

(@amiller68) Reading this I am becoming less convinced of the Native Actor approach.
“I am of the opinion that a wrapped Filecoin token should be implemented as a native actor, when FVM milestone 2 permits the deployment of native actors.”
I feel like then were not getting ahead of the issue I’m trying to point out here, which is that WFIL should be adopted as close to launch as possible in order to:

• offer documented DeFi support from the get go
• implement EVM parity. lots of optional things (like WETH) are common enough in the EVM ecosystem to be nominally standard. We should think of an ecosystem supported ERC20 wrapper as a requirement, not a feature
  “However, this path [implementing as a Native actor] would not result in a wrapped FIL until after user-programmed native actors are possible, which is some time after the FEVM launches. Unfortunately, that probably means that some people will deploy EVM-based wrapped Filecoin tokens in the meantime, fragmenting the space and possibly locking in an inferior non-native approach”
  Yes, Exactly. We would also have to research and design a migration strategy for these alternatives that will spring up in the meantime, in addition to developing the actor itself
  “It would be nice to find some path to avoid that fragmentation yet support wrapped tokens early on.”
  That would be an ecosystem supported WFIL deployment on FEVM. Its an easy lift and, at the very least, holds off fragmentation. Develop a Native actor later if you want, but supporting a FEVM from the get-go seems like a good route to take.
  Seems like an FEVM deployment would be easier, get ahead of the issue I’m trying to point out here, and reflects how WETH is actually implemented on EVM, (which I also haven’t heard anyone complain about).

(@laudiacay) IMO, standardizing and planning this is a very urgent priority. It may even be worth it to consider having it be a prerequisite for putting the FEVM on mainnet. If this gets messed up, I anticipate the risk of a lot of hacks and scams through mistaken token identities and liquidity move screwups. General ugliness that the ecosystem has to deal with could cause some reputational harm to the FVM ecosystem and Filecoin as a whole.
Let me explain: as soon as there are APYs from a lending pool for miner collateral, risk-tolerant speculators/degens (and a good bit of liquidity) will start flowing in. If decent FIL APYs launch on the FEVM in February, money’s gonna show up- maybe not as much as during the bull market, but money is gonna show up. If point 2 (below) is not planned and communicated correctly, and a difficult-to-migrate ERC20 gets a ton of liquidity in it, there will have problems: things will be entrenched and dangerous to migrate.
You’ll be stuck with a sort of janky/suboptimal/gas-expensive/illiquid way of transferring that particular ERC20 forever… and someone will eventually get annoyed and decide it’s good to migrate it. Each time this happens will increase the risk of embarrassing and destructive hacks and scams, but it’s completely avoidable with proper standardization work before mainnet.
I think there should be aggressive propaganda to ecosystem devs of “your liquidity goes in the FRC-46, with an ERC-20 shim laid over top” the second native actors launch- probably even starting right now, distributed through the f1 foundry and hackFEVM/SpaceWarp programs.
To get to this place, while still allowing for people to build on FEVM before native actors launch, there need to exist:

• standardization and heavy auditing of FRC-46, and checking ERC-20 compatibility in terms of relatively-similar calls existing (I think this is mostly done?)
• a well-documented and well-publicized procedure to safely migrate ERC-20s into FRC-46s (I am not sure whether this is done, I bet probably not, and it will most likely require ERC-20s to be deployed in a very different manner than people usually deploy them, probably less securely)
• a standard audited & well-publicized open-source FEVM wrapper to securely access FRC-46s through a standard ERC-20 wrapper (if step 1 is done right, the “1:1 correlation of methods” part should be fine, but we need to ensure this is possible to do securely- I slacked @raul about this a few weeks ago)
• guides for modifying forked code from ERC-20 compatibility to FRC-46-with-ERC-20-shim compatibility (there shouldn’t be many modifications needed, but there will be a lot of forks incoming to FEVM if the ecosystem attracts liquidity- many of the developers writing them will be incompetent- in the bull run, i witnessed devs with months of experience deploying code that secured millions of TVL)
• Token bridge endpoints (and anything an entity like Circle may deploy) will urgently need to be modified to be in line with 3. Any teams looking at doing a bridge or other manner of bringing stablecoins on/deploying official WFIL will need to be supervised to make sure they’re doing this right, because that’s where the liquidity will flow from in the system.
• developer tools so that deployment scripts can deploy to both FVM native actors and FEVM seamlessly (this is a lower priority)
  With regards to WFIL- you’ll probably want to be able to represent FIL as an FRC-46 no matter what happens… the steps above should solve the concern of ERC-20 compatibility within FEVM.

(@Schwartz10) At GLIF We were planning on launching an ERC20 WFIL token too - GitHub - glifio/wfil: ERC20 implementation of the $FIL token 2 - happy to use someone else’s, but I’d err on the side of using something with simpler features. Preparing now to figure out how to migrate an ERC20 token into a native actor seems hard and like it would change.
I don’t see a huge problem in ignoring a built-in migration path within WFIL to a native actor for now - folks who want to migrate can do it themselves - just burn your ERC20 WFIL tokens for FIL, and then mint FRC46 WFIL tokens with the received FIL. What downsides am I missing here?