ERC-7631: Dual Nature Token Pair

ERCs
, ,
21

The skipping methods MAY be implemented. We will clarify.

22

is it similar to erc404?

23

Hi authors of ERC-7631, this is Victor, an EIP editor and current operator of AllERCDevs.

I like to invite you to our next AllERCDevs meeting (online) to present for 10min of your ERCs if you are interested!

AllERCDevs is a bi-weekly meeting for ERC authors, builders and editors to meet and help the drafting and adoption of an ERC. The next one is 2024-03-21 UTC 1600, let us know if this time works for you, I can put this ERC in the agenda, or you can add a response directly at 2024 1st AllERCDevs Agenda Thursday (EMEA friendly time) ¡ Issue #17 ¡ ercref/AllERCDevs ¡ GitHub

1 Like
24

It is similar, with the main difference being that this is a two-contract system.

ERC20 and ERC721 are incompatible for a single-contract implementation if we want to be pedantic about full standard compliance. This is due to the collision between the balanceOf, transferFrom, approve functions which share the same signatures between both standards.

For trading on popular platforms (e.g. Uniswap, OpenSea, Blur), a single-contract system is feasible if the accounting logic is implemented carefully to not trigger edge cases in practice. However, one cannot assume compatibility with other platforms that expects exact ERC-20 and ERC-721 behavior (or if you want to build tools later on that rely on these behavior). Due diligence must be done on per-platform basis for safety.

A single-contract system offers end user simplicity. A dual-contract system offers backwards compatibility and composability. You’ll need to choose depending on your context.

2 Likes
25

Without a standard for the relationship between the two, a security audit would be required every time.

I’ve been interested in pairing ERC20 and ERC721 before ERC404 and DN404, and I’ve seen other developers’ code, but each contract is different, and it’s hard to engage users in the market if you need to audit every time.

The market is closely interacting with the development ecosystem, and we don’t think we should ignore it. ERC20 and ERC721 pairing needs to be established as a standard.

1 Like
26

Thank you for sharing. I have briefly reviewed and have a few notes.

The IERC7631BaseNFTSkippable this is very application-specific behavior. And I cannot see any reason that a consumer would need to query this information. But more importantly, no such motivation is provided in the text itself.

Philosophically, I think this combined token type is a fun terrible idea. It’s fun, so do it. But these are not non-fungible tokens. Governments will hopefully see through the complexity and understand these are entirely financial assets.

1 Like
27

If you have 10,000 NFT bound to a fungible token, what happens is you transfer the 10% of the total amount to a DAO? You have to burn and mint 1000 NFT, which is impossible in a single transaction.
But, if the project owner can set some wallets that skips the standard NFT behavior, those large transactions become possible, which is the rationale behind IERC7631BaseNFTSkippable.

However, what happens if an investor accumulates a lot of tokens and at some moment needs to transfer them? Since they don’t want to renounce to their NFT, they won’t take advantage of the skippable interface and will be forced to do many small transactions.

My doubt with the 404 model, since the beginning, is that it is prone to out-of-gas denial-of-service issues and setting a standard for something that is intrinsically vulnerable seems a bad idea.

29

I’m very curious about that last sentence.

@Vectorized , what do you think is the maximum number of DN404 (e.g. ASTX, the representative token of DN404) tokens that can be sent in a single transaction under the current circumstances?

30

Around the ballpark of 500 tokens for DN404.

Depends on your implementation too.

31

I will clarify the motivation of IERC7631BaseNFTSkippable on the proposal.

It can be considered like an optional extension (e.g. IERC721Enumerable), which is good to have in certain situations.

In one of our launches, we saw many snipers intentionally calling the setSkipNFT function to save on gas, as they were only interested in the ERC20 price action and not the ERC721 pictures.

32

The cumulative gas costs of transferring hundreds of ERC721 tokens into a single account will be similar to the cumulative gas costs needed to transfer these tokens out of the account.

In this case, it will be like any other regular ERC721 collection.

33

If I may share this extensive article discussing DN404s and why they are useful in support of ERC-7631.

This type of dual nature contract pair will likely be the main choice for L2 NFTs going forward as they make NFTFi AMM tools like NFTX less necessary to establish liquidity and allow yield farming while also making buying fractions of NFTs on DEXs more native and accessible to the NFT.

NFT Skipping is very useful for when someone wants to hold some fractions of an NFT but doesn’t care about reserving any specific IDs. They can hold ERC-20s in a contract and then interact with other contracts like a DEX to stake those ERC-20s and earn yield without paying the extra gas of interacting with the ERC-721s too.

Overall ERC-7631 has many benefits for artists and their communities over pure ERC-721s. I say this as COO of the NFT launchpad/marketplace Scatter.

1 Like
34

I still don’t understand why anyone would want skippable NFTs. It seems obvious that this should be removed from any spec.

Reason 1) If you have 10,000 NFTs and you want to transfer 1,000 of them, don’t. You can’t do that. Or you have to wrap them. “Transferring 1,000 NFTs” clearly shown that they are not actually non-fungible.

Reason 2) If you transfer 1,000 NFTs to Uniswap (by transferring ERC-20 tokens) but you don’t lose those NFT. Then somebody else gets the ERC-20s. And they transfer them to somebody else. Doesn’t that mean you keep 1,000 NFTs and somebody else has 1,000 NFTs all from the same underlying ERC-20 tokens? That’s weird.

Reason 3) Who decides which contracts are skipped? This power vests with somebody. Who inputs the Uniswap V4 address? V5? This behavior makes everything weird. I can’t imagine multiple people would want this.

These are some of the points discussed today on the Community Service Hour call about this topic.

1 Like
35

The skip NFT methods are optional, but recommended.

  1. It is akin transferring ERC-20 tokens that can be materialized into NFTs later on.

    I find this similar to buying call options where transferring the actual asset would be logistically costly (real-world transportation costs = gas costs of actually minting the NFTs).

    • Loading vesting contracts (e.g. Hyperliquid, Sablier) with large amounts ERC-20 tokens to be vested to many users.
    • Loading candy machine contracts with large amounts of ERC-20 tokens to sell to customers.
    • Transferring large amounts of ERC-20 tokens in / out of a liquidity pool, liquidity migration.
    • Transferring large amounts of ERC-20 tokens between DAOs.

    Including these methods in the standard will allow applications to conveniently display the option for users to skip NFTs.

  2. We recommend the skip NFT flag to only affect automatic minting of ERC-721s to recipients of ERC-20 tokens.

    Typical implementations should burn / transfer the appropriate number of ERC-721s when ERC-20s are transferred out.

  3. We recommend the skip NFT flag to be turned on by default for all smart contracts.

    Smart accounts and other contracts that need the ERC-721s can permissionlessly toggle the flag off.

    We recommend that the setSkipNFT function to be kept permissionless.

1 Like
38

Similar idea but based on ERC-20 and ERC-1155 are introduced as ERC7681 here.

Instead of a token pair approach, a single contract with full compliance can be achieved with 20 and 1155 instead of 721. Would love to see if there is any opinion of this similer approach.