ERC-7208: On-chain Data Container

ERCs
, , , ,
23

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

7 Likes
24

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?

5 Likes
25

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

4 Likes
26

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)

8 Likes
27

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

1 Like
28

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.

9 Likes
29

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)

9 Likes
30

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?

4 Likes
31

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

6 Likes
32

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!

5 Likes
33

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

4 Likes
34

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?

5 Likes
35

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

9 Likes
36

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 :pray:

4 Likes
37

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

6 Likes
38

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?

3 Likes
39

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?

4 Likes
40

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.

4 Likes
41

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.

7 Likes
42

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.

6 Likes