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
Currently, FlowBridgeFactory.sol contains both the state pertaining to associations between deployed EVM contracts and relevant Cadence type identifiers as well as deployment logic to define bridged Cadence-native assets. Supported assets in EVM are limited to ERC20 and ERC721, but future feature requirements may entail supporting additional standards. In it's current form, this contract is not very upgradeable and may limit future extensibility.
Proposed Solution
Parse out the functionality of this contract such that the state and functionality are decoupled in a manner that would allow new ERCs to be added while maintaining all the same functionality as present. The coordinating COA owner should be able to deploy an EVM contract, passing identifying information about the related Cadence asset, query for deployed contract associations as well as add support to enable the deployment of new ERCs.
Based on initial conversations with @ramtinms this likely means moving the associations to a "registry" contract of some kind, and adding the notion of a set of "deployer" contracts. Calls to what is now the FlowBridgeFactory will route to the appropriate "deployer" based on given parameters which means the factory will act as a proxy, routing/delegating calls to the relevant
"deployer". This pattern should allow the deployment of future "deployer" contracts which are tasked with deploying a new ERC and the setting of a deployment signature (say deployERCX) to deployed contract address, of course restricted in access to the bridge COA.
The text was updated successfully, but these errors were encountered:
Issue To Be Solved
Currently,
FlowBridgeFactory.sol
contains both the state pertaining to associations between deployed EVM contracts and relevant Cadence type identifiers as well as deployment logic to define bridged Cadence-native assets. Supported assets in EVM are limited to ERC20 and ERC721, but future feature requirements may entail supporting additional standards. In it's current form, this contract is not very upgradeable and may limit future extensibility.Proposed Solution
Parse out the functionality of this contract such that the state and functionality are decoupled in a manner that would allow new ERCs to be added while maintaining all the same functionality as present. The coordinating COA owner should be able to deploy an EVM contract, passing identifying information about the related Cadence asset, query for deployed contract associations as well as add support to enable the deployment of new ERCs.
Based on initial conversations with @ramtinms this likely means moving the associations to a "registry" contract of some kind, and adding the notion of a set of "deployer" contracts. Calls to what is now the
FlowBridgeFactory
will route to the appropriate "deployer" based on given parameters which means the factory will act as a proxy, routing/delegating calls to the relevant"deployer". This pattern should allow the deployment of future "deployer" contracts which are tasked with deploying a new ERC and the setting of a deployment signature (say
deployERCX
) to deployed contract address, of course restricted in access to the bridge COA.The text was updated successfully, but these errors were encountered: