How is this ERC different from NFT Bound Accounts?
Maybe this is an answer that helps you a bit:
ERC-7208 (ODC): Aims at universal on-chain data management with mutable, extensible, and interoperable containers (ODCs), suitable for complex tokenization, especially of real-world assets.
NFT Bound Accounts: Focuses on enhancing the security and identity verification of NFTs by binding them to specific accounts, primarily used for digital art, memberships, and tickets.
In essence, ERC-7208 offers a comprehensive framework for on-chain data management with extensive functionalities, while NFT Bound Accounts provide a more targeted solution for securing and verifying NFT ownership.
2 Likes
Sounds really interesting. Itās an ERC721 but with a lot of extra features. Iāll take a look to it.
Thank you for taking an interest @rodaemonic ! Conceptually, each ODC is an ERC721 with extra features (mainly storage and security). The 721 interface is only a requirement for the data container contract. The Property Managers (smart contracts that manage Properties and Restrictions stored within the ODC) can use other interfaces.
Am I correct in asuming that this ERC can be used for keystore contracts? I saw a previous version of this ERC had a reference to Vitalikās article about The Three Transitions.
Iāve read the PRā¦ the DataStorage Library Example at the core of the ODC seems to be hard to swallow. I understand it is not a part of the ERC itselfā¦ more like a component of the reference implementation. Is this correct? Also, can you think of a simpler structure that will enable the implementation of this standard?
1 Like
Hi ā¦.in the TokenRestriction structure, there is a variable ridxCounter. This feels a bit too implementative. If the idea is to have a Restriction ID, may I suggest a renaming of the variable?
1 Like
Why is Wrapping and Fractionalizing not a part of the standard interfaces? I saw them listed as examples of Property Managers, but they seem to be super helpful.
Hey @Ljrr3045 if youāre referring to this article, yes! To be fair, we started working on this abstraction almost a year before Vitalik spoke about the Keystore Contracts, and before ERC-4337 got accepted. This goes to show the future-proofing of the ERC-7208 =) The three transitions speak about
- L2s, which we have deployed our reference implementation on
- Smart Wallet security transition, which we have achieved with brillion.finance
- privacy, recovery, identity and reputationā¦ which is also at the core of the Nexera Protocol
Hey @RWAfan , thanks for checking out the library and the PR. Yes, you are correct on both accounts The DataStorage Library is a hard piece of code, but it is only part of the Reference Implementation (Nexera Protocol).
The motivation for the DSL to be this complicated is that we wanted to have as many features as possible within the Reference Implementation. Therefore, we are releasing a multichain implementation that is based on Diamond Standard (ERC-2535), with several Property Managers (identity snart wallet, compliance, wrapper, fractionalizer, recovery rules, and an Oracle PM for streaming data to the ODC)
There are many ways in which Properties can be implemented, depending on the functional requirements for each specific use-case. We use bytes or bytes32 for Property Keys, so that they are as generic as possibleā¦ but as long as the keys are identifiable by the Property Managers, there is no requirement on them being implemented as our DataStorage Library. To be fair, we have been working on a light implementation of the ODC for minimalistic scenarios, and it only uses a simple structure with a mapping of uint to store Property Data.
Hey @D_Ddefi ! Indeed, Wrapper and Fractionalizer are super helpful for a lot of use cases. However, I donāt see them as being an intrinsic part of the standard interfaces, as there is a chance that not all implementations will have them as a requirement. In other words, we are making them a part of the reference implementation, but that does not mean that they must be a part of the specification. Wdyt? Let me know if you see it differently.
Well written proposal for ERC-7208 (ODC), very clearly structured.
What I find the most interesting aspect of this proposal is itās approach to updating the metadata, this represents a significant advancement in how we interact and can perceive on chain tokenized assets. By allowing smart contracts to interact with richer and more actionable data that is stored within the properties, the utility of these assets is not only enhanced, but also allows to create more complex use cases. In my opinion this could revolutionise the dynamic NFT landscape, because the change in metadata could trigger certain on chain conditions.
Splitting and merging NFTS within this ERC-7208 also opens up a new possability for fractionalized ownership and asset management. It is actually quite logical, like buildings could be legally split and merged again, NFTs should have the same properties. This could have really interesting applications in art, real estate and intellectual property use cases where shared ownership is central.
Well done @galimba and team!
1 Like
Great news 
weāve been accepted as DRAFT proposalā¦ we are going to be implementing your suggestions soon, and hopefully get to IN REVIEW status soon 
1 Like
Am I correct in assuming that variables named mtid refers to MetaNFT, and that this is an old naming convention that refers to the ODCs?
Could someone elaborate on how data or Properties within ERC-7208 can expose multiple interfaces? Iām interested in understanding the technical mechanisms behind this feature and its implications for interoperability among different token standards
I was reading into the standard interfaces and there is an ODC function called merge() for categories and properties from one ODC token to another. Can you explain how to address merging if Properties have conflicting information?
Correct, this is an outdated naming convention. The On-chain Data Containers used to be called MetaNFTs on an earlier implementation. Thatās why youāll see some variables named mtid. Weāre in the process of updating them to ouid as in "ODC Unique Identifier`
Hey @FiremanMal, thanks for taking an interest in this standard. The main motivation behind ERC-7208 is to smoothen the interactions between other standards. As there are many standards (and the number of standards is expected to grow in the future), it is up to each implementation to address the possibilities of merging conflicts within Property (and Restrictions) data.
For example: Imagine the community keeps up with this trend of shallow ERC proposals that only target a specific business, and are pushed by marketing rather than the motivation to improve the ecosystem. In the past few weeks, the community has witnessed a huge marketing campaign pushing for a so-called āERC-404ā, intended to ācombine ERC-20 and ERC-721 in a revolutionary wayā. There are already several other ERC proposals designed for NFTs that build upon ERC-721, each introducing functionalities for specific business needs (such as multi-tokens, semi-fungible, rentable assets, royalties, fractional ownership, hierarchical systems, and ownership control) but none of those are natively interoperable with each other. Implementing a specific mix of these functionalities will require a unique control mechanism and, as a result, a distinct implementation for each combination. To ensure that any standard can be made interoperable with another standard safely and sustainably, the abstraction offered by ERC-7208 is necessary for managing asset storage and logic effectively.
TL;DR It is up to each Property Manager to define the mechanisms for handling the collisions, depending on the Properties they are managing.
Yesā¦ one of the motivations is to abstract the logic away from the underlying asset while being able to support multiple interfaces (on the same asset). The basic mechanism is not new (it is a delegateCall or similar), however, the ERC-7208 standard provides the structure for how other standards become interoperable.
Let me give you an example:
In the context of utility use cases for NFTs, ERC-4907 represents a rentable NFT and ERC-2981 represents a royalty NFT. Conceptually, both are using the same underlying asset: an ERC-721. But if you implement them as separate contracts, each of them has its storage, and therefore its own independent underlying NFT implementation.
If you want to have a rentable NFT that also pays royalties, youād probably implement both ERC-4907 and ERC-2981 within the same smart contract (i.e. contract superNFT is ERC2981, ERC4907{...)
This way, you have the same storage identifying the underlying asset (i.e. the mapping of uuid to address representing who is the owner of each NFT), and the resulting contract must then manage the logic on how to handle renting and paying royalties concurrently.
With ERC-7208 you can have the storage of the underlying asset (as a Property within the ODC) separated from the logic that implements the interfaces (as Property Manager contracts)
Youāre 100% correct, we are taking this feedback into account and we will be updating the interface accordingly before moving to Final.