Discovery for supporting developer defined cross-VM associations

[sisyphusSmiling]

Description

Currently, developers can only define one side of the bridge assets - they deploy to either EVM or Cadence and the bridge deploys a corresponding contract in the non-native VM according to ecosystem standards (NFT: ERC721 & FT: ERC20). The primary motivation behind this design choice is to support users in permissionlessly moving assets between VMs, thus optimizing for ownership and ecosystem composability at the sacrifice of cross-VM customizability.

While this design satisfies basic use cases, there may be more complex instances that are not fully supported. The highly opinionated nature of the current bridge means that Cadence-native NFTs are relegated to simple ERC721s in EVM, disallowing bespoke functionality enabled by unsupported ERC721 extensions or even other ERC implementations such as ERC1155, etc. There have already been a number of requests asking how either net new or existing assets can be configured to support these bespoke cross-VM implementations and it's clear that this feature will be increasingly demanded.

The end goal ultimately is for a developer to define their implementations across Cadence and EVM and have the bridge satisfy a user's request to bridge the given asset, all without compromising the existing permissionless nature of the bridge. This should be the case for both net new assets and those already onboarded to the bridge. The focus of this discovery will be NFTs as they are a complete asset - a given NFT is either wholly defined by one or another contract.

Below are a number of considerations for this discovery phase:

• Cross-VM definitions for net new assets - new deployments to both VMs
• Migration paths for legacy bridged assets to newly associated contracts
• Mechanisms for app-layer platforms to identify legacy assets
• Sources of truth for existing and updated associations
• Upgradability of existing Cadence & Solidity bridge contracts