ERC-7208: On-chain Data Container

Hello Magicians,
Today we are excited to introduce ERC-7208, a set of interfaces that we call the On-Chain Data Container (ODC).

An ODC is an on-chain data container that houses both data and metadata and can be modified (mutable), expanded upon (extensible), and integrated with other assets (composable). Furthermore, it can be characterized by specific Properties, governed by Restrictions, and can trigger certain actions through Hooks. As ODCs are mutable, they can be split and merged, fractionalized, and the Properties within them can be attached or detached. The programmability of ODCs is abstracted into Property Manager smart contracts, enabling the implementation of multiple interfaces for the same stored values.

Cohesion Through Standardization

As the Ethereum landscape evolves, we’ve witnessed an influx of ERC standards targeting niche use cases. ERC-7208 aims to provide a universal interface for on-chain data management, irrespective of the ERC implemented on the specific use case. In particular, by bridging interoperability gaps between existing token standards. For example, consider the tokenization of a luxury car rental. Use cases like this would probably require the implementation of many moving parts, each one of them with its functional requirements. But if we focus just on the formalization, this use case calls for the interoperability between 1) rentable NFTs (ERC-4907), 2) a security token (ERC-3643), and 3) a compliance system (using one or several standards). The issue that this solution presents, is that once it is built, the ERCs are fixed and the product is not necessarily interoperable with other solutions (i.e. a DEX would have to implement compatibility with the three standards, in a specific way, to be able to support a listing of this type of product. There is no standard interface for interacting between standard interfaces, and this is why we are presenting ERC-7208. Custom solutions that once were necessary for interoperability can now be streamlined through ODCs, facilitating interactions across different standard interfaces.
Now and then, we see a stream of new ERC proposals flooding the ecosystem. At the time of this writing, there are over 50 new ERC proposals that have been introduced in the past three weeks. If we continue with the previous luxury car rental example we can imagine a scenario where soon, there will be a new standard proposal, this time for the specific tokenization of the rental of real-world assets (cars) that are rentable. This is a big problem for the ecosystem, as it would be standardizing a use case rather than the interface required for a cohesive interaction between smart contracts. The main motivation driving ERC-7208 resides in future-proofing all previous ERC interfaces, making them interoperable with their future counterparts by enabling the logic specific to each implementation to work independently of the stored data they require.

Abstraction of Logic from Storage

At the core of the ERC-7208 is the conceptual abstraction of logic from storage. This means that a storage variable with a value can represent multiple things concurrently, depending on the implemented interpretation. For example, a uint Property with a stored value of 100 within the ODC can represent both 100 USDT and 100 USDC concurrently, by utilizing two different contracts which can manage their respective interfaces (Property Managers).

Properties in ERC-7208
Properties within ERC-7208 are central to its functionality. They are modifiable units of information stored within On-Chain Data Containers (ODCs). These Properties can store various types of data, such as bytes32 key-value pairs, sets of values, and mappings. This flexible data structure enables dynamic management of information related to tokens, including ownership details, identity information, programmable rules and triggers for how to handle the information itself, and more. Properties empower developers to implement complex, mutable states for tokens, reflecting changes over time. This versatility makes ERC-7208 particularly effective in tokenization scenarios, especially for real-world assets that often require complex and detailed data representation.
In our luxury car rental example, the cars can be represented with ODCs. One possible representation would be to store Properties with the storage values of the ERC-4907, the ERC-3643, and the compliance rules the car ownership (and rental) has to abide by. Property Managers would be used for managing the logic that governs the stored data.
More often than not, users are represented as addresses or SBTs. We can think of a scenario where they are represented by their ODC UniqueID, and the information stored within it. If ERC-3643 is being used, then OnchainID must be implemented… but what if the company has other identity requirements? Well, they could be stored as Properties, and exposed through a Property Manager implementing the OnchainID interface.

Restrictions in ERC-7208
Restrictions in ERC-7208 provide a cohesive layer, dictating how Properties can be altered. These include transfer restrictions and lock restrictions, ensuring that changes to Properties adhere to predefined rules. This mechanism preserves the integrity and intended use of the data stored within the Properties. Coming back to the luxury car rental example, users being identified with a token will have a Transfer restriction on the identity Properties within their ODCs. Additionally, users themselves can configure access Restrictions to limit who can read the information stored within those identity Properties. Moreover, the tokenized car’s Properties may have Restrictions, limiting access to just the owner for data such as mileage, the status of components, the last service date, or the price for which it was last rented. Lastly, lock restrictions can be employed when an asset is staked for a given period or when an asset undergoes fractionalization and new tokenized fractions are minted. By using Restrictions and Properties in this way, the whole luxury car rental business itself can be represented as an ODC. In other words, data can be streamed directly to Properties and Restrictions will apply when accessing sensitive data.

Metadata Exposed from Properties
Some information is worth storing on-chain. However, we see the majority of on-chain tokens that make use of Metadata use it to store data off-chain. Continuing with our example, a fair solution would be to use a dynamic NFT for representing the car, where the off-chain metadata can be updated to reflect the information about the current driver, model number, and year of manufacturing. This solution, although acceptable in some scenarios, comes with a major limitation: the metadata is not actionable by smart contracts. Data that would otherwise be usable or accessible (actionable) by smart contracts is stored off-chain. By storing additional on-chain data related to ODCs, this ERC addresses this limitation by exposing Properties as a procedurally generated Metadata JSON. This on-chain metadata generation can include all Properties and Restrictions. Information like the asset’s name, description, a default URI, or the asset’s own URI updated in real-time, can be retrieved from the ODC and shown as Metadata. ODC’s metadata is programmable and is dynamically rendered from within the ODC. This hits two birds with one stone: 1) it enables smart contracts to interact with richer, actionable data stored within Properties, and 2) the tokenized asset becomes a self-contained entity, where data and metadata live within the same space (on-chain). And if there is a need for some resources to be stored off-chain, a reference to them can be stored within a Property, which would be rendered within the Metadata (i.e. a link to IPFS where to store the photo of the car).

Property Managers
In ERC-7208, PMs are smart contracts that manage data within ODCs. They are vital for maintaining the structure and integrity of the data stored in Properties. Property Managers are responsible for enforcing Restrictions and managing the data following predefined rules and protocols. PMs are categorized based on their access to Properties. This categorization, managed by governance, allows for organized and secure interaction with ODCs, mitigating the risk of unauthorized data manipulation. Categories help define roles and permissions for Property Managers. Therefore, they are the governance layer for data within the ecosystem.

Examples of Property Managers

  • Wrapper Property Manager: Manages the bundling and unbundling of various asset types into a single ODC, increasing composability and interoperability.

  • Fractionalizer Property Manager: Enables the creation of fraction tokens for a specific ODC, particularly useful for assets that require fractional ownership, governance, and shared participation.

  • Oracle Property Manager: Streams data from Oracles directly into Properties, updating them with real-time information like asset prices, arbitrary data that can fit within the ODC and may be relevant to use-case-specific logic (Impermanent Loss, weather conditions, position within a map, etc).

  • Identity Property Manager: Manages Credentials stored within Properties, where Restrictions apply based on identity within the ODC. Signatures and Verifications can be based on zero-knowledge proofs and Verifiable Credentials, enabling Identity Management without exposing any personally identifiable information. With this kind of PM, Self-Sovereign Identity solutions can be integrated regardless of the implementation, ensuring security and privacy for other standards.

  • Rules Engine Property Manager: This component enables the definition of rules that govern how information is allowed to flow between ODCs. Rules are smart contracts that can be triggered by a call or delegateCall and often return a boolean with an approval value. For example, in the case of zero-knowledge proofs of residence, a rule can be an on-chain implementation stating that the country of origin is not within a sanctioned list. “One of many”, “many of many”, and “none of many”, are examples of rules that can be verified to achieve Regulatory Compliance requirements with governmental institutions, even across borders.

  • Recovery Property Manager: Can be developed to support partial or full recovery of ODC based on Identity, regulatory framework, estate planning, and other customizable triggers.

  • Real World Asset Tokenization: If we combine the Abstraction of logic from Storage, the dynamic generation of Metadata from on-chain actionable data, together with the privacy-preserving self-sovereign identity storage, we can achieve a regulatory-compliant tokenization of real-world assets. For example, in Arkefi ( ODCs are being used to represent fractionalized ownership of real art pieces. Property Managers are used to comply with regulations and to govern the financing, investment, acquisition, and buy-back options. In AgriFi (, each user owns their ODC, which acts as a non-transferrable data container. Property Managers are utilized to represent the flow of assets (crops, investments, and debt), and to implement the logic that governs the use case, adhering to regulation and without exposing any private information.

A mechanism for Account Abstraction
Over the past few years, much has been discussed about Account Abstraction, especially with the approval of ERC-4337. We propose that data is at the core of any concept of an account. It is the on-chain data the one that represents an individual on-chain. The digital self is derived from digital interactions on-chain. This applies to accounts, and individuals, but also applies to entities like businesses, institutions, intellectual property, and the business of renting tokenized luxury cars. Using ODCs the digital self is not represented by an account but by a composition of the data stored within the container, the rules that govern such data, its rules, Properties, and Restrictions.

Nexera Protocol (default implementation)

The default implementation of ERC-7208 we are introducing has several added features outside of the standard interface. It is based on the Solidstate implementation of Diamond (ERC-2535), and it introduces identity management, a programmable rule system for managing Properties and Restrictions in a compliant manner, wrapping of native assets as well as other ERC tokens, fractionalization, splitting, and merging of ODCs, dynamic metadata exposing the ODC’s internal stored data, an Oracle PM capable of streaming data and delegating calls through triggers, programmable recovery rules, and a Smart Wallet system (being actively used on

This design choice empowers a more efficient and scalable approach to tokenization, especially for real-world assets, which often require mutability, interoperability, and compliance with regulatory frameworks. For instance, it can enhance ERC-1400 by providing dynamic data management for security tokens, or work alongside EIP-2615 to enrich swap orders with additional data capabilities. This interoperability extends to other standards like ERC-4885 (Fractional Ownership), enabling more efficient and transparent management of fractional ownership.

Although we have a default implementation live, audited, and with several use cases implementing it, this standard is still in draft and will likely be amended with the community’s input. We’re eager to hear your thoughts and feedback on ERC-7208. Your insights will be invaluable in refining this standard.
We are looking forward to a lively and insightful discussion!


BOSS moves. Confidence in this team only growing. No mercy.


Great breakdown and technical overview of the overall vision of the AllianceBlock project, very exciting to see it at this stage :pray:


Amazing work the #NXRA team is doing!


Man! this provides a comprehensive and insightful overview of ERC-7208 , particularly highlighting the innovative approach of On-Chain Data Containers (ODC) in enhancing data management and interoperability across various token standards. I think tht its impressive how this delves into the technicalities while also considering practical use cases like the tokenization of real-world assets. RWA needs this in my opinion.

I’m curious about the potential impact of ERC-7208 on the broader Ethereum ecosystem. how might the introduction of ERC-7208 and its On-Chain Data Containers influence the development and deployment of decentralized applications (DApps), particularly in terms of scalability and user experience?


…a comprehensive and well-thought-out proposal! The concept of On-Chain Data Containers (ODCs) and ERC-7208’s focus on standardization and interoperability make a lot of sense, especially in a rapidly evolving Ethereum ecosystem with a constant influx of ERC proposals.

I appreciate the attention to detail, especially the abstraction of logic from storage, the versatility of Properties, and the role of Property Managers. The use case examples, like the luxury car rental scenario, add practical context to how ERC-7208 can streamline complex interactions.

The approach to expose Properties as procedurally generated Metadata JSON on-chain is a smart move, addressing the limitation of off-chain metadata storage. The variety of Property Managers, such as Identity and Rules Engine, showcase the flexibility and extensibility of the proposed standard.

…examples of real-world asset tokenisation using ODCs and the default implementation with added features demonstrate a thoughtful consideration for efficiency, scalability, and compliance. Overall, ERC-7208 seems like a promising step towards a more cohesive and adaptable on-chain data management solution. Kudos to the team!


Love how projects keep innovating, the RWAs sector is critical to DeFi.


Very informative read on ODC’s. Thanks for giving insight on the topic. Love to see this as the new standard!


Unlocking seamless interoperability, abstraction of logic from storage, and empowering dynamic tokenization scenarios. Innovation in the Ethereum ecosystem always exciting :raised_hands:


A great read, thanks for the informative information.


I too think that this is not necessarily restricted to real-world asset tokenization. it could enable some wider-reaching applications.

A good example would be digital asset tokenization in on-chain gaming applications. Think of a character or avatar as an ODC with the PMs managing all the various abilities, powers, or assets of that avatar. I also wonder if the generated JSON metadata could be harnessed to render certain assets in digital space and thus removing the need to store assets in centralized cloud storage.


This is very smart. No mercy!


ODC can replace a wallets of all sorts eventually, can it?


As someone who talks with a lot of companies that are looking into RWA tokenization, I can safely say that ODCs are much needed and will open op a wide range of new business opportunities to the Ethereum community and beyond. From a professional and business perspective, I see this as the next much needed evolution of NFTs. I have explored ODCs with businesses from different industries, from creative businesses looking into creative NFT use cases, all the way to dynamic licensing companies, real-estate and carbon credit projects.

All these businesses have one thing in common, they want this!

As I am personally very biased, in favour of this proposal. I would also like to hear from the community what potential ‘drawbacks’ could be. In what scenario would you prefer a different standard instead of this one? And when would you use ERC-7208?


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?


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?


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


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?


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


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)