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.
propertiesOf instead of getAllProperties.)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.
Hey Sam! Thanks for taking the time and contributing.
Yes! This is correct. We will add events to the interface. Not just for Properties, but also Restrictions modifications.
This is also a great idea. We will modify the interfaces to support this naming convention.
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?
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?
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.
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.
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?
Can you ellaborate on how this ERC plans to maintain compatibility with emerging ERC proposals that might introduce novel functionalities or data structures?
Love all these questions and answers. Great to see what you guys have been developing behind the scenes.
Enjoyed the topic, sounds like the way to go for the tokenization of RWA. Good job.
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.
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.
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.
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)
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:
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.
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.
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 
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:
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.
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.