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?
4 Likes
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?
4 Likes
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
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
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
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
This is really great, especially in the RWA sector. Good work guys
1 Like
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
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
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
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
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
What are the challenges in implementing ERC-7208, particularly in terms of backward compatibility and integration with existing systems? 
4 Likes
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
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
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 
4 Likes
You mentioned Hooks a couple of times. How do these differ from Uniswap V4 hooks?
6 Likes
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
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
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