This is really great, especially in the RWA sector. Good work guys
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.
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)
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?
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
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!
What are the challenges in implementing ERC-7208, particularly in terms of backward compatibility and integration with existing systems?
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?
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
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
You mentioned Hooks a couple of times. How do these differ from Uniswap V4 hooks?
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?
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?
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.
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
forbytes32
key-value pairs,keyBytesData
for storingbytes
,keySetData
for sets ofbytes32
values,keyMapData
for mappings ofbytes32 => 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.
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.
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!
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.
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).
I believe these two previous replies address the question:
Let me know if I can help you address any specifics.