Enjoyed the topic, sounds like the way to go for the tokenization of RWA. Good job.
1 Like
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.
2 Likes
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.
4 Likes
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.
Yes, you are correct in your analogy. This ERC introduces interfaces that can be thought of as legos for on-chain data.
2 Likes
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)
2 Likes
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.
3 Likes
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.
2 Likes
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 
4 Likes
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.
3 Likes
hahahaha yeah man! the reference implementation will be like Lego bricks for younger solidity devs 
like Meccano if you’re my age
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.
2 Likes
How is this ERC different from NFT Bound Accounts?
Maybe this is an answer that helps you a bit:
ERC-7208 (ODC): Aims at universal on-chain data management with mutable, extensible, and interoperable containers (ODCs), suitable for complex tokenization, especially of real-world assets.
NFT Bound Accounts: Focuses on enhancing the security and identity verification of NFTs by binding them to specific accounts, primarily used for digital art, memberships, and tickets.
In essence, ERC-7208 offers a comprehensive framework for on-chain data management with extensive functionalities, while NFT Bound Accounts provide a more targeted solution for securing and verifying NFT ownership.
2 Likes
Sounds really interesting. It’s an ERC721 but with a lot of extra features. I’ll take a look to it.
Thank you for taking an interest @rodaemonic ! Conceptually, each ODC is an ERC721 with extra features (mainly storage and security). The 721 interface is only a requirement for the data container contract. The Property Managers (smart contracts that manage Properties and Restrictions stored within the ODC) can use other interfaces.
Am I correct in asuming that this ERC can be used for keystore contracts? I saw a previous version of this ERC had a reference to Vitalik’s article about The Three Transitions.
I’ve read the PR… the DataStorage Library Example at the core of the ODC seems to be hard to swallow. I understand it is not a part of the ERC itself… more like a component of the reference implementation. Is this correct? Also, can you think of a simpler structure that will enable the implementation of this standard?
1 Like
Hi ….in the TokenRestriction structure, there is a variable ridxCounter. This feels a bit too implementative. If the idea is to have a Restriction ID, may I suggest a renaming of the variable?
1 Like
Why is Wrapping and Fractionalizing not a part of the standard interfaces? I saw them listed as examples of Property Managers, but they seem to be super helpful.
Hey @Ljrr3045 if you’re referring to this article, yes! To be fair, we started working on this abstraction almost a year before Vitalik spoke about the Keystore Contracts, and before ERC-4337 got accepted. This goes to show the future-proofing of the ERC-7208 =) The three transitions speak about
- L2s, which we have deployed our reference implementation on
- Smart Wallet security transition, which we have achieved with brillion.finance
- privacy, recovery, identity and reputation… which is also at the core of the Nexera Protocol