Title: ERC_7208__On_chain_Data_Container
Category: ERCs

Author: galimba
Date: 2023-06-21T18:25:59.473Z

UPDATE January 2025 -
The ERC-7208 is pushing to FINAL
The audit report is here
An example implementation can be found here, where an ERC-1155 and many ERC-20 share storage
Other implementations and tools will be posted here, thanks to the Nexera Network
Special thanks to Omniscia for their contributions.
/******************* About This ERC ********************************/
Hello Magicians,
Today we are excited to introduce ERC-7208, a set of interfaces that we call the On-Chain Adapters:

DataIndex (DI) → indexes information and approvals of DataManagers to DataPoints through DataObjects
DataManager (DM) → interfaces with user, implements business logic or “high-level” data management
DataObject (DO) → logic implementing "low-level data storage management
DataPoint (DP) → indexed low-level data pointer (bytes32)
DataPoint Registry (DPR) → defines a space of data point compatibility/access management

overview744×450 35.3 KB
Abstract
This ERC defines a series of interfaces for the abstraction of storage of on-chain data by implementing the logic functions that govern such data on independent smart contracts. “On-chain Data Containers” (ODCs) refer to the separation and indexing of data storage away from data management. We propose that on-chain data can be abstracted and stored in smart contracts called “Data Objects” (DO), which answer to external data indexing mechanisms named “Data Points” (DP). This data can be accessed and modified by implementing (one or many) separate smart contracts identified as “Data Managers” (DM). We introduce two mechanisms for access management: first, through a “Data Index” (DI) implementation, the “Data Managers” (DM) can be gated from accessing “Data Objects” (DO); second, a “Data Point Registry” (DPR) implementation manages the issuance of “Data Points” (DP). Lastly, we introduce the concept of data portability (horizontal data mobility) between implementations of “Data Index” (DI), enabling massive updates to the logic without affecting the underlying data storage.
Motivation
As the Ethereum ecosystem grows, so does the demand for on-chain functionalities. The market encourages a desire for broader adoption through more complex systems and there is a constant need for improved efficiency. We have seen times when an explosion of new standard token proposals was solely driven by market hype. While ultimately each standard serves its purpose, most of them require more flexibility to manage interoperability with other standards. A standard adapter mechanism is needed to enhance interoperability by driving the interactions between assets issued under different ERCs.
Without such mechanisms, most projects have implemented bespoke solutions for interoperability. This is an inefficient approach and leads to a fragmented ecosystem. We recognize there is no “one size fits all” solution to solve the standardization and interoperability challenges. Most assets - Fungible, Non-Fungible, Digital Twins, Real-world Assets, DePin, etc - have multiple mechanisms for representing them as on-chain tokens through the use of different standard interfaces and the diversity of standards spurs innovation.
However, for these assets to be exchanged, traded, or otherwise interacted with, protocols must implement compatibility with the relevant interfaces to access and modify on-chain data. This is especially challenging when considering the previously mentioned bespoke solutions for interoperability. Additionally, the immutability of smart contracts complicates the ability of already deployed protocols to adapt to new tokenization standards, which is critical for future-proofing implementations. A collaborative effort must be made to enable interaction between assets tokenized under different standards. The current ERC provides the tools for developing such on-chain adapters.
We aim to abstract the on-chain data handling from the logical implementation, exposing the underlying data independently of the ERC interface. We propose a series of interfaces for storing and accessing data on-chain in contracts called “Data Objects” (DO), grouping the underlying assets as generic “Data Points” (DP) that may be associated with multiple interoperable and even concurrent “Data Manager” (DM) contracts. This proposal is designed to work by coexisting with previous and future token standards, providing a flexible, efficient, and coherent mechanism to manage asset interoperability.


Data Abstraction: We propose a standardized interface for enabling developers to separate the data storage code from the underlying token utility logic, reducing the need for supporting and implementing multiple inherited -and often clashing- interfaces to achieve asset compatibility. The data (and therefore the assets) can be stored independently of the logic that governs such data.


Standard Neutrality: A neutral approach must enable the underlying data of any tokenized asset to transition seamlessly between different token standards. This will significantly improve interoperability among other standards, reducing fragmentation in the landscape. Our proposal aims to separate the storage of data representing an underlying asset from the standard interface used for representing the token.


Consistent Interface: A uniform interface of primitive functions abstracts the data storage from the use case, irrespective of the underlying token’s standard or the interface exposing such data. Data and metadata can be stored on-chain, and exposed through the same primitives.


Data Portability: We provide a mechanism for the Horizontal Mobility of data between implementations of this standard, incentivizing the implementation of interoperable solutions and standard adapters.


Terms


Data Point: A uniquely identifiable reference to an on-chain data structure stored within one or many Data Objects and managed by one or many Data Managers. Data Points are issued by a Data Point Registry.


Data Object: A Smart Contract implementing the low-level storage management of information indexed through Data Points.


Data Manager: One or many Smart Contracts implementing the high-level logic and end-user interfaces for managing Data Objects.


Data Point Registry: One or many Smart Contracts used for managing the issuance of Data Points. Additionally, a Data Point Registry defines a space of compatible or interoperable Data Points.


Data Index: One or many Smart Contracts used for managing the access of Data Managers to Data Objects.
overview-tec1374×731 95.2 KB

Author: Ridgestarr
Date: 2023-12-17T13:45:19.899Z

BOSS moves. Confidence in this team only growing. No mercy.

Author: Howee
Date: 2023-12-17T15:23:14.792Z

Great breakdown and technical overview of the overall vision of the AllianceBlock project, very exciting to see it at this stage

Author: D_Ddefi
Date: 2023-12-17T18:12:39.069Z

Amazing work the #NXRA team is doing!

Author: kamelion
Date: 2023-12-17T18:35:43.764Z

Man! this provides a comprehensive and insightful overview of ERC-7208 , particularly highlighting the innovative approach of On-Chain Data Containers (ODC) in enhancing data management and interoperability across various token standards. I think tht its impressive how this delves into the technicalities while also considering practical use cases like the tokenization of real-world assets. RWA needs this in my opinion.
I’m curious about the potential impact of ERC-7208 on the broader Ethereum ecosystem. how might the introduction of ERC-7208 and its On-Chain Data Containers influence the development and deployment of decentralized applications (DApps), particularly in terms of scalability and user experience?

Author: Howee
Date: 2023-12-17T19:00:04.004Z

…a comprehensive and well-thought-out proposal! The concept of On-Chain Data Containers (ODCs) and ERC-7208’s focus on standardization and interoperability make a lot of sense, especially in a rapidly evolving Ethereum ecosystem with a constant influx of ERC proposals.
I appreciate the attention to detail, especially the abstraction of logic from storage, the versatility of Properties, and the role of Property Managers. The use case examples, like the luxury car rental scenario, add practical context to how ERC-7208 can streamline complex interactions.
The approach to expose Properties as procedurally generated Metadata JSON on-chain is a smart move, addressing the limitation of off-chain metadata storage. The variety of Property Managers, such as Identity and Rules Engine, showcase the flexibility and extensibility of the proposed standard.
…examples of real-world asset tokenisation using ODCs and the default implementation with added features demonstrate a thoughtful consideration for efficiency, scalability, and compliance. Overall, ERC-7208 seems like a promising step towards a more cohesive and adaptable on-chain data management solution. Kudos to the team!

Author: Hairoun
Date: 2023-12-17T19:14:53.467Z

Love how projects keep innovating, the RWAs sector is critical to DeFi.

Author: Leon_S
Date: 2023-12-17T19:43:52.948Z

Very informative read on ODC’s. Thanks for giving insight on the topic. Love to see this as the new standard!

Author: farzad
Date: 2023-12-17T20:40:27.830Z

Unlocking seamless interoperability, abstraction of logic from storage, and empowering dynamic tokenization scenarios. Innovation in the Ethereum ecosystem always exciting

Author: Hunty
Date: 2023-12-17T21:47:59.954Z

A great read, thanks for the informative information.

Author: jaws
Date: 2023-12-17T22:16:04.698Z

I too think that this is not necessarily restricted to real-world asset tokenization. it could enable some wider-reaching applications.
A good example would be digital asset tokenization in on-chain gaming applications. Think of a character or avatar as an ODC with the PMs managing all the various abilities, powers, or assets of that avatar. I also wonder if the generated JSON metadata could be harnessed to render certain assets in digital space and thus removing the need to store assets in centralized cloud storage.

Author: Nellykhan
Date: 2023-12-17T23:59:36.353Z

This is very smart. No mercy!

Author: AndyVi
Date: 2023-12-18T09:30:54.799Z

ODC can replace a wallets of all sorts eventually, can it?

Author: RWAfan
Date: 2023-12-18T09:33:52.434Z

As someone who talks with a lot of companies that are looking into RWA tokenization, I can safely say that ODCs are much needed and will open op a wide range of new business opportunities to the Ethereum community and beyond. From a professional and business perspective, I see this as the next much needed evolution of NFTs. I have explored ODCs with businesses from different industries, from creative businesses looking into creative NFT use cases, all the way to dynamic licensing companies, real-estate and carbon credit projects.
All these businesses have one thing in common, they want this!
As I am personally very biased, in favour of this proposal. I would also like to hear from the community what potential ‘drawbacks’ could be. In what scenario would you prefer a different standard instead of this one? And when would you use ERC-7208?

Author: AndyVi
Date: 2023-12-18T09:35:16.156Z

How does ERC-7208 ensure compatibility and interoperability with existing ERC standards, particularly those that are widely adopted in the Ethereum ecosystem? Can you provide examples of how ERC-7208 would enhance or integrate with popular standards like ERC-20 or ERC-721?

Author: AndyVi
Date: 2023-12-18T09:35:54.509Z

Could you elaborate on specific real-world use cases where ERC-7208 would be particularly advantageous? How does this standard address the challenges faced in these scenarios more effectively than existing solutions?

Author: galimba
Date: 2023-12-18T09:54:46.078Z

Exactly like Jaws says: the concept of the Metadata being a composition of on-chain Properties provides not just backwards compatibility with previous NFT use cases where you would just store the uri as a string Property, but also for new use cases that require the Metadata to be updated “in real time”, like in videogames

Author: borovvvviec
Date: 2023-12-18T09:57:56.745Z

I have some Scalability Concerns… How does ERC-7208 plan to manage scalability challenges associated with storing large volumes of mutable data on-chain, especially in light of Ethereum’s current limitations in terms of block size and gas fees?

Author: Mike1
Date: 2023-12-18T10:03:17.479Z

How does in ERC-7208 propose the efficient on-chain data retrieval, especially when dealing with complex data structures and large data sets?

Author: galimba
Date: 2023-12-18T10:09:41.302Z

AndyVi:

How does ERC-7208 ensure compatibility and interoperability with existing ERC standards, particularly those that are widely adopted in the Ethereum ecosystem? Can you provide examples of how ERC-7208 would enhance or integrate with popular standards like ERC-20 or ERC-721?


Hey Andy! Thanks for the question… Most tokens that follow a standard like the ones you mention have the storage integrated within the same interface as the functions that govern the logic for how to manage that storage. We see this as a limitation, where the logic and storage are bound to one another by the standard itself.
This ERC standardizes the interfaces that abstract the implementation from the storage. To give you a clear example:
Let’s say you have 100 DAI on your account. This value is stored on a mapping within the ERC-20 contract, and you modify or access it by using the other functions listed on the standard (transfer(), balanceOf(), etc)
Now, in this scenario the assets are represented by a uint number, associated with your account. Your account has 100 DAI, whenever this storage says you do.
What we propose, is that the functions that modify this storage can be abstracted away from the data. For instance, you keep the storage on one contract and apply the logic on a different contract.
Back to the question: how does this work in ERC-7208? You can have Properties with storage values within the ODC contract, and you can have Property Manager contracts that implement the logic. Why is this a desired thing? Because by separating the logic, you get more versatility, at the cost of a delegate or delegateCall. Example of this would be: we can store a Property with value uint= 100 for your address, and then this Property is managed by two different Property Managers contracts, each of them implemented with a different interface. i.e. ERC-1155 and ERC-20. This is a theoretical scenario, of course… but it would mean that you both simultaneously own an NFT (1155) and 100 of an ERC20 token. Each Property Manager works as its own token contract, it just delegates the storage to the ODC.
Hope this makes things clear(er)

Author: CryptoBeast
Date: 2023-12-18T10:52:59.706Z

This is really great, especially in the RWA sector. Good work guys

Author: galimba
Date: 2023-12-18T10:57:51.476Z

borovvvviec:

I have some Scalability Concerns… How does ERC-7208 plan to manage scalability challenges associated with storing large volumes of mutable data on-chain, especially in light of Ethereum’s current limitations in terms of block size and gas fees?


This is a good question… one that we’ve asked ourselves many times. I would usually consider this would be a concern for the implementation rather than the Standard interface. It is a matter of HOW you implement it, instead of the WHAT interface you’re implementing. We should not limit the implementation and we should strive to be agnostic from it while proposing a Standard Interface. Some use cases will require more data to be stored on-chain than others, and the proposal must consider all possible implementations.
If you check what’s being done in use cases in particular, you can check out Chainlink’s Dynamic NFTs, the team has implemented off-chain storage by keeping on-chain references. ERC-7208 can easily accommodate the use case of Dynamic NFTs, and then empower it with interoperability with other standards. Another example would be EIP-4883 (for SVG metadata)… this can also be implemented with the ERC-7208, and in fact, both solutions can coexist within this standard. At the end of the day, the standard interface should not limit the implementation. It is up to each developer to define which information should go on-chain and which one should not. ERC-7208 is here just to enable better standardization in the way we make the on-chain information interoperable across standards.

Author: galimba
Date: 2023-12-18T11:12:41.293Z

Mike1:

How does in ERC-7208 propose the efficient on-chain data retrieval, especially when dealing with complex data structures and large data sets?


Same as the question above… the standard only proposes a series of interfaces. As such, we cannot limit developers to a single concept of efficiency. Standards must be abstractions that developers use to guide their implementations.
However, we do have a default implementation and for that, we do have to consider efficiency in the context of that implementation. What we did there was to sometimes use local storage within the Property Managers themselves rather than “pushing data” to the ODC’s Property.
To give you an example: lets say we have an ODC representation of your portfolio of assets. Some of them could be ETH, DAI, USDT… maybe some NFTs are owned by the ODC as well. You may want different Property Managers to manage different asset classes or different categories, as different assets require interacting with different smart contract interfaces.
Another example: if you have a Property Manager implementing the ERC-721 interface (a regular NFT), you may want to store the metadata within the 721 Property Manager itself (as a link to IPFS), or you may want to delegate the storage to a Property within the ODC. In the first case, the data storage would be straightforward from the contract implementing the 721 interfaces, while in the second case, it is likely that the same interface is reading a view function from the ODC.
The point is that the decision of what architecture to implement should be up to you.
Hope that makes things clear(er)

Author: thiesku
Date: 2023-12-18T12:46:56.916Z

Given the mutable nature of on-chain data in ERC-7208, what are the proposed security measures and fraud detection mechanisms to prevent malicious activities like data tampering or unauthorized access?

Author: cratus
Date: 2023-12-18T12:53:43.495Z

This is a great breakdown. I do have a question though - what governance models are you suggesting for managing Property Managers in ERC-7208 to ensure decentralized control and prevent central points of failure or manipulation? Keen to know your thoughts on this

Author: Jocx
Date: 2023-12-18T13:00:48.808Z

What levels of customization and extensibility does ERC-7208 offer to developers, especially when creating complex dApps that require bespoke data structures and management processes? Thanks!

Author: Berbex
Date: 2023-12-18T13:06:23.143Z

What are the challenges in implementing ERC-7208, particularly in terms of backward compatibility and integration with existing systems?

Author: kpachhai
Date: 2023-12-18T13:14:15.457Z

This is great especially when it comes to Identity Property Manager where credentials are stored within ODCs. I think the use of signatures verifications rooted in zero-knowledge proofs and verifiable credentials is amazing because this approach allows for robust identity management while also maintaining the privacy of personally identifiable information. I did have a question though:
How does the Identity Property Manager within ERC-7208 ensure interoperability with various self-sovereign identity standards and platforms? Is there a unified protocol or set of guidelines that different blockchain networks and identity solutions must adhere to for seamless integration with the IPM?

Author: galimba
Date: 2023-12-18T13:18:25.317Z

thiesku:

Given the mutable nature of on-chain data in ERC-7208, what are the proposed security measures and fraud detection mechanisms to prevent malicious activities like data tampering or unauthorized access?


Hey thiesku… what do you mean “fraud detection”?

If you mean in terms of who has access to modifying the data, this is exactly the role Access Control plays with Property Managers. These smart contracts are the only ones that are allowed to modify Properties.
If you mean “fraud” in the traditional sense, as in money laundering and other illicit activities, then it will depend on the implementation of particular rules, tailored to the regulations that are required for each use case.

To be clear, this ERC proposes a series of standard interfaces that can be used to develop interoperable smart contracts. Access to each smart contract’s storage is managed in different ways. Some SCs implement role-based access control, others based on signatures, and others based on Verifiable Credentials. The specifics of each implementation should not be derived from the interfaces drafted here.
Hope that clears out the confusion

Author: Ljrr3045
Date: 2023-12-18T13:34:22.544Z

We jut saw that Ethereum community adopted the ERC-3643 for compliant RWA tokenisation (https://cointelegraph.com/news/ethereum-community-adopts-erc-3643-standard-compliant-asset-tokenization). Is ERC-7208 doing the same? if not, what are the key difference and how it is interoperable with this asset? Thank you in advance

Author: cryptonew
Date: 2023-12-18T13:36:19.735Z

You mentioned Hooks a couple of times. How do these differ from Uniswap V4 hooks?

Author: Howee
Date: 2023-12-18T14:49:04.748Z

You said the core concept of ERC-7208 is abstracting logic from storage, allowing a storage variable to represent multiple things concurrently based on the implemented interpretation​​. Can you provide a detailed example where this abstraction significantly improves efficiency or opens up new possibilities in asset management and smart contract development? Why would we want to separate the storage from the logic in different standards?

Author: RWAfan
Date: 2023-12-18T14:54:17.571Z

In a complex use case like tokenizing a real estate portfolio all together, where multiple houses or apartments, each with unique characteristics, need to be represented on-chain… How does ERC-7208 facilitate this representation more effectively compared to existing standards? In other words, why do we need this standard if there are others that can be used for the tokenization?

Author: galimba
Date: 2023-12-18T14:56:57.641Z

cratus:

This is a great breakdown. I do have a question though - what governance models are you suggesting for managing Property Managers in ERC-7208 to ensure decentralized control and prevent central points of failure or manipulation? Keen to know your thoughts on this


Good question… this will depend on the specific implementation of the ODC. This is not a decision to be considered as part of the ERC, as it is not a part of any of the standard interfaces presented.
The first solution that comes to mind is to implement a Registry of Property Managers organized in Categories. Each Category has access to specific Properties indexed by property_id within the ODC. The Registry can be managed by a DAO, which gets to vote and govern over the Property Managers’ access to information.

Author: galimba
Date: 2023-12-18T15:34:25.887Z

Jocx:

What levels of customization and extensibility does ERC-7208 offer to developers, especially when creating complex dApps that require bespoke data structures and management processes? Thanks!


Hey Jocx, thanks for the question… the interfaces presented allow developers to use all previous data structures and standard interfaces regardless of their implementation. If you check the DataStorage Library we are proposing as the core storage for the ODC, we have:

keyValueData for bytes32 key-value pairs,
keyBytesData for storing bytes,
keySetData for sets of bytes32 values,
keyMapData for mappings of bytes32 => bytes32 values.

With these, you can virtually represent anything you may require. Remember, the ODC is mainly storing crude data, and it is up to Property Managers to give meaning to it by implementing the interfaces, functions, and logic to manage that data.
This is because we don’t just want to have backward compatibility with previous ERC standards, we want to also be future-proof and enable current data to be exposed to the new standards that are yet to be conceived by the community.

Author: galimba
Date: 2023-12-18T15:45:42.702Z

Berbex:

What are the challenges in implementing ERC-7208, particularly in terms of backward compatibility and integration with existing systems? 


The default implementation will be Open Sourced in 2024… and we’ll soon share the documentation for it. In terms of backward compatibility, you don’t need to worry, we’re not breaking anything. This is just an ERC proposing a series of standard interfaces.
We do, however, provide a cherrypicked list of possible points of contact between this proposal and other standards, and how these integrations can be achieved:

ERC-1400 (Security Token Standard): In aggregate provides a suite of standard interfaces for issuing/redeeming security tokens, managing their ownership and transfer restrictions, and providing transparency to token holders on how different subsets of their token balance behave with respect to transfer restrictions, rights and obligations. ODCs can enhance ERC-1400 by offering more dynamic and flexible data management. ODCs allow for the storage and modification of properties related to security tokens, such as compliance information or ownership details. This integration could lead to more efficient and transparent security token offerings. Additionally, hooks and triggers can be implemented within the logic of specific use cases so that compliance with regulatory frameworks is achieved automatically.
EIP-2309 (Consecutive batch minting): ODCs are compatible with EIP-2309, allowing for the batch minting process to be enriched with additional data. ODCs could store information related to each batch, such as metadata or batch-specific attributes, without disrupting the minting process.
EIP-2615 (Swap Orders): ODCs can work alongside EIP-2615, enhancing swap orders with additional data capabilities. Properties within ODCs can store terms, conditions, or other relevant data for swap orders, facilitating more complex and informed swap transactions. Additionally, Swap Orders can be bundled together by Wrapper Property Manager, generating bundles of orders to be interacted with together.
EIP-2981 (Royalties): ODCs can complement EIP-2981 as a Property Manager by providing a flexible way to handle royalties. Properties in ODCs can store and manage royalty information dynamically within the data and metadata, allowing for more complex royalty structures that can change over time or based on certain conditions.
ERC-3643 (Permissioned Tokens): ERC-3643 proposal defines Security Token interface based on ERC-20 token standard with additional requirements for the sender and receiver of the token to be approved by the token issuer. This interface relies on the OnchainID system to provide Identity information, process KYC and other credentials, providing that data on-chain for token holders for minting, burning, and recovery of assets. Compatibility with this interface can be implemented as an ODC Property Manager, with the added benefit of a more versatile on-chain identity management derived from alternative Property Managers. Implementing ERC-3643 tokens as Property Managers could lead to more robust permissioned tokens. ODC Properties can store and manage permissions, enhancing the control and flexibility of permissioned tokens.
ERC-4337 (Account Abstraction): ODCs can provide a standardized method to store and manage the complex data structures required by abstracted accounts. This can include user preferences, access control lists, recovery options, and other customizable account features. The mutable states of abstracted accounts can be efficiently handled using ODCs. This, in turn, improves the adaptability and security of abstracted accounts.
EIP-4626 (Tokenized Vaults): Tokenized Vaults inherit from ERC-20 and ERC-2612 for approvals via EIP-712 secp256k1 signatures. ODCs can enhance EIP-4626 by providing a more dynamic data layer for tokenized vaults. Properties in ODCs can store information about the assets in the vault, conditions for access, or other relevant data, enabling more nuanced interactions with tokenized vaults.
ERC-4885 (Fractional Ownership): ODCs can improve ERC-4885 Fractional Ownership by providing a standardized way to manage and track metadata related to the life-cycle of the tokens. ODC Properties can store details about each fractional owner and their ownership percentage, making the management of fractional ownership more efficient, versatile, and transparent.
ERC-4886 (Proxy Ownership Register): Combining the security features of ERC-4886 with the data management capabilities of ERC-7208 could open up new use cases by working together to provide a more comprehensive solution for user security and experience. For example, the proxy address in ERC-4886 could be used to interact with various dApps while maintaining the user’s settings and preferences stored in an ERC-7208 ODC. This synergy allows users to have a secure, consistent, and personalized experience across the Ethereum ecosystem. Moreover, ERC-4886 addresses the issue of user confidence when interacting with smart contracts, as it separates the interaction address from the asset storage address. When combined with ERC-7208, it can ensure that users feel safe interacting with various applications, knowing that their settings are stored securely in an ODC and their assets are safe in a different address.
ERC-4907 (Shared Ownership): The integration of ERC-4907 as a Property Manager with ERC-7208 ODC storage can enhance the rental experience by allowing for additional rental-related data directly on-chain, such as rental terms, user permissions, and other customizable settings which would be self-contained within Properties and therefore automatically updated as metadata. ERC-4907’s rental mechanism complements ERC-7208’s ability to manage mutable on-chain data. By combining these two, NFTs can not only be rented out for specific periods but also have their properties or states dynamically managed and updated during the rental period using ODCs. This combination enhances security and compliance in NFT transactions, particularly for Real World Asset Tokenization. Rental agreements, regulatory compliance, intellectual property and user rights can be embedded within ODCs to ensure that the NFT usage adheres to predefined rules.
EIP-5050 (Interactive NFTs): The integration of ERC-7208 with ERC-5050 could potentially enable new forms of interactive applications, where the data stored via ODC can be utilized in interactive NFT environments governed by either native ERC-5050 or a Property Manager implementation of ERC-5050. This could open up innovative use cases, especially in areas like gaming, digital art, and decentralized identity, where the interplay of secure data storage and interactive token functionalities is crucial.
EIP-5095 (Principal Tokens): An ERC-5095 Property Manager implementation could potentially be used to represent specific financial states or obligations as part of a broader data container structure. This way, ERC-5095 tokens could be part of a larger ODC structure, representing a financial component within a multi-faceted on-chain agreement or asset. Compliance, Identity, and predefined rules can be included as part of the logic once it is abstracted away from the storage, which is of particular interest for use cases referent to Realt World Asset tokenization.
EIP-5185 (Metadata Upgradeability): ODCs align well with EIP-5185’s focus on metadata upgradeability. Properties in ODCs can be used to store and update metadata, allowing for more flexible and dynamic metadata management for tokens. However, the main benefit for implementing EIP-5185 as a Property Manager is the access to dynamically metadata upgradeability by tapping into the stored data within the ODC.
EIP-5505 (Asset-Backed NFTs): The Wrapper and Fractionalizer Property Managers within ERC-7208 ODCs can be used to ensure that the fractionalization adheres to relevant regulations and custom rules, providing a compliant and flexible framework for ERC-5505 tokens, if they are implemented as ODCs.
EIP-5560 (Redeemable NFTs): ERC-5560 and ERC-7208 complement each other’s capability to tokenize real-world assets. ODCs can be used to manage the data and rules surrounding the redemption process of a physical asset represented by an NFT, including tracking the redemption status, ownership history, and other relevant metadata of the tokenized assets. By leveraging both standards together, digital tokens can not only represent ownership of physical assets but also provide a standardized and regulated mechanism for their redemption.
EIP-5633 (Composable Soulbound NFTs): ERC-7208 ODCs can be utilized to manage the additional data and rules associated with ERC-5633 soulbound tokens, such as identity management, access and usage rights, and specific account associations.
ERC-6960 (Dual Layer Token Standard): By implementing ERC-6960 as an ODC, the two-level classification system complements ERC-7208’s focus on real-world asset tokenization. The mainId and `subId`` structure of ERC-6960 can be utilized to represent various layers of ownership and characteristics of a real-world asset within an ODC framework, providing more nuanced control and representation of assets. This synergy can enable more sophisticated management and fractionalization of assets, adhering to regulatory frameworks and custom management rules.
ERC-7540 (Asynchronous ERC-4626 Tokenized Vaults): ERC-7540 vaults’s are focused on asynchronous deposit and redemption. Integrating ERC-7540, either by Wrapping or by Property Manager, will complement ERC-7208’s ODCs and facilitate more complex financial products. Complex DeFi products like undercollateralized loans, insurance products, or tokenized stocks often require operations to be handled in a non-instantaneous manner. However, the nature of these products requires adhering to regulatory compliance and identity management solutions. This can easily be achieved by integrating ODC’s Identity Property Managers.

Author: Jocx
Date: 2023-12-18T16:28:40.333Z

Thanks for the prompt reply, also I am curious how does the Fractionalizer Property Manager in ERC-7208 manage the governance aspects of fractionalized assets, especially in scenarios where these assets are governed by complex legal and operational frameworks? Thank you!

Author: galimba
Date: 2023-12-18T18:02:36.229Z

kpachhai:

How does the Identity Property Manager within ERC-7208 ensure interoperability with various self-sovereign identity standards and platforms? Is there a unified protocol or set of guidelines that different blockchain networks and identity solutions must adhere to for seamless integration with the IPM?


In the current version of the ERC proposal draft, the IPM is referenced as an example implementation of a Property Manager. We consider that it does not necessarily have to become a part of this standardization of interfaces. That is to say, there are many identity management interfaces, and it would be hard to abstract all of them in such a way that the resulting interface is generalized enough to cover them and specific enough to work in tandem with the other interfaces within this standard.
That being said, we do have an implementation of IPM included in our default implementation of ERC-7208. This implementation supports quite a lot of identity models and rules. To achieve it it uses internal storage, like:
struct RuleData {
        IRules.AccessRule[] rules; //array of all Rules
        mapping(bytes32 => uint256) operations; //operations => rules
        mapping(uint256 => uint256) ruleUsageCounters; //how many (other) rules implement this rule
    }

where rules have these structures:
struct AccessIdentity {
        address verifier;
        bytes32 id;
    }

struct AccessRule {
        uint256 required;
        AccessIdentity[] identities;
    }

These are the type of Identity management structures that are being used in https://brillion.finance but, once again, 1) this is an implementation decision and there is no obligation to follow these structures, and 2) Identity standardization is not a part of this ERC draft.

Author: galimba
Date: 2023-12-18T18:11:13.690Z

cryptonew:

You mentioned Hooks a couple of times. How do these differ from Uniswap V4 hooks?


If we consider the account’s representation by its activity rather than an address, then with the ODC a user can theoretically (depending upon the implementation) manage their hooks, their Properties, and their on-chain identity information, rather than just managing their signature. In this way, conceptually, the ODC is a mechanism for account abstraction.
Our default implementation of ERC-7208 works with internal and external hooks, but unlike UniV4, these can be programmed with a broader spectrum of rules and triggers. At its core, the ODC is about separating the data storage from the implementation logic.
To give you an exact example of how this is useful: A while back, we developed a UniV4 hook that implements an Impermanent Loss Delta Hedging strategy. Parallel to this, we have developed an on-chain compliance rule engine for NexeraID.
By combining this ERC’s interfaces, hooks can be developed to comply with regulations depending on the location. The assets are managed by a contract (with its custom standard interface), the rules by another (with a different interface, implementation, and requirements based on jurisdiction), and the ERC-7208 acts as the layer that brings them together.
Furthermore, the ODC internal hooks system can trigger calls to multiple other UniV4 hooks… and so we have also developed such hooks to bundle multiple actions (protocol interactions) together within the same transaction (i.e. deposit liquidity, borrow, arbitrage, claim, withdraw are bundled into the same transaction).

Author: galimba
Date: 2023-12-18T18:19:06.985Z

Howee:

You said the core concept of ERC-7208 is abstracting logic from storage, allowing a storage variable to represent multiple things concurrently based on the implemented interpretation​​. Can you provide a detailed example where this abstraction significantly improves efficiency or opens up new possibilities in asset management and smart contract development? Why would we want to separate the storage from the logic in different standards?


I believe these two previous replies address the question:



ERC-7208: On-chain Data Container ERCs


    Hey Andy! Thanks for the question… Most tokens that follow a standard like the ones you mention have the storage integrated within the same interface as the functions that govern the logic for how to manage that storage. We see this as a limitation, where the logic and storage are bound to one another by the standard itself. 
This ERC standardizes the interfaces that abstract the implementation from the storage. To give you a clear example: 
Let’s say you have 100 DAI on your account. This valu…
  





ERC-7208: On-chain Data Container ERCs


    Same as the question above… the standard only proposes a series of interfaces. As such, we cannot limit developers to a single concept of efficiency. Standards must be abstractions that developers use to guide their implementations. 
However, we do have a default implementation and for that, we do have to consider efficiency in the context of that implementation. What we did there was to sometimes use local storage within the Property Managers themselves rather than “pushing data” to the ODC’s …
  

Let me know if I can help you address any specifics.

Author: SamWilsn
Date: 2023-12-18T18:39:28.040Z

Hey! Couple of non-editorial related comments. Note that I haven’t read the rest of this discussion thread, so I apologize if these have already been discussed.

Should there be events emitted when properties are modified?
I’d recommend using the ERC-721 naming convention (eg. propertiesOf instead of getAllProperties.)
You may want to add support for ERC-165 and include the interface id.

Author: galimba
Date: 2023-12-18T18:47:18.384Z

RWAfan:

In a complex use case like tokenizing a real estate portfolio all together, where multiple houses or apartments, each with unique characteristics, need to be represented on-chain… How does ERC-7208 facilitate this representation more effectively compared to existing standards? In other words, why do we need this standard if there are others that can be used for the tokenization?


In the theoretical scenario, you are mentioning tokenizing properties with multiple diverse characteristics. Of course, you can apply multiple standards and develop smart contracts tailored to the specific use case of your choice.
The point of the standard interfaces is to keep a cohesive ecosystem. So, similar implementations implement a set of standard functions that enable them to work together, simplify the development of off-chain services, and facilitate maintenance.
ERC-7208 can help by providing an abstraction of the stored value from the logic of the implementation. This helps drive interoperability between standards, of course, but it also means that if at some point you want your assets to change from being ERC-721 to being ERC-4907 (rentable NFTs), you just need to implement a different Property Manager Interface and no migration of storage is required.

Author: galimba
Date: 2023-12-18T19:27:00.167Z

Hey Sam! Thanks for taking the time and contributing.



 SamWilsn:

Should there be events emitted when properties are modified?


Yes! This is correct. We will add events to the interface. Not just for Properties, but also Restrictions modifications.



 SamWilsn:

I’d recommend using the ERC-721 naming convention (eg. propertiesOf instead of getAllProperties.)


This is also a great idea. We will modify the interfaces to support this naming convention.



 SamWilsn:

You may want to add support for ERC-165 and include the interface id.


Do you mean for the ODC or Property Managers? I think it is a good idea for ODC, but why should we enforce this on Property Managers?

Author: CryptoGO23
Date: 2023-12-18T19:42:04.586Z

Good evening all,
Some amazing developments going on here and I have a burning question.
How does ERC-7208 address cross-chain functionality and portability of ODCs? Can an ODC created on Ethereum be transferred, bridged or mirrored on other blockchains while preserving its integrity and functionality?

Author: SamWilsn
Date: 2023-12-18T19:42:19.238Z

galimba:

Do you mean for the ODC or Property Managers? I think it is a good idea for ODC, but why should we enforce this on Property Managers?


I wouldn’t enforce (eg. “MUST”) it anywhere, but I would add a recommendation (“SHOULD”) for it anywhere you specify functions that need to be implemented.
If you’re standardizing the interface for Property Managers, you obviously expect third parties to interact with them, so signalling that a contract is, in fact, a Property Manager is useful for discovery.

Author: galimba
Date: 2023-12-18T19:56:40.138Z

SamWilsn:

If you’re standardizing the interface for Property Managers, you obviously expect third parties to interact with them, so signalling that a contract is, in fact, a Property Manager is useful for discovery.


Once again, thanks! You are totally correct, it SHOULD be there. I misunderstood that the suggestion was for a MUST, which I understand would be a bit too strong.

Author: FiremanMal
Date: 2023-12-18T21:18:34.748Z

Data Structure Optimization:
Given the mutable nature of the On-Chain Data Container (ODC) in ERC-7208, how does the standard optimize data structure to minimize gas costs during property updates, especially in high-frequency update scenarios? How does ERC-7208 optimize smart contract interactions, particularly for functions that involve multiple property updates, to minimize gas consumption and enhance transaction efficiency?

Author: D_Ddefi
Date: 2023-12-18T21:43:17.534Z

Can you ellaborate on how this ERC plans to maintain compatibility with emerging ERC proposals that might introduce novel functionalities or data structures?

Author: Leon_S
Date: 2023-12-18T22:15:24.782Z

Love all these questions and answers. Great to see what you guys have been developing behind the scenes.

Author: Cook
Date: 2023-12-19T05:54:01.202Z

Enjoyed the topic, sounds like the way to go for the tokenization of RWA. Good job.

Author: jsburgosAB
Date: 2023-12-19T09:45:23.015Z

Great new standard! I enjoyed reading about it. Two suggestions:


I’d like to propose a slight yet impactful modification to the terminology you used within the ERC-7208 framework. Instead of ‘Real World Assets’, how about the term ‘Real Time World Assets (RTWA)’? This would better reflect the dynamic and constantly evolving nature of these assets, especially considering the real-time updates and interactions facilitated by the ODCs. The term RTWA would not only reaffirm the connection of these assets to the real world but also emphasize their active and current status within the digital ecosystem. I think this change could significantly enhance the way you communicate the capabilities and innovations of ERC-7208.


Thinking about the On-Chain Data Containers (ODCs) in the ERC-7208 framework, I can’t help but compare them to Legos. Just like those classic building blocks, ODCs can be broken down, mixed up, and built back in new ways. They’re flexible and adaptable, letting us customize and enhance our digital assets easily. It’s this Lego-like quality that makes ODCs adaptable building blocks for the blockchain ecosystem.

Author: galimba
Date: 2023-12-19T11:44:57.852Z

CryptoGO23:

How does ERC-7208 address cross-chain functionality and portability of ODCs? Can an ODC created on Ethereum be transferred, bridged or mirrored on other blockchains while preserving its integrity and functionality?


Hey there! Thanks for the question.
I don’t think we should enforce portability or cross-chain functionalities as part of the Standard Interfaces. they “MAY” be implemented, but there are many strategies to pick from nowadays, and there will be many more developed in the future as the ecosystem continues to grow.
That being said, in our Reference Implementation we are using some cool mechanics for supporting the bridging of ODCs.
For example, an implementation of ODC core smart contract MAY have its unique id represented with uint256, crafted in such a way where the upper bytes of the number correspond to the chain_id where the ODC was first minted and using the lower bytes for the actual unique id. This would maintain the uniqueness of all ODCs across blockchains where the ODC contract was deployed, a solution similar to embedding a DOMAIN_SEPARATOR within the ODC’s uuid.
To be clear, that would be an implementation decision (not a specification one), and it carries a lot of other implementation problems to deal with.

Author: galimba
Date: 2023-12-19T11:58:21.899Z

jsburgosAB:

Instead of ‘Real World Assets’, how about the term ‘Real Time World Assets (RTWA)’?


Hey @jsburgosAB thanks for your questions. The term RWA is only incidental and comes in as one of the possible applications for the ERC. It is not the driver behind any of the standard interfaces we are introducing. The main driver for this ERC is data. Specifically,  On-chain data for use cases that require it to be mutable, extensible, composable, and actionable by smart contracts.



 jsburgosAB:

Thinking about the On-Chain Data Containers (ODCs) in the ERC-7208 framework, I can’t help but compare them to Legos. Just like those classic building blocks, ODCs can be broken down, mixed up, and built back in new ways. They’re flexible and adaptable, letting us customize and enhance our digital assets easily. It’s this Lego-like quality that makes ODCs adaptable building blocks for the blockchain ecosystem.


Yes, you are correct in your analogy. This ERC introduces interfaces that can be thought of as legos for on-chain data.

Author: galimba
Date: 2023-12-19T13:38:46.167Z

Jocx:

I am curious how does the Fractionalizer Property Manager in ERC-7208 manage the governance aspects of fractionalized assets, especially in scenarios where these assets are governed by complex legal and operational frameworks?


In the context of the formalization of this ERC (and therefore of this discussion), this is an implementation detail of an example conceptual Property Manager. As of this point, we don’t consider the Fractionalizer as a component that should be included within the interfaces of the ERC. This is to say that the implementation details of specific PMs are outside of the scope of the general interfaces that we are proposing.
Now that we’ve cleared that, yes: we have implemented, audited, and deployed a couple of products that are using a live version of the Fractionalizer. In the Reference Implementation, we will include a version of these contracts where the Governance of fractions is represented with a variation of the Governor contract (Compound). Regarding the legal frameworks, this is also an implementation detail, but this time it has to do with the Rules Engine implementation. The connection between fractions and their compliance rules may be implemented using hooks (i.e. call/delegateCall to functions within the beforeTransfer() and other similar methodologies)

Author: galimba
Date: 2023-12-20T11:53:05.904Z

RWAfan:

In what scenario would you prefer a different standard instead of this one? And when would you use ERC-7208?


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.

Author: galimba
Date: 2023-12-20T19:54:52.486Z

FiremanMal:

How does ERC-7208 optimize smart contract interactions, particularly for functions that involve multiple property updates, to minimize gas consumption and enhance transaction efficiency?


Hey @FiremanMal , thanks for the question. Actually, this would also be an implementation decision. This ERC only describes the interfaces, not how to implement them. We expect there will be many different versions of these architectures, each one of them optimized for different use cases. The key factor, however, is that through those smart contracts implementing Property Manager interfaces, ODCs should be able to interact with one another, regardless of the implementation details.
If you are asking about how we optimized within the Reference Implementation, we are going to be releasing the documentation and SDK soon.

Author: Lao0ni
Date: 2023-12-20T20:02:35.937Z

Hey, guys, good job. I’m glad the idea finally got out there; I can’t wait to built with it, and seeing protocols using that new standard

Author: galimba
Date: 2023-12-21T13:18:25.978Z

Ljrr3045:

We jut saw that Ethereum community adopted the ERC-3643 for compliant RWA tokenisation (…). Is ERC-7208 doing the same?





 AndyVi:

Could you elaborate on specific real-world use cases where ERC-7208 would be particularly advantageous? How does this standard address the challenges faced in these scenarios more effectively than existing solutions?


ERC-3643 defines an interface for tokenized securities for regulated exchanges, which are regular fungible tokens with some additional requirements based on identity. This is not the first (i.e. ERC-1400 / ERC-1594) and probably won’t be the last ERC for securities or RWA. The cool thing about TREX standard is they support identity management solutions. There are lots of regulations coming and the ecosystem will benefit from proper standardization.
Anyway, the first difference to note between ERC-3643 and ERC-7208 is technical: the former must be ERC-20, while the ODCs extends ERC-721. This is because ODCs should be unique, non-fungible. But why should they be unique? Because of the main difference between the standards: the scope. ERC-3643 standard is motivated by “the compliant issuance and management of permissioned tokens”, while ERC-7208 interfaces are motivated by a versatile access to the data stored in smart contracts and bridging the differences between ERCs by standardizing the way in which they share data.
There are similarities between both standards, but only in terms of their practical applications. Just as there are similarities between ERC-721 and ERC-1155 tokens, and both applications of them are considered NFTs but their motivations are quite different.
In terms of advantageous applications of either ERC-3643 or ERC-7208, or even ERC-1400 for RWA I would personally say that it all depends on the specifics of the use case. Regulated asset tokenization is an open topic in terms of implementation, because the regulations are still an open topic in many parts of the world. My personal view is what I said here about some scenarios well suited for ERC-7208.
If you already have RWA tokenized following either ERC-3643 or ERC-1400, and you need them to interact with other standards, modify the rbac logic, or otherwise customize the implementation in a way that would break the standard, then ERC-7208 provides a way in which you can achieve this without actually breaking the standard interface, by abstracting the storage from the implementation.
A couple of examples come to mind:

if you are building a platform for exchanging ERC-3643 tokenized assets, and a new regulation requires complex compliance workflows to be embedded within the asset. You don’t have control on the tokenization, but you do have control over your platform. In this scenario, you could wrap ERC-3643 and apply any logic you want to them… in particular, only enable transfers that are compliant, implement recovery rules, location based rules, etc.
if you have been tokenizing any kind of assets, either following a specific interface likes vaults, securities, or using a bespoke implementation, and you want to support new standards, tap into markets which support a different standard, or abstract a component of the logic (like the identity management, the bridging capabilities, the rationalization logic, ownable mechanics, etc)

The tl;dr is this: the motivation is different, and the use-cases are different, so it stands to reason that both standards can coexist and in some scenarios be leveraged together.

Author: galimba
Date: 2023-12-21T14:17:43.859Z

Lao0ni:

Hey, guys, good job. I’m glad the idea finally got out there; I can’t wait to built with it, and seeing protocols using that new standard 


hahahaha yeah man! the reference implementation will be like Lego bricks for younger solidity devs  like Meccano if you’re my age

Author: Lao0ni
Date: 2023-12-21T23:46:14.404Z

Haha i only know Legos 
Have you already some DeFi protocols in mind to work with ? And did you plan to organize events like demos, workshops, etc. to draw in more attendees? I’m excited about what new opportunities those kinds of standards can bring.

Author: FiremanMal
Date: 2023-12-24T12:34:09.050Z

How is this ERC different from NFT Bound Accounts?

Author: kamelion
Date: 2023-12-24T18:51:11.309Z

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.

Author: rodaemonic
Date: 2024-01-04T03:39:01.648Z

Sounds really interesting. It’s an ERC721 but with a lot of extra features. I’ll take a look to it.

Author: galimba
Date: 2024-01-04T09:28:35.848Z

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.

Author: Ljrr3045
Date: 2024-01-09T10:37:41.279Z

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.

Author: RWAfan
Date: 2024-01-09T10:45:28.453Z

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?

Author: Howee
Date: 2024-01-09T19:39:01.053Z

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?

Author: D_Ddefi
Date: 2024-01-09T21:34:14.083Z

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.

Author: galimba
Date: 2024-01-11T14:31:40.310Z

Ljrr3045:

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.


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

Author: galimba
Date: 2024-01-15T17:44:10.420Z

RWAfan:

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?


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.

Author: galimba
Date: 2024-01-18T21:11:50.361Z

D_Ddefi:

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 @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.

Author: AllianceDaniel
Date: 2024-01-19T09:51:52.536Z

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!

Author: galimba
Date: 2024-01-24T12:26:48.366Z

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 


Ethereum Improvement Proposals


ERC-7208: On-Chain Data Container
Abstracting logic away from storage

Author: Micho
Date: 2024-01-30T20:17:18.456Z

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?

Author: ApostolosSchwarz
Date: 2024-01-31T10:22:01.521Z

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

Author: FiremanMal
Date: 2024-01-31T19:56:26.645Z

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?

Author: galimba
Date: 2024-02-05T16:55:13.918Z

Micho:

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?


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`

Author: galimba
Date: 2024-03-08T08:38:01.246Z

FiremanMal:

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?


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.

Author: galimba
Date: 2024-03-25T17:11:14.886Z

ApostolosSchwarz:

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


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)

Author: galimba
Date: 2024-04-09T10:17:08.490Z

Howee:

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?


You’re 100% correct, we are taking this feedback into account and we will be updating the interface accordingly before moving to Final.

Author: galimba
Date: 2024-05-31T09:00:23.193Z

We’re taking care of the issues pointed out in the conversation. We’ve pushed a couple of updates here, and we’re going to be pushing a few more strong changes to improve the decentralization and abstraction.
Recap from conversations held outside of the Forum: 1) It is true that Properties as such have too much emphasis on data, and 2) storing every data point on the same container is a potential security concern, so we will be pushing an update to separate the interface a bit further. It has been suggested to rename and use “DataPoint” and “DataObjects” instead of calling “Properties”, to differentiate between the actual tag for the data and the internal functions that are used for modifying the storage.

Author: galimba
Date: 2024-06-13T09:02:19.091Z

If we separate the data into multiple contracts, we can mitigate the security concern around centralizing a ton of user data within a single ODC smart contract holding all Properties. Additionally, we would make the ODC far more scalable. This is not a big change, at least conceptually. We are proposing the following architecture:
image1699×744 76.1 KB
Other than changing a few names, the concepts are quite similar:

DataManagers act the same as PropertyManagers, independent smart contracts that can implement their required interfaces and delegate some storage. The difference is that the data is not stored within the ODC, but on a DataObject with access control managed by the ODC.
ODC no longer needs to implement a ton of logic for both managing storage and access control, which means there is not a single contract centralizing all the data for all Data Containers
Data management is no longer part of the ODC, now it is part of each DataObject
This opens up the possibility of Data “Mobility” or “Portability” across ODC implementations. Meaning, if an ERC-7208 smart contract is gas-optimized for a specific task(i.e. multi-chain) and another implementation is optimized for other uses (i.e. Account Abstraction), then a DataManager and DataObject can be “moved/ported”, or “transferred” from one ODC implementation so that data can now be access-managed by another ODC implementation.

Author: galimba
Date: 2024-06-17T11:09:26.472Z

Based on the above diagram, there is no need for an IODCRegistry anymore.
We want to propose a change to the interfaces:
Instead of PropertyManagers, we propose a simple DataManager interface:
interface IDataManager {
    /**
     * @notice Reads stored data
     * @param dobj Identifier of DataObject
     * @param dp Identifier of the datapoint
     * @param operation Read operation to execute on the data
     * @param data Operation-specific data
     * @return Operation-specific data
     */
    function read(address dobj, DataPoint dp, bytes4 operation, bytes calldata data) external view returns(bytes memory);

    /**
     * @notice Store data
     * @param dobj Identifier of DataObject
     * @param dp Identifier of the datapoint
     * @param operation Read operation to execute on the data
     * @param data Operation-specific data
     * @return Operation-specific data (can be empty)
     * @dev Function should be restricted to allowed DMs only
     */
    function write(address dobj, DataPoint dp, bytes4 operation, bytes calldata data) external returns(bytes memory);
}

This way, DataManagers can either read() or write() from a DataObject address (which also acts as delegated storage). Just as with PropertyManagers, DataManagers can implement other interfaces. For instance, a DataManager can also be ERC-20 if it is:
contract MyContract is IDataManager, IERC20, ...

In this scenario, MyContract would have to rely on read() and write() to access the DataObject, and implement the logic of the IERC20 functions (balanceOf(), transfer(), etc).
Multiple DataManagers can make use of the same DataObject for storage. For this to work, it is important to have proper access management.

Author: galimba
Date: 2024-06-17T11:26:07.637Z

So, how do we simplify the central Registry previously proposed (interface IODCRegistry), while still handling proper access to data?
Here is a new proposal:
interface IAccessManager {
    /**
     * @notice Verifies if DataManager is allowed to write specific DataPoint on specific DataObject
     * @param dp Identifier of the DataPoint
     * @param dm Address of DataManager
     * @return if write access is allowed
     */
    function isApprovedDataManager(DataPoint dp, address dm) external view returns(bool);

    /**
     * @notice Defines if DataManager is allowed to write specific DataPoint
     * @param dp Identifier of the DataPoint
     * @param dm Address of DataManager
     * @param approved if DataManager should be approved for the DataPoint
     * @dev Function should be restricted to DataPoint maintainer only
     */
    function allowDataManager(DataPoint dp, address dm, bool approved) external;

    /**
     * @notice Verifies if DataObject is allowed to add Hooks to the DataPoint
     * @param dp Identifier of the DataPoint
     * @param dobj Address of DataObject
     * @return if write access is allowed
     */
    function isApprovedDataObject(DataPoint dp, address dobj) external view returns(bool);

    /**
     * @notice Defines if DataObject is allowed to add Hooks to the DataPoint
     * @param dp Identifier of the DataPoint
     * @param dobj Address of DataObject
     * @param approved if DataManager should be approved for the DataPoint
     * @dev Function should be restricted to datapoint maintainer only
     */
    function allowDataObject(DataPoint dp, address dobj, bool approved) external;
}



The first two functions are get/set Access Control for DataManager to modify a DataPoint.


The last two are get/set Access Control for DataObjects to modify DataPoint.

Author: galimba
Date: 2024-06-17T17:21:18.741Z

We separate the DataObject interfaces into the ones handling the raw data and the ones handling the implementation logic.
interface IDOData {
    /**
     * @notice Reads stored data
     * @param dp Identifier of the DataPoint
     * @param operation Read operation to execute on the data
     * @param data Operation-specific data
     * @return Operation-specific data
     */
    function read(DataPoint dp, bytes4 operation, bytes calldata data) external view returns(bytes memory);

    /**
     * @notice Store data
     * @param dp Identifier of the DataPoint
     * @param operation Read operation to execute on the data
     * @param data Operation-specific data
     * @return Operation-specific data (can be empty)
     */
    function write(DataPoint dp, bytes4 operation, bytes calldata data) external returns(bytes memory);
}

As per the logic of the implementation, we only need one function as it will be handled on a case-by-case basis:
interface IDOHooks {
    /**
     * @notice Execute Hook on ODC ID with specified data
     * This call affects only specified DataPoint and ODC ID.
     * @dev DataObject SHOULD NOT change data for other DataPoint. Data for other oid's within the same DP can be modified if necessary
     * @dev This call is expected to revert if the hook operation is not allowed for the user
     */
    function hook(DataPoint dp, uint256 oid, bytes4 hook, bytes calldata encodedArgs) external;
}

Finally, suppose we want to have “mobility”/“portability” (i.e. the ability to move DataPoints from one implementation of ERC-7208 to another). In that case, the DataObject interface should allow this with a single function call:
interface IDataObject is IDOData, IDOHooks{
    function setOdcImplementation(DataPoint dp, address newImpl) external;
}

Author: galimba
Date: 2024-06-17T17:33:45.164Z

how does the new architecture work with the Wrapper?

A valid question from the telegram channel. With this architecture, the Wrapper works as a DataManager (there can be many instances) and the assets can be stored in AssetVault contracts that extend IDataObject. That is to say, instead of a single smart contract managing all wrapped assets, the implementation may separate them into multiple ownable smart contracts. At the same time, if the implementation has “mobility”/“portability”, it is easy to move whole DataObjects worth of value from one implementation to another. For instance, in the case where ImplementationA supports omni-chain features, and ImplementationB is optimized for lower gas consumption.
We want to get your feedback and help the ERC-7208 become the Standard for adapting/connecting all standards, enabling interoperability across the ecosystem.

Author: galimba
Date: 2024-06-18T09:33:06.939Z

What does Mobility/Portability mean?

It is the ability to choose implementations. In other words: a DataManager may decide to entrust the management of DataObjects to a compatible ODC Smart Contract.
image1400×653 59.8 KB

When is this relevant? / Why is this important?

For instance, in the case where a DataManager Admin (i.e. Developer, DAO, or owner of the DataManager Smart Contract) sees that switching to a different implementation of Access Manager. One ODC implementation may support hooks, another ODC implementation may have omni-chain support, another may have both (making it more gas-costly), and another ODC implementation may be developed with gas optimizations for a custom use case.

Author: galimba
Date: 2024-06-25T09:11:17.407Z

How does Mobility/Portability work?

It works within similar implementations of DataPoints.
We introduce a DP-Registry interface, for implementing contracts that manage access control to DataPoints. The DataManager Maintainer can allocate DataPoints through a Registry instance and delegate management if required. The ODC Implementation verifies access management.
DataManagers should be able to move implementations, provided that they are using compatible DataPoints. DP-Registries are, in a way, a mechanism for bundling DataPoints that follow the same internal structure and therefore are compatible with each other.
For simple implementations, a DP-Registry interface can be implemented within the ODC as a monolithic contract although we don’t recommend this.
For most use cases, we expect they will be using a handful of DAO-managed or semi-public registries.
Building their own self-managed DP-Registry may make sense for big or complex protocols requiring many DataPoints especially if they want to add some custom features.
image919×773 52.2 KB

Author: galimba
Date: 2024-06-25T09:14:42.797Z

So, what exactly is a DataPoint?

In our reference implementation, the type DataPoint is bytes32;. DataPoints SHOULD know which Registry allocated them, and it MAY store information relevant to the compatibility with other DataPoints. There shouldn’t be any further limitation (from the ERC) about other implementation decisions.
Here is a suggestion for a 32 bytes structure:
/**
 * Reference Implementation of internal DataPoint structure:
 * 0xPPPPVVRRIIIIIIIIHHHHHHHHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 * - Prefix (bytes4)
 * -- PPPP - Type prefix (0x4450) - ASCII representation of letters "DP"
 * -- VV   - Verison of DataPoint specification, currently 0x00
 * -- RR   - Reserved byte (should be 0x00 in current specification)
 * - Registry-local identifier
 * -- IIIIIIII - 32 bit implementation-specific id of the DataPoint
 * - Chain ID (bytes4)
 * -- HHHHHHHH - 32 bit of chain identifier
 * - REGISTRY Address (bytes20)
 * -- AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA - Address of Registry which allocated the DataPoint
 * 
 * !!! ERC-7208 COMPATIBILITY REQUIREMENTS !!!
 * - REGISTRY address SHOULD be located in the last 20 bytes of the DataPoint in ALL DataPoint implementations
 * - PREFIX 0x44500000 MAY be used. This identifies the implementations with the same DataPoint structure
**/

This suggested implementation of DataPoint internal’s structure holds 32 bits for the chain identifier, which may be used by an omni-chain ODC implementation to sync data across blockchains.

Author: Lao0ni
Date: 2024-07-06T17:57:30.161Z

Congrats on the improvements and simplification of your architecture. I really appreciate the new design; it’s much easier to manage, adapt, and export.
I have a couple of questions regarding the implementation of ERC-7208:


If a protocol or developer wants to implement and use ERC-7208, do they essentially only need to focus on the ODC and Data Manager SCs ?


Are the DOs (Data Oracles) common for all ODCs on a particular blockchain?


Looking forward to work with that, looks really promising

Author: galimba
Date: 2024-07-06T18:55:05.203Z

@Lao0ni Thanks for your questions! Super valid points, and it is very important to clarify a few things here:



 Lao0ni:

I have a couple of questions regarding the implementation of ERC-7208:

If a protocol or developer wants to implement and use ERC-7208, do they essentially only need to focus on the ODC and Data Manager SCs ?



Short answer: Depends on the use case. If you want to use this standard, you can:

No dev requirement: as a user of any Data Manager exposing any interface, you won’t know the difference
Minimal dev requirement: By Integrating with it by just developing a Data Manager implementing your business logic, re-using someone else’s ODC implementation, and Registry for allocating Data Points, and finally someone else’s Data Objects for managing your Data Points.
Some dev requirements: By Implementing your Registry, either if your use case requires a separate space for storing Data Points or if you want to have a different Data Point internal structure.
A bit more effort: By implementing your own ODC Smart contract or a custom Data Object internal logic, you may want to have a cross-chain storage sharing mechanism for storing assets or an on-chain gating mechanism embedded into the low-level storage management.

Coincidentally, this new architecture means that the ODC doesn’t have to be an ERC-721, which in turn means ERC-7208 no longer relies on it. If you wanted to have an ODC implementation where each data container is an NFT, you can, but the standard should not force you to do that
We expect that for most instances, the motivation to use ERC-7208 will come from a use-case that either:

Requires interoperability of assets: i.e. if you want to develop a mechanism for trading ERC-1155 through ERC-20 interfaces, you can use a DataObject for storing the mapping of balances, and then expose as many Data Manager interfaces as you want.
Requires adapting one standard to another: i.e. if you are collecting ERC-721 NFTs and you want to make them Rentable (ERC-4907), you would store the NFT in a DataObject and expose it through a DataManager implementing the ERC-4907 interface.
Requires modifying the logic of a particular asset: If you have a certain RWA and the regulatory framework on your current jurisdiction has changed, you may require an update to the Smart Contract managing such asset. But if you are not the owner of that contract, you won’t be able to update it. The solution would be to abstract the asset from the logic that governs it, and this is where ERC-7208 shines

We also expect that, as the Ethereum ecosystem grows, so does the need for On-chain Adapters to address incompatibilities. The other day a close friend of mine was traveling abroad, and he forgot his adapter to charge his phone. Good thing universal adapters are cheap, right? Well, ERC-7208s are the same thing: they enable interoperability between on-chain contracts following different standards.



 Lao0ni:


Are the DOs (Data Oracles) common for all ODCs on a particular blockchain?



DOs are Data Objects, not Oracles. We took the Property concept (now Data Point), and moved it to a separate contract (Data Object) to be more scalable by decentralizing the necessary logic for handling this storage. Since the low-level data-management logic no longer sits on the ODC Implementation, it is a part of the Data Object, and so we don’t need Restrictions anymore as they can be implemented by the Data Object. The Oracles as you know them can be an implementation of a Data Manager.
About the particular blockchain… it depends on the implementation. Neither Data Points, nor anything that uses them is required to have a ChainID or Domain Separator. However, it is recommended as we are providing omnichain support on our reference implementation.

Author: galimba
Date: 2024-07-09T20:38:42.074Z

We’ve added a couple of assets to the ERC, you will find them on this folder
Here is a simple overview of the main components:

To the left, multiple Data Objects acting as buckets of assets and storing asset data
In the middle, an ODC implementation that will handle write function calls for Data Managers
Data Managers to the right, exposing business logic
erc-7208-simple-overview744×440 42.7 KB

A deeper overview, where we also introduce the role of Data Points and their Registries
erc-7208-technical-overview1374×731 115 KB

Author: galimba
Date: 2024-07-15T13:56:11.762Z

GM, gm… I wanted to share an overview diagram for a use case proposed by a community member on the telegram channel.
This architecture enables transparently trading of fractionalized assets across blockchains, by integrating with LayerZero. In chain A, assets are wrapped through a Wrapper-Fractionalizer DM contract. The assets are owned (“stored”) on an Asset Vault, managed by a Vault Data Object. In the chain B, the Data Manager emits the fractions that can be traded. An ODC Omnichain Proxy implementation of the ODC smart contract handles the synchronization and message passing across chains.
image1252×887 69.3 KB

Author: galimba
Date: 2024-07-15T20:41:37.852Z

A slight correction on the previous diagram, as pointed out by a community member: The green and purple dotted vertical lines to the left of the diagram, should go through the ODC Omnichain Proxy and then through the ODC implementation on Chain B, representing the ODC validation of access control rights, before accessing the OmnichainFuntibleFractionsDO. In other words, cross-chain DataObjects like this can be developed, but they must abide by the access management imposed on the ODC Implementation (read()/write() functions).

Author: galimba
Date: 2024-07-18T11:26:37.889Z

Another good point brought up by community members:

What if the DataManager needs to send a native token and store some values on the DataPoint?

The question is referring to the write() functions on ODC implementation and DataObject. write() may be required to be payable by the use-case, in which case we should update the ERC to reflect this behavior:
write() MAY be payable in the case of DataObjects and ODC Implementation

Author: galimba
Date: 2024-07-22T13:02:42.368Z

After a discussion on the community chat, we will remove the allowDataObject and isApprovedDataObject functions from the ODC interface. The rationale is that those two functions were used for access management control from ODC to DataPoint. However, DataPoint management should be on DataObject through the DataManager Admin. DataManager is the one requesting DataPoints to the Registry; therefore, the responsibility of managing DPs is on the DataManager. We don’t want the ERC to force all ODC implementation to mess with DataPoint access management. Anyone can propose an ODC implementation that can have extra control, but this shouldn’t be required of the ERC.

Author: galimba
Date: 2024-07-24T08:56:44.025Z

A proposal has been made for changing the name of a major component:

Rename the ODC to Index or DataIndex

The rationale is that, after the decentralization of Properties into DataPoints, the ODC structure is no longer a “data storage unit”, but a data index of Data Objects that manages the actual storage of Data Points. Therefore, in the current state, the smart contracts acting as “data containers” are not the ODC Implementation, but the DataObjects. The current ODC Implementation acts as an ACL intermediary layer between the Data Points and the Data Manager. It is only a “Data Container” because it is a point of contact for Data Managers. Since Data Managers are “aware” of Data Points, the storage is not abstracted from them further supporting the argument in favor of renaming IODC into IODI or something similar.
The interfaces would be:

DP → indexed low-level data storage (bytes32)
DP Registry → defines a space of data point compatibility/access management
DI / ODI → indexes information and approvals (former ODC Implementation)
DM → interfaces with user, implements business logic
DO → logic implementing data management

As you are aware, we are close to pushing the ERC to “In Review” state.  A change like this has the potential to impact the whole ERC, so we want to open up the question to the community before following through with the changes.

Author: galimba
Date: 2024-08-01T18:49:18.493Z

in preparation for moving the ERC to “In Review”, we just pushed an example implementation here
The implementation makes use of the abstraction of storage in favor of an implementation that drives interoperability between ERC-1155 and multiple ERC-20 contracts.
This is an educational example and has not been audited, therefore we do not recommend using these contracts in any production environment

Author: rbgrn
Date: 2024-08-08T18:58:10.059Z

Very interesting. Seems well-suited for very deep data models.

Author: SamWilsn
Date: 2024-08-20T14:34:49.974Z

Apologies for jumping in here without reading all the previous comments, but I wanted to check if there are any opportunities to borrow terminology from already existing object oriented design patterns. A lot of the concepts introduced in this proposal feel vaguely similar to ones used in the Java world in particular.

Author: pash7ka
Date: 2024-09-04T08:06:01.222Z

Hi @SamWilsn,
You’re right: Data Objects have a lot in common with some data-related Java patterns. At the same time, there are differences.
Data Access Objects are used in Java to abstract data storage from business logic. This is similar to the purpose of the Data Objects we have, but DAOs are limited to generic CRUD operations, while Data Objects provide data-specific operations (like mint/burn/transfer when we store data for a fungible token).
Data Objects are also similar to Components in the ECS pattern, since they inherit data and base logic for it. But I think it would be wrong to represent Data Managers as Entities - because unlike Entities, which usually only have an ID, Data Managers have their own logic and data.
Data Index provides an intermediate layer between business logic (implemented in Data Managers) and data storage (in Data Objects), and this is similar to the Repository Design Pattern , but since the main purpose of Data Index is to manage access to Data Objects, I don’t think it has exactly the same purpose and semantics as Repositories.

Author: galimba
Date: 2024-09-20T12:54:38.588Z

We’ve open-sourced an educational example, with a minimalistic implementation of the ERC-7208 and shared storage between different interfaces of tokens.


github.com




GitHub - Nexera-Foundation/Minimalistic-ERC-7208
Contribute to Nexera-Foundation/Minimalistic-ERC-7208 development by creating an account on GitHub.






What does this mean? A single ERC-1155 smart contract (i.e. fractional ownership of an asset, represented by the NFTs) can now be traded concurrently through its original smart contract or an alternative ERC-20 interface.
Why is this relevant? Because ERC-1155 is usually an illiquid asset. The possibility of trading it through an ERC-20 interface enables tapping into liquidity pools through DEXs (i.e. Uniswap and others)
How does it work? By abstracting the storage of the asset from the interface (ERC-1155, ERC-20, etc) being used to access and modify the underlying asset. This is only possible through ERC-7208

Author: TechnicallyWeb3
Date: 2024-09-24T19:33:48.565Z

This is awesome and just what we need for our browser… We have built a version of this technology just this last week. We call them WebContracts and they are supposed to mimic an Apache server including redirect codes, MIME types (and a special version of Extended MIME type that we build specifically for web3 links). Our contract works as a transferable file and token store (ERC20 and ERC721).
I was actually about to update our contract to take low-level data rather than just strings. And I wanted to expand the token withdrawal to be able to execute any function of the owned token’s contract.
Would anyone look over my latest updates to my WebContract project (v0.1.0 coming soon to return full redirectCodes in the next couple days)?
Would like some help to get an ERC draft together. *I’m new here and not sure how or where to start my own thread.
GitHub Repo: technicallyweb3/web-contract
NPM Package @tw3/solidity/contracts/WebContract.sol

Author: TechnicallyWeb3
Date: 2024-09-24T21:33:49.163Z

Would what I’m building be considered a Data Manager in this scenario? I have also built a LinuxVirtualFS contract which brings functions like ls, mkdir, rm, touch, nanoUpdate and more to make the contract feel like you’re interacting with a linux machine. What roles would these components play in the ERC-7208 ecosystem?

Author: galimba
Date: 2024-09-28T10:44:50.328Z

TechnicallyWeb3:

mimic an Apache server including redirect codes, MIME types (and a special version of Extended MIME type that we build specifically for web3 links).


This is super interesting (!!!) Thanks for asking this type of question, and I hope we can help you sort it out.



 TechnicallyWeb3:

Our contract works as a transferable file and token store (ERC20 and ERC721).
(…)
I was actually about to update our contract to take low-level data rather than just strings. And I wanted to expand the token withdrawal to be able to execute any function of the owned token’s contract.


It would benefit from being an abstract generic storage, like a File DataObject for file handling. Then the functions can be handled elsewhere on a different contract, perhaps on a different chain as well.



 TechnicallyWeb3:

Would anyone look over my latest updates to my WebContract project (v0.1.0 coming soon to return full redirectCodes in the next couple days)?


For sure, lets chat =)



 TechnicallyWeb3:

Would like some help to get an ERC draft together. *I’m new here and not sure how or where to start my own thread.


You can always open a new thread on this forum, or if the project already has a few backers, you can open up a PR on GitHub - ethereum/ERCs: The Ethereum Request for Comment repository for a DRAFT proposal



 TechnicallyWeb3:

Would what I’m building be considered a Data Manager in this scenario?


Yes and No. The DataManager is “the last mile” component that exposes interfaces with the end-user. The storage layer is with the DataObject, the DataPoint is the “pointer” to the data, not unlike an inode, and the DataIndex is the “access manager”. ERC-7208 can help you set up an architecture design pattern that is sustainable and interoperable, by using simple interfaces for separation of domain and to facilitate communication between components (i.e. read/write functions and other common interfaces).



 TechnicallyWeb3:

I have also built a LinuxVirtualFS contract which brings functions like ls, mkdir, rm, touch, nanoUpdate and more to make the contract feel like you’re interacting with a linux machine.


I’ll need to understand a bit more about what you’re trying to achieve, and how deep down the rabbit hole you want to take it. Do you want to have “just the feeling” of interacting with a terminal, or do you want to have a full Linux running on top of EVM? Do you want a FS or do you want just to expose some functions that pretend you are using a FS?



 TechnicallyWeb3:

What roles would these components play in the ERC-7208 ecosystem?


First thing, ERC-7208 is not an ecosystem. It is an ecosystem builder. You can use it to build smart contracts that can interact with one another, including adapting previously deployed assets to be wrapped and exposed through a different implementation. This ERC can provide you with the framework to build those things you mentioned in the previous msg and much more, but the motivation will determine the architectural design you wish to follow. Where is this code going to run? Is it a private chain, public, or localhost? Who is going to be using this, and for what purpose?
An over-simplification can look like this:

File Data can be stored in a bytes32 format (if you want to have 32-byte block size or you can simply use bytes blobs), indexed by a DataPoint, which is issued by a DataPointRegistry
The DataPoint is managed by a File DataObject implementing the “low-level file management” logic.
The Access Management can be implemented through a DataIndex, that allows/denies access based on user/application privileges
The Logic facing the user/application (i.e. mkdir/rm/touch/…etc) can be exposed through one or multiple DataManager contracts.

Author: galimba
Date: 2024-10-21T12:37:17.118Z

In preparation for going from “In Review” to “Last Call”, the team has released some technical documentation that we hope you’ll find helpful.
https://docs.nexera.network/nexera-standard/

Author: galimba
Date: 2024-11-08T19:55:18.558Z

The Minimalistic Example implementation repository has been closed for a few days while undergoing an audit with Omniscia. After completing the process, the code will be renamed as the Reference Implementation and the report will be made public.
We’ll be pushing for the ERC to go for LAST CALL, and soon after FINAL.

Author: nickjuntilla
Date: 2024-11-10T23:50:43.772Z

After spending 3 days reading the (very trite) description of ERC-7208 and it’s related interfaces, going over the example implementations and further dissecting it with ChatGPT. I would highly recommend you update your description and explanation here: ethereum . org/EIPS/eip-7208 The main issues I had trouble with are that it’s not clear what the hierarchy of this system is. What containers contain what and where the actual data lives.
From someone with fresh eyes: You have something called a data registry which appears to contain the actual data but has no read and write methods. Further more you have permissions on the data registry and then also on the data index. You have almost identical descriptions for both. It is not clear how the data registry is different from the the data index and what are the responsibilities of each. A chart or some of the charts you have created for this page would be great.
It is not clear how a data object relates to a data point. I have discerned that it is a 1 to many relationship and I feel like the probability of that is 80% at this point but it is not explicitly stated anywhere on the main informational page. It is also not clear if using a data object is always necessary.
It is not clear if a data index is always necessary. It is not clear how data is registered in the data index. It is not clear the usefulness of the data index because there are no example methods or description of how it may be used to retrieve many data points or all the datapoints of a dataobject if that is one of the uses.
It seems like there are many ways this system of data abstraction can be implemented and the interfaces you have created are designed to allow for many different implementations.
There are also several mistakes on the ethereum . org/EIPS/eip-7208 page. In the write method on the data index interface this line
@param operation Read operation to execute on the data
should probably be
@param operation Write operation to execute on the data
On this like
* @return If the role was revoked (otherwise account didn't had the role)
“had” should be “have”.
Througout the documentation this wording is used
  * @return Operation-specific data

But it is unclear what this means. An example or short explanation would be very helpful.
Overall I think this is a good idea, but for someone coming in with fresh eyes it is very hard to understand. A very basic example of the least necessary operations and smart contracts necessary to implement this would be very helpful to conceptualize is the core of this system and what is ‘nice to have.’ How is an index used? Where is the data stored?
It is helpful to read this long wall of comments, but it would be even more helpful if this information could be distilled and put back into the main website especially with some hierarchical charts.
Thank you very much for your work.

Author: nickjuntilla
Date: 2024-11-10T23:54:12.728Z

I’d also like to recommend that when you introduce the concepts of the data points, the data objects, the registry and the index you introduce them in order from the most granular to the most encompassing. This probably means you start with a data point and end with the the data point index.

Author: galimba
Date: 2024-11-11T12:57:50.594Z

Hi Nick! Thank you for going through the trouble of reading and reviewing the ERC 
You are correct, the currently published description is bound for an update! And we have been working on it. I am confident all your points have been addressed in the next update, which we’ll publish in a few days.
Generally speaking, I’ve found that GPT is prone to hallucinations after reading this thread. The standard has changed a lot since its conception, and the terminology has evolved with it. Still, I’ll try to clarify a few points here:




 nickjuntilla:

The main issues I had trouble with are that it’s not clear what the hierarchy of this system is.


We’re providing two diagrams, here and here

The first is a conceptual overview, where we exemplify the separation of domain between storage, access management, and business logic.
The latter is a more technical diagram, showcasing the interactions between components and their roles.





 nickjuntilla:

What containers contain what and where the actual data lives.


Data is stored within DataObjects, and uniquely identified by DataPoints. Each DataPoints acts as a unique reference to the information stored on-chain. You can think of a DataPoint as a “pointer” to the data being stored and managed by the DataObject.




 nickjuntilla:

From someone with fresh eyes: You have something called a data registry which appears to contain the actual data but has no read and write methods.


There is a misconception here. The Standard doesn’t have a Data Registry. We propose a DataPoint Registry, with its main role being access management, rather than data storage. This is why it does not have a read() or write() method.
The standard states:

The Data Point Registry is a smart contract entrusted with Data Point access control. Data Managers may request the allocation of Data Points to the Data Point Registry .

Additionally, since each Data Point Registry implements the same Structure for all the Data Points under it’s management, in essence it defines the “space of compatible Data Points”.
In a previous iteration of the standard (in DRAFT, about a year ago), we used to have some form of smart contract that acted as a single data repository. We have left that architecture behind on account of its centralization. It is better to have multiple Data Objects capable of coexisting and managing their own internal low-level data-management logic than a single central repository for all data.




 nickjuntilla:

Further more you have permissions on the data registry and then also on the data index. You have almost identical descriptions for both. It is not clear how the data registry is different from the the data index and what are the responsibilities of each. A chart or some of the charts you have created for this page would be great.


Both the DataPoint Registry and the Data Index are smart contracts designed for access control. The Standard does not impose restrictions on whether they should be the same or separate contracts. That is, if you wanted to build a monolithic implementation you should be able to do it and still comply with the standard Interfaces. However, they are exposed as separate entities because of the separation of domain. I trust these diagrams (here and here) help explain the roles.
Regarding the Data Index, the standard says:

The Data Index is a smart contract entrusted with access control. It is a gating mechanism for Data Managers to access Data Objects . If a Data Manager intends to access a Data Point (either by read() , write() , or any other method), the Data Index should be used for validating access to the data.

So DataPoint Registry implements DataPoint access-management, while Data Index implements Data Manager access control to Data Objects. This requires the Data Index to implement user control or some form of ID management (either through address, NFT gating, or some other mechanism. The Standard does not impose restrictions on the mechanism, leaving it open to the developer to chose which one suits the implementation. However, the standard has this to say about it:

The mechanism for ID managamenent determines a space of compatibility between implementations.

In this context, this means that “Data Portability” or “Data Mobility” between implementations is subject to a compatible Data Index. In other words: when a Data Manager using Data Index A wants to switch implementations to Data Index B, the Data Manager must consider that the internal ID management of both Data Index implementations must be compatible.




 nickjuntilla:

It is not clear how a data object relates to a data point. I have discerned that it is a 1 to many relationship and I feel like the probability of that is 80% at this point but it is not explicitly stated anywhere on the main informational page. It is also not clear if using a data object is always necessary.


I hope this was clarified on the previous points. Data Points and Data Objects are necessary every time that data needs to be indexed and stored for its abstraction.




 nickjuntilla:

It is not clear if a data index is always necessary.


Indeed, a Data Index is always necessary for access-control from Data Managers to Data Objects, which translates in ID management for the end-user (albeit an address or a contract.




 nickjuntilla:

It is not clear how data is registered in the data index. It is not clear the usefulness of the data index because there are no example methods or description of how it may be used to retrieve many data points or all the datapoints of a dataobject if that is one of the uses.


I believe this misunderstanding comes from the previous one regarding the Data Index role. Data is not registered in the Data Index. Data lives within one or many Data Objects, referenced or pointed by a Data Point.




 nickjuntilla:

It seems like there are many ways this system of data abstraction can be implemented and the interfaces you have created are designed to allow for many different implementations.


This is correct, and it is the main motivation behind the standard. This architecture is designed to allow for many different implementations to be compatible with one another, enabling data mobility or portability between those implementations.




 nickjuntilla:

@param operation Read operation to execute on the data
should probably be
@param operation Write operation to execute on the data


I think this is within the read() function declaration, so it’s ok to have a “Read”, as it’s a view function.




 nickjuntilla:

On this like
* @return If the role was revoked (otherwise account didn't had the role)
“had” should be “have”.


Fixed, thank you! 




 nickjuntilla:

Througout the documentation this wording is used
  * @return Operation-specific data

But it is unclear what this means. An example or short explanation would be very helpful.


This means that each read or write will also require an operation to be performed. If it is a read, it retrieves some data from the operation performed (i.e. a read on an mapping address -> address will retrieve an address, while a read on a public bool variable  will retrieve a bool). Conversely, the write operations must receive operation-specific data to be written.




 nickjuntilla:

A very basic example of the least necessary operations and smart contracts necessary to implement this would be very helpful to conceptualize is the core of this system and what is ‘nice to have.’ How is an index used? Where is the data stored?


We have a reference implementation that is currently under audit and will be published in the next weeks. You’ll find it here
For now, what you are looking for is also provided here, as part of the current work In Review, and cataloged as an Example Implementation.




 nickjuntilla:

I’d also like to recommend that when you introduce the concepts of the data points, the data objects, the registry and the index you introduce them in order from the most granular to the most encompassing. This probably means you start with a data point and end with the the data point index.


For the next version, we were thinking of going for a “Top-Down” approach… but I understand what you’re saying and it makes sense.
Maybe we can go in this order:

Data Point, as the structure is important to how data is indexed.
Data Object, as this is where the actual data resides.
Data Manager, as this is the user-facing contract, implementing any interface.
Data Point Registry, as this is access management for data.
Data Index, as this is access-management for business logics.


Once again, I thank you for taking the time and putting in the effort on reviewing this ERC. I cannot stress how important this process is, and how valuable your input was. 
Please, let us know if you have any follow-up questions.

Author: pash7ka
Date: 2024-11-11T13:25:15.514Z

Hi Nick! Thank you for you interest to the ERC.
I see DataPoint as a label of application which creates & modifies data.
You allocate the DataPoint through the DataPoint Registry for your application and then use it to define who can access application’s data. After that your DataManager specify DataPoint to show which data they want to access.

Author: johnsn
Date: 2024-11-13T02:47:49.163Z

GM, sorry if this has already been answered but I’m not sure if I understood it correctly — could this standard theoretically allow for the integration of tokens from other L1s into the Ethereum ecosystem, enabling them to be treated as compatible Data Objects for things like staking and reward distribution? Or is it more focused on abstracting data storage and management without actually transferring assets across chains?

Author: galimba
Date: 2024-11-13T10:12:13.924Z

Hey @johnsn, thank you for taking an interest in this ERC!
I think you’ve raised a question that hasn’t been explicitly addressed yet but has been assumed throughout the discussion.
The short answers are: “Mostly YES” and “YES.”
Now for the longer explanation:
In response to this part of your question:

“is it more focused on abstracting data storage and management without actually transferring assets across chains?”

EIPs (Ethereum Improvement Proposals) are the primary mechanism for proposing new features to Ethereum, gathering technical feedback from the community, and documenting design decisions. ERCs, as application-level standards, provide conventions for specific use cases, such as token standards (e.g., ERC-20), name registries, and wallet formats.
This particular standard, ERC-7208, focuses on abstracting on-chain data storage from the logic used to manage it. The motivation here isn’t solely about transferring assets across chains, but rather achieving asset-data interoperability.
On-chain data is typically tied to specific storage mechanisms—for example, ERC-20 uses a mapping of address -> balance. Because of these dependencies, other standards often limit how data can be managed or shared. ERC-7208 provides a framework to decouple those dependencies and enable more flexible interactions.
You can think of most ERCs as theoretical frameworks. For instance, ERC-20 was instrumental in building stablecoins, but the standard only defines the interface for token contracts, not their implementation. Similarly, ERC-7208 proposes a high-level architecture or design framework, leaving the implementation, tooling, and applications to developers.

As for this part of your question:

“ould this standard theoretically allow for the integration of tokens from other L1s into the Ethereum ecosystem, enabling them to be treated as compatible Data Objects for things like staking and reward distribution?”

Yes, absolutely. This is a theoretical application of the standard. In practice, several companies are already working on interoperability solutions based on ERC-7208.
At its core, the standard defines a set of interfaces for smart contracts to interact with one another. These interfaces specify the function names, expected parameters, and guidelines for their usage. However, the actual implementation is up to developers, allowing them to tailor it to their needs.
As stated in the DRAFT:

“We recognize there is no ‘one size fits all’ solution to solve the standardization and interoperability challenges.”

We believe this ERC is a step in the right direction, and its adoption so far has shown that it is a valuable framework. Not just for cross-chain interoperability, but mainly for adapting assets from one standard to another, for embedding regulatory-compliance checks within the logic of certain assets or protocols, for future-proofing already existing solutions, and for building data-oriented smart contract architectures.
This ERC is not intended to solve all these problems directly. Instead, it aims to provide a framework that empowers engineers to develop solutions for them.
Thanks again for your question, and I hope this clarifies things!

Author: galimba
Date: 2024-11-18T21:46:53.760Z

Updates pushed. Source code updated and sent for audit.

Author: futreall
Date: 2024-11-19T07:46:23.689Z

How does the concept of horizontal data mobility introduced in ERC-7208 redefine the approach to on-chain interoperability, and what implications could this have for the future of standardization within the Ethereum ecosystem?

Author: xdaniortega
Date: 2024-11-29T12:18:10.668Z

Thanks @futreall for taking part of the debate of this standard, your contribution will help to better understand the capabilities ERC-7208 to newcomers.
Until now, transferring assets between chains means bridging from source chain (SC) to destination chain (DC) or wrapping assets, locking it in SC and minting a new token in DC,
this has several implications and, maybe one of the most important parts, it is very difficult (UX-wise) for a user to operate across chains.
With the new architecture proposed by abstracting logic from storage, a transfer operation logic will remain in the source chain and the asset virtually shares storage between chains, meaning there is no need to wrap or bridge assets.
Do we see how cool is that?
Let’s take this example:
Given an already functional ERC20 token under ERC7208, we would have a DataManager that defines the logic of the transfer operation single-chain. In this case, it can be used in a local DeFi protocol as usual.
If we would want to give this ERC20 token cross-chain capabilities, DataManager can decide to upgrade to a DataIndex that has omnichain support (omni = any), turning the capabilities of the same DeFi protocol to use the asset cross-chain.
In regards your question about the implications about the future of standardrization within the Ethereum ecosystem. I’d say cross-chain projects and DeFi is one of the hottest topics right now in the industry. A lot of players are bringin solutions to patch or meet the requirements they have for a single use case, and we bring ERC7208 for the long run.
As you may see, we wanted to make this standard as agnostic and upgradeable as possible, giving full potential for upcoming use cases and solving the fragmentation the industry has across standards.

Author: alex-ppg
Date: 2024-12-02T14:33:07.374Z

I believe that the EIP presently possesses some ambiguities in its content, and the use of loose RFC-2119 terminology does not benefit it or its adoption. In my opinion, the Data Point structure and the relevant interfaces need to be strictly defined to encourage ecosystem growth, permit auditors to validate the standard correctly, and allow utility libraries in off-chain software to be utilized across EIP-7208 implementations.
Beyond concerns around RFC-2119 terminology, the EIP definition itself is presently incorrect in the sense that its definitions are incompatible (particularly interface definitions). As an example, the Data Object Interface definition is as follows:
interface IDataObject {
    function read(DataPoint dp, bytes4 operation, bytes calldata data) external view returns(bytes memory);

    function write(DataPoint dp, bytes4 operation, bytes calldata data) external returns(bytes memory);

    function setDIImplementation(DataPoint dp, address newImpl) external;
}

These definitions make use of the user-defined DataPoint variable type causing implementations to be forced on a particular pragma version range, a trait that is generally avoided in EIPs relating to smart contract implementations that do not make use of opcodes.
Secondly, the user-defined DataPoint causes function signatures to not be generate-able by the interface declaration alone. Specifically, different function signatures will be generated if the DataPoint is a uint256 variable than if it is a bytes32 variable and so on. The EIP mentions that the DataPoint SHOULD be bytes32, but does not mandate it so.
To ensure that the definitions are compatible, one of the following edits should be made:

The code within the EIP should be clarified as pseudo-code
The DataPoint itself should be set to a particular data type strictly (i.e. use MUST in place of SHOULD in relation to whether it is a bytes32 data type) and all DataPoint mentions should be replaced by the underlying data type (including interface-style data types such as IDataObject)

Depending on the desired direction of the EIP by the team that drafted it, any of the aforementioned edits would be acceptable. However, one of the edits must be incorporated to ensure that the EIP is clearly and concisely defined without any ambiguities.
From a long-time auditor’s and ecosystem developer’s PoV, I believe that restricting the DataPoint type is acceptable for this particular EIP. Additionally, I believe that some of the interface declarations should use MUST terminology as well (i.e. IDataObject and IDataIndex read/write function definitions) to impose a common baseline for all EIP-7208 implementations.
Given that the above MUST terminology changes would not actually restrict how the underlying 32 bytes are used in a particular DataObject and the dynamic data arguments of the read/write function definitions allow maximum flexibility I do not believe the above recommendations are unsound.
Disclaimer: This feedback has been provided on behalf of Omniscia as part of a security engagement by the Nexera team in relation to this EIP

Author: galimba
Date: 2024-12-02T20:07:55.099Z

Thank you @alex-ppg and Omniscia 
We have applied the following suggestions:

DataPoint MUST be bytes32
The erc enforces the implementation of the interfaces (IDataObject, IDataPointRegistry, IDataIndex)  with MUST rather than SHOULD
Functions within the interfaces (i.e. read()/ write()) now take arguments in the underlying data type (i.e. address / bytes32)
Improved DataManager enforcement

Author: galimba
Date: 2024-12-09T08:34:31.219Z

Hey @Vitaliyr888, compatibility is ensured because although ERC-7208 is NOT a token standard, it is designed to abstract the underlying asset’s storage of any token and enable the separation of its logic. We’re providing a short list with some examples here.
We’ll happily provide some insights if you’d like to ask about a specific integration or interoperability use case.

Author: galimba
Date: 2025-01-01T15:06:11.392Z

The ERC-7208 is now on LAST CALL. We’ll be pushing for FINAL in a few weeks.
The audit report is here
The reference implementation is here
Special thanks to Omniscia for their contributions.