Great question @RWAfan … if we are talking about choosing a standard that will become the interface for implementing a smart contract, it will always have to depend on the project’s use case.
From the top of my mind, I can think of a couple of scenarios:
- When combining other ERC’s logic: There are a ton of scenarios where a combination of two or many token standards is desired. There are lots of fractionalized tokens out there, using a bespoke combination of ERC-711 and ERC-1155, but this ERC proposes a different approach. One that would apply to virtually any standard token interface. For example, check out this discussion about combining multi-assets(ERC-5773) and multi-tokens(ERC-1155). This use-case can be an abstraction of logic from storage. However you want to implement the combination by implementing both interfaces separately or with a combined logic within the same contract, you can probably achieve it. Another example would be in RWA tokenization: you can probably combine the functionalities of ERC-3643 while abstracting a different system for identity verification (other than the required ONCHAINID).
- When versatile metadata is required: There are a bunch of standards and use cases for versatile metadata (i.e. ERC-4906, ERC-4955, ERC-7160, ERC-6662, ERC-3569, ERC-5185… not to mention products like Chainlink’s Dynamic NFTs). By implementing different Metadata logic, Properties can be exposed with different Restrictions, depending on the requirements of each use case.
- When storage shouldn’t be upgradeable but logic should: Keeping the storage within the same contract as the logic is convenient and simplifies the design of most smart contracts sometimes use cases require a common storage layout for implementing a lot of logic across multiple contracts to manage it. This is particularly useful when you know the logic will change over time, but you don’t know how much it will change and just making the contracts “upgradeable” is probably not enough (i.e. when regulatory compliance is mandatory for smart contracts to operate assets).
- When building an enclosed ecosystem: I can imagine a scenario where multiple products coexist by sharing data. Separating the data storage from the implementation enables each use case to have its smart contract logic while tapping into the same data pool. With this, multiple products or companies can grow their businesses by providing services while the users own their ODCs.
But to be fair, this is not a “one standard to rule them all” type of proposal. All implementations of ERC-7208 will most likely require the use of complex smart contracts, which in turn are likely to consume more gas. On top of that, security and privacy considerations have to be taken into account, and not every use case will benefit from the overhead in complexity. If you just need a token for a specific use case, and there is a standard for it, you may be better off using said standard interface.
I think this standard is good for a bunch of scenarios, each one of them with different motivations, and their caveats. As part of the ERC proposal, we are pushing an appendix with some ways in which this ERC can be used in conjunction with other standards. You can read about it here.