forta-network/forta-contracts

Add a layer of abstraction to FortaBridged to leave open bridging to other chains in the future

Ramarti opened this issue · 3 comments

I've been looking at the way some bridges work with ERC20s

  • xDai Omnibridge -> Deploys ERC667 token if it does not exists, handles minting and burning. Optional bridge extensions for custom tokens
  • Anyswap -> Not a lot ot info, seems like it generates the bridged tokens itself
  • Optimism -> Must implement interface IL2StandardERC20
  • Celo -> Looks like bridge handles minting in Celo chain, permissionless
  • Avalanche -> Permissioned listing, uses their own token contract for minting / burning
  • Arbitrum -> Several options regarding gateways, but the token itself must implement IArbToken

So I see 2 cases in bridging

  1. Generic wrapper token deployed by the bridge
  2. Custom contract that must implement some interface specific to the chain

Although FortaCommon implements the common ERC20 methods, FortaBridged is tightly coupled with the Polygon bridge.

If tomorrow we wanted to bridge to for example Optimism, we would have to create a different contract.

We could either:

  1. Rename FortaBridged to FortaBridgedPolygon so the tight coupling is made explicit.
  2. Make FortaBridged abstract, having these interal methods:
function _increaseL2Supply(address account, uint256 amount) internal {
   _mint()...
}

function _decreaseL2Supply(address account, uint256 amount) internal {
   _burn...
}

Then have each child contract of FortaBridged add each bridge interface.

The 2 options are basically the same with option 1 being just renaming and option 2 looking more "clean" to me, but the basic point is I think we should not give the general sounding name FortaBridged to a specific chain implementation.

We would have to deploy a different contract in Mumbai, but if this does not disrupt the flow of early participants I think it may be justified.

Amxx commented

I'd personally go for option 1.

With option 2, we would have FortaCommonFortaBridgedFortaBridgedPolygon anyway ... and the middle layer would include very little value.

I'd agree with renaming FortaBridged to FortaBridgedPolygon (or some variation of this name). I wouldn't add any additional complexity until there is a real need to develop bridged versions for other networks.

Renamed to FortaBridgedPolygon