Title: ERC_7631__Dual_Nature_Token_Pair
Category: ERCs

Author: Vectorized
Date: 2024-02-20T22:08:20.421Z

Dual Nature Token Pair
requires: ERC-20, ERC-721
Abstract
A fungible ERC-20 token contract and non-fungible ERC-721 token contract can be interlinked, allowing actions performed on one contract to be reflected on the other. This proposal defines how the relationship between the two token contracts can be queried. It also enables accounts to configure if ERC-721 mints and transfers should be skipped during ERC-20 to ERC-721 synchronization.
Motivation
The ERC-20 fungible and ERC-721 non-fungible token standards offer sufficient flexibility for a co-joined, dual nature token pair. Transfers on the ERC-20 token can automatically trigger transfers on the ERC-721 token, and vice-versa. This enables applications such as native ERC-721 fractionalization, wherein purchasing ERC-20 tokens leads to the automatic issuance of ERC-721 tokens, proportional to the ERC-20 holdings.
Dual nature token pairs maintain full compliance with both ERC-20 and ERC-721 token standards. This proposal aims to enhance the functionality of dual nature token pairs.
To facilitate querying the relationship between the tokens, extension interfaces are proposed for the ERC-20 and ERC-721 tokens respectively. This enables various quality of life improvements such as allowing decentralized exchanges and NFT marketplaces to display the relationship between the tokens.
Additionally, users can configure if they want to skip ERC-721 mints and transfers during ERC-20 to ERC-721 synchronization.
Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Overview
A dual nature token pair comprises of an ERC-20 contract and an ERC-721 contract.
For convention, the ERC-20 contract is designated as the base contract, and the ERC-721 contract is designated as the mirror contract.
ERC-20 Extension Interface
The ERC-20 contract MUST implement the following interface.
interface IERC7631Base {
    /// @dev Returns the address of the mirror ERC-721 contract.
    ///
    /// This method MAY revert or return the zero address
    /// to denote that a mirror ERC-721 contract has not been linked.
    ///
    /// If a non-zero address is returned, the returned address MUST
    /// implement `IERC7631Mirror` and its `baseERC20()` method MUST
    /// return the address of this contract.
    ///
    /// Once a non-zero address has been returned, this method
    /// MUST NOT revert and the returned value MUST NOT change.
    function mirrorERC721() external view returns (address);
}

The ERC-20 contract MAY implement the following interface.
interface IERC7631BaseNFTSkippable {
    /// @dev Emitted when the skip NFT status of `owner` is changed by
    /// any mechanism.
    ///
    /// This initial skip NFT status for `owner` can be dynamically chosen to
    /// be true or false, but any changes to it MUST emit this event.
    event SkipNFTSet(address indexed owner, bool status);

    /// @dev Returns true if ERC-721 mints and transfers to `owner` SHOULD be
    /// skipped during ERC-20 to ERC-721 synchronization. Otherwise false.
    /// 
    /// This method MAY revert
    /// (e.g. contract not initialized, method not supported).
    ///
    /// If this method reverts:
    /// - Interacting code SHOULD interpret `setSkipNFT` functionality as
    ///   unavailable (and hide any functionality to call `setSkipNFT`).
    /// - The skip NFT status for `owner` SHOULD be interpreted as undefined.
    ///
    /// Once a true or false value has been returned for a given `owner`,
    /// this method MUST NOT revert for the given `owner`.
    function getSkipNFT(address owner) external view returns (bool);

    /// @dev Sets the caller's skip NFT status.
    ///
    /// This method MAY revert
    /// (e.g. insufficient permissions, method not supported).
    ///
    /// Emits a {SkipNFTSet} event.
    function setSkipNFT(bool status) external;
}

ERC-721 Extension Interface
The ERC-721 contract MUST implement the following interface.
interface IERC7631Mirror {
    /// @dev Returns the address of the base ERC-20 contract.
    ///
    /// This method MAY revert or return the zero address
    /// to denote that a base ERC-20 contract has not been linked.
    ///
    /// If a non-zero address is returned, the returned address MUST
    /// implement `IERC7631Base` and its `mirrorERC721()` method MUST
    /// return the address of this contract.
    ///
    /// Once a non-zero address has been returned, this method
    /// MUST NOT revert and the returned value MUST NOT change.
    function baseERC20() external view returns (address);
}

Rationale
Implementation Detection
The mirrorERC721 and baseERC20 methods returning non-zero addresses suffice to signal that the contracts implement the required interfaces. As such, ERC-165 is not required.
The getSkipNFT and setSkipNFT methods MAY revert. As contracts compiled with Solidity or Vyper inherently revert on calls to undefined methods, a typical IERC7631Base implementation lacking explicit getSkipNFT and setSkipNFT definitions still complies with IERC7631BaseNFTSkippable.
NFT Skipping
A useful pattern is to make getSkipNFT return true by default if owner is a smart contract. This allows ERC-20 liquidity pools to avoid having ERC-721 tokens automatically minted to it by default whenever there is an ERC-20 transfer.
The choice of getSkipNFT returning a boolean value is for simplicity. If more complex behavior is needed, developers may add in extra methods of their own.
Implementation Conventions
The ERC-20 contract is designated as the base contract for convention, as a typical implementation can conveniently derive ERC-721 balances from the ERC-20 balances. This does not prohibit one from implementing most of the logic in the ERC-721 contract if required.
This proposal does not cover the token synchronization logic. This is to leave flexibility for various implementation patterns and novel use cases (e.g. automatically rebased tokens).
Linking Mechanism
The linking process omitted for flexibility purposes. Developers can use any desired mechanism (e.g. linking in constructor, initializer, or via custom admin-only public methods on the two contracts). The only restriction is that the pairing must be immutable once established (to simplify indexing logic).
Backwards Compatibility
No backward compatibility issues found.
Security Considerations
Synchronization Access Guards
External methods for synchronization logic must be guarded such that only the other contract is authorized to call them.
Rare NFT Sniping
For dual nature collections that offer ERC-721 tokens with differing rarity levels, the ERC-721 metadata should be revealed in a way that is not easily gameable with metadata scraping and ERC-20 token transfers. A recommendation is to require that an ERC-721 token is held by the same account for some time before revealing its metadata.
Out-of-gas Denial of Service
ERC-20 transfers can automatically trigger multiple ERC-721 tokens to be minted, transferred or burned. This can incur O(n) gas costs instead of the typical O(1) gas costs for ERC-20 tokens transfers. Logic for selecting ERC-721 token IDs can also incur additional gas costs. Synchronization logic must consider ERC-721 related gas costs to prevent out-of-gas denial of service issues.
Implementations
https://github.com/Vectorized/dn404

Author: Philogy
Date: 2024-02-21T03:53:42.002Z

What’s the point of the non-fungible paired ERC721 if it’s actually fungible? Seems like a lot of unnecessary complexity and attack surface for not much benefit.

Author: Vectorized
Date: 2024-02-21T04:37:50.525Z

Gachapon game mechanics. Most NFTs are emotional products, so it’s hard to rationalize.
Given the market demand, we would like to develop flexible and safe ways for people to use such mechanisms.

Author: brrito
Date: 2024-02-21T13:59:06.656Z

Speaking as a long-time NFT fractionalization skeptic who’s trying to understand why “ERC404” is so popular right now: the main benefit IMO is defragmenting liquidity and attention. ERC721s which were previously only traded on Blur and OpenSea can also be traded on CEXes like Binance and Coinbase (in ERC20 form), and vice versa.
Seems to make sense and is valuable in the short-medium term, since NFTs are mostly used for speculating at the moment, but agree that making non-fungible assets fungible defeats the purpose.

Author: Tsubasa
Date: 2024-02-21T15:54:39.510Z

the market seems to have a very positive reaction to this new hybrid type of nature. Mainly increased flexibility on the collectors side and additional game theory methods to how traditionally supply and demand behaviors of users would change and reflect on primary and secondary markets.
It is definitely an exciting experiment and especially when initial implementations like the "erc"404 caused a lot of inefficiency resulting in gas spikes in the past few weeks, this implementation by the ‘avengers’ is a great product birth by adversity and a good step towards ‘optimization to market needs’.
Kudos to the authors.

Author: Tsubasa
Date: 2024-02-21T16:07:42.101Z

Good point!
In regards to ‘making non-fungible, fungible’, it is likely a response to the nature of how the NFTs landscape has been transforming over the years, since the 2021 era, and the introduction of blur, have shown that more fungible versions of art or one with a hybrid nature would have its own niche and could potentially become a large segment in future. When we also consider what this does to collecting art and reveal mechanisms it also brings an interesting conversation to the table.

Author: tba
Date: 2024-02-21T19:47:35.559Z

Big benefit of this proposal is the seamless synchronization between ERC-20 and ERC-721 contracts. you can basically establishing a dynamic relationship between these tokens and users can experience unparalleled flexibility and efficiency in managing their assets. tx’s initiated on the ERC-20 contract automatically trigger corresponding actions on the ERC-721 contract, and vice versa, facilitating effortless token management and enhancing user experience.
Furthermore (as already mentioned by brrito) the proposal allows not only trading on NFT marketplaces, but also on decentralized and centralized exchanges which brings a lot more attention to it. By bridging the gap between fungible and non-fungible tokens, it opens even more doors to a world of possibilities for creators, investors, and enthusiasts alike. With fractionalized buying it also brings more opportunities for investors to gain exposure.

Author: JesseBTC
Date: 2024-02-22T08:18:45.592Z

There are two discussions around this proposal that need to be had. One is purely subjective and centered around, why combine the to aspects of ERC721 and ERC20 into one contract when they both serve the original purpose of providing fungibility and non fungibility separately. There are clear advantages to this for both NFT projects and the wider industry. One such advantage being, the opportunity to have fractional exposure to the NFT if the price of said non fungible asset is unattainable. People can own a divisible amount of an NFT or scale into ownership of a full token to unlock an NFT.
Another benefit is the game theory dynamics and novel use cases that can come from utilising the core dynamics of DN404 to create novel ways of interacting with both the token and the NFT which have not yet been available to developers. There could be countless opportunities for new innovation with this standard.
But this part of the discussion is purely subjective, some will see value in it and some will not. Neither are wrong it is an independent opinion.
The core part of the discussion that needs to be had is objective. Objectively is the standard being proposed safe, is the codes logic sound, and does it bring any inherent risk to users of this experimental standard. Does it pass the test in terms of code quality and engineering to receive an official ERC title. This is what should be reviewed, without our subjective opinion of if it is valuable. The subjective opinion on NFTs and the usage of ERC721 can also be called into question. Many use cases of ERC721 could quite easily exist with no need for any on chain token representation, for example gated token communities. This is subjective to whether it actually adds value by being on chain or off chain.
Let’s be objective here and focus on the code, the quality of the engineering and the security of the standard and allow experimenters to prove value of the ERC standard being proposed once we accept that it is at least safe for experimentation and further development.

Author: Vectorized
Date: 2024-02-22T09:04:21.834Z

Would re-emphasize that dual nature token pairs are entirely feasible with ERC-20 and ERC-721 alone, with full standard compliance.
The goal of this proposal is to standardize an interface for signalling (like ERC-2981, ERC-5185) and permissionless configuration of ERC-20 to ERC-721 syncing behavior.

Author: I3artwork
Date: 2024-02-22T09:35:05.952Z

Fractionalizing NFTs has benefits for the smaller fish in sea. Inscreased accessibility. People who would normally be prized out can now participate by purchasing a smaller portion of the NFT. This also means people can diversify their NFT portofolio.
Also the big fish can benefit because of the increased liquidity this technology brings with it.

Author: MichaelWinczuk
Date: 2024-02-22T13:02:12.230Z

There are multiple types of traders and enthusiasts in this space. Some trade tokens, Some trade NFTs, some hunt for rares, and DN 404 affords an interesting investment opportunity to everyone. I am curious to see what sort of utilities come from this standard. Cheers to the brilliant minds behind it. Bravo

Author: 0xth0mas
Date: 2024-02-22T23:55:14.269Z

As one of the original contributors to the DN404 implementation, I think it’s important to reiterate what @Vectorized mentioned above: the structure used in DN404 allows the tokens to seamlessly integrate into existing protocols that are currently built for ERC20 or ERC721 with zero security issues or integration changes.
The benefit of an ERC for DN404 is that protocols that want to support specific features - such as knowing the paired ERC20 of the ERC721 or vice-versa and toggling of the skip NFT feature - of DN404 will have a standard interface for handling them.
Enshrining the “skip NFT” concept in the token standard where an account defaults to skipping the NFT mint if it is a contract account and defaults to NOT skipping the NFT mint if it is an EOA, with the account being able to change its default behavior with setSkipNFT allows for better gas efficiency in a more decentralized/ownerless manner when new AMMs, token routers and smart wallets are sending and receiving the ERC20 tokens.

Author: 0xMillz
Date: 2024-02-25T10:40:29.189Z

It used to be that you couldn’t even buy 0.1 shares of Amazon stock if you only had 505 USD in your brokerage account, when the market price for AMZ was $1200/share. This was before Robinhood, et al. But for certain systems, both in Ethereum and the accompanying Universe, 1 exact unit is only equal to 1 exact unit. If I was only born with one hand I can still cast one whole ballot.
Scraping together Bitcoin satoshi after satoshi just to have a wallet that exactly reads 1.00000000 is not uncommon, even though that chain has no concept of exactly that amount being anything special.
The same way one can own a piece of a condo “timeshare” in Aspen (free lunch included). The point is there is this use case for x amounts of fungible widgets, semi-useless alone, but when combined as puzzle pieces in the predetermined standard amount make 1 non-fungible whole.
My first post here, but I’ve read a lot of the history. Fractional NFTs like this have already been inspired, debated, and forgotten- many years ago. Some senior wizards had good perspectives, it’s good to try a simple forum search and give credit where it’s due.

Author: Tsubasa
Date: 2024-02-26T21:57:37.945Z

wow i really like this perspective. nice thought!

Author: fomo-protocol
Date: 2024-03-02T16:54:06.869Z

IMO, ERC20 and ERC721 is already enough. The relationship between them are developers’ decision. We don’t need to standardardized how they would interact with each other.
There could be a lot of ways that they can interact with each other, and we can’t possible included all of them in a ERC nor should we.

Author: xinbenlv
Date: 2024-03-02T19:35:26.922Z

First of all, thanks for submitting a ERC proposal.
The draft LGTM editorial for a status of DRAFT so I merged it.
Technical feedback / question
Q1: choice of bool



 Vectorized:

    event SkipNFTSet(address indexed owner, bool status);


The status is bool, have you thought of using something that’s better than bool,

avoid mistaken implementation, similar to rationale of ERC-165’s choice return value instead of bool they use a 6bytes
allow future expansion. same rationale as ERC-5269: ERC Detection and Discovery choosing the status to be a bytes32 as hash of a string so

That apply to the parameters and return values of

 function setSkipNFT(bool status) external;
function getSkipNFT(address owner) external view returns (bool);

Etc.



 Vectorized:

interface IERC7631Mirror {
    /// @dev Returns the address of the mirror NFT contract.
    /// This method MAY revert or return the zero address
    /// to denote that a base ERC-20 contract has not been linked.
    ///
    /// If a non-zero address is returned, the returned address MUST
    /// implement `IERC7631Base` and its `mirrorERC721()` method MUST
    /// return the address of this contract.
    ///
    /// Once a non-zero address has been returned, this method
    /// MUST NOT revert and the returned value MUST NOT change.
    function baseERC20() external view returns (address);
}



Q2: Do you wanna specify recommented function that sets the addresses of ERC-20 and ERC-721 binding?

Author: Vectorized
Date: 2024-03-02T20:58:11.888Z

I agree that just ERC-20 and ERC-721 alone suffice for the accounting logic.
This ERC is foremost a signalling ERC (similar to ERC-4906). It informs dApps about the link between the two tokens, to aid indexing, and to enhance the experience for end-users. It does not impose any other restrictions on how the two tokens should interact.
We understand that a standard cannot encompass all possible use cases – it’s a careful balance of imposing restrictions and leaving flexibility.
The setSkipNFT and getSkipNFT methods may be omitted, as they are allowed to revert by default. A contract that does not implement these methods in Solidity will essentially revert when called with their function selectors, which is functionally the same as a contract that implements these methods and reverts in them.

Author: Vectorized
Date: 2024-03-02T21:21:43.962Z

The choice of bool is for simplicity. In the case where more complex behavior is needed and can benefit from standardized interpretation, an extension standard can be proposed.


The linking process can use any desired mechanism (e.g. linking in constructor, initializer, or via custom admin-only public methods on the two contracts). The only restriction is that the pairing must be immutable once established (to simplify indexing logic).


I think we can clarify in the rationale on the choice for bool, and why the mechanism for linking the contracts is omitted.

Author: Vectorized
Date: 2024-03-02T21:46:53.513Z

Might be better if we specify that getSkipNFT reverting SHOULD be interpreted by dApps that the setSkipNFT function should not be displayed in the front-end.
I understand that not all implementations will want the skip NFT status to be configurable.
The getSkipNFT and setSkipNFT methods can be left unimplemented in Solidity, which is functionally equivalent to implementing these methods and reverting in them.

Author: xinbenlv
Date: 2024-03-03T05:57:07.289Z

Another question: I am wondering why does it need the skipping methods? Can they be MAY instead of MUST?

Author: Vectorized
Date: 2024-03-03T11:57:53.977Z

The skipping methods MAY be implemented. We will clarify.

Author: alimaomao
Date: 2024-03-11T01:48:13.667Z

is it similar to erc404?

Author: xinbenlv
Date: 2024-03-15T14:23:14.058Z

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

Author: Vectorized
Date: 2024-03-15T19:50:40.724Z

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.

Author: abitofdots
Date: 2024-03-18T02:12:39.837Z

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.

Author: fulldecent
Date: 2024-03-21T16:56:50.771Z

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.

Author: sullof
Date: 2024-03-23T01:16:56.175Z

fulldecent:

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.


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.

Author: abitofdots
Date: 2024-03-24T15:32:14.047Z

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?

Author: Vectorized
Date: 2024-03-24T23:08:54.183Z

Around the ballpark of 500 tokens for DN404.
Depends on your implementation too.

Author: Vectorized
Date: 2024-03-24T23:20:03.807Z

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.

Author: Vectorized
Date: 2024-03-24T23:27:32.363Z

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.

Author: Haiku
Date: 2024-03-29T12:51:43.581Z

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.

Author: fulldecent
Date: 2024-04-02T22:44:25.889Z

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.

Author: Vectorized
Date: 2024-04-03T00:40:46.501Z

The skip NFT methods are optional, but recommended.


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.


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.


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.

Author: sennett-lau
Date: 2024-04-12T04:42:38.871Z

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.