ERC-7611: Sovereign Bridged NFTs

This is the discussion thread for:

The ERC-7611 proposal

That has an open pull request on Ethereum/RFCs here.

ERC-7611 proposes an extension to ERC-721 that facilitates seamless migration of NFTs across Ethereum’s rollup ecosystem without forcing NFT communities to cede sovereignty to an interoperability protocol.

NFT communities are currently stuck on the smart contract platform of their original minting. This means that they are isolated to a very small subset of the market on a single rollup, or that their users are forced to pay extremely high gas fees on L1. With all of the innovation happening across the rollup ecosystem it is essential that we establish an open and neutral way for NFT communities to seamlessly expand into the L2 ecosystem and harness the cost savings and innovation happening in these ecosystems.

This is especially important as NFTs have driven some of the most mainstream adoption of Ethereum, so we need to make sure that they are accessible and functional across L2s where a majority of the next wave of users will likely onboard into directly.

Providing sovereignty and security to NFT communities as they expand across the rollup ecosystem is essential, below we enumerate a few questions in particular that we would like to open discussion around to make sure that we establish this standard in a way that best aligns with the community interests:

Should we abstract out the bridge authorization interfaces from any specific token standard?
The work in this ERC has been largely inspired by the prior contributions of the Connext team under ERC-7281 which provides the same functionality for ERC-20s. You’ll notice that the bridge authorization interfaces match ERC-7281 exactly — we believe this is the best decision so that as a community when we build tooling to empower NFT communities, that tooling can similarly be used to support token communities and vice versa. However, what about ERC-1155s, ERC-6551s, etc.? Should we launch a new specific standard extending the interfaces of each with the same authorization interfaces or should we instead create one singular interface that can be inherited by any digital asset standard to facilitate secure, sovereign transfers across rollups?

Should we keep the mintBatch and burnMatch functions?
We extended the interface to include batching functionality for transfers across smart contract platforms. The logic here is that in general this is a pain point when working with ERC-721s in a single smart contract platform, but the pain for developers goes up even further when migrating ERC-721s across domains. This manifests both in terms of complexity, but also in the form of cost.

I’d like to end on a note thanking the Connext team for their prior work on ERC-7281, it really is fantastic work that empowers token communities to embrace Ethereum’s modular ecosystem in a secure way that preserves sovereignty. We’re proud to be expanding these principles and bringing them to other digital asset standards and looking forward to collaborating with others in the community who wish to promote a future of Ethereum where no proprietary risk or lock in is baked into a future that should remain open, neutral and censorship resistant.

1 Like

This is something I’ve been really interested in so expect me to participate a lot on the discussion :sweat_smile:

I understand you are using ERC-7281 as a starting point but I don’t actually see much benefit in all this limit settings which add a lot of overhead. At most I would see useful a way to set maxSupply (which could be “unlimited”, i.e 2**256 - 1).

Can you add a free bytes data parameter on mint and burn? This would allow richer standards to use the bridging functionality too, for instance ERC-5773 which allows NFTs to have multiple assets could use this to pass the data for such assets.

I do like the batch functionality, but having struggled too often with size limits I’m not sure if it’s a good idea, this already has to go on top of 721 and if your contract has other extensions you might run out of space (please don’t suggest diamonds, those are terrible UX :grimacing:). On top of that, usually lighter standards have more chances or making it through.

With that said, I think the localSupply method is absolutely useful and would even include it in the standard.

On the LockBox, for now I just have 2 things.

  1. I think only the bridge should be able to call withdraw, if that’s the case please add a @dev comment on it. If that’s not the case, could you explain why?
  2. I’m not fan of the name, I would rather have it reflect more it’s use. Something like BridgeLock or CrossChainLock.

Finally (for now), do you have any mock implementation?

1 Like