When most people think of NFTs, they think of Bored Ape monkeys and digital artworks, but in reality, it is a universal standard meant for much more. For example, NFTs perfectly represent real-world entities on the blockchain. An NFT can represent the ownership of a real piece of art (such as a painting), allowing it to be traded on the blockchain while the painting remains in a well-protected safe. Similarly, an NFT can represent raw materials, such as the steel needed for car manufacturing, or a container of berries that will eventually be made into smoothies.
To these NFTs that represent real entities, we can also assign metadata that provides precise information about the entity associated with the NFT. For instance, in the case of a piece of art, this could include certificates proving authenticity and ownership, or in the case of raw materials, quality statements, and unique attributes like the place of origin.
If the metadata is stored on immutable storage, then every change requires updating the metadata reference in the NFT, making the entity's history traceable throughout the blockchain. This history is unchangeable due to the nature of blockchain and immutable storage systems!
This brings us to the trace.market project, which we are currently working on in close collaboration with the . The system's goal is to allow anyone to freely create NFTs representing physical entities on the Polygon blockchain and to assign metadata to them on Swarm. The blockchain ensures a reliable product history, which can be accessed on Swarm.
From the end-users perspective, this looks like scanning a QR code (which contains the NFT ID) on the final product (such as a garment, a box of smoothies, or a car service book) using an app, where they can view the metadata and the complete history. For example, they can verify that the t-shirt was made by recycled textiles, or that the price of refurbished electronics is in balance with its defects.
The project uses standard NFTs, which are supplemented by two methods for storing and retrieving metadata:
function updateMetadata(uint256 tokenId, uint256 swarmHash)
function metadata(uint256 tokenId)
The updateMetadata method allows us to modify the metadata assigned to the token. Since the address of content on Swarm is the keccak256 hash of that content, we use uint256 for storage. As the content stored on Swarm is immutable, any change requires us to modify the metadata hash. This ensures that the complete history can be traced on the blockchain. To facilitate traceability, we are also introducing a new event:
event metadataUpdated(uint256 indexed _tokenId, uint256 _swarmHash);
The event is emitted with every change in metadata, allowing the complete history to be collected based on the tokenId.
Since Swarm has its storage incentive system, the storage fee must be covered. This responsibility always falls on the current owner of the NFT. It is in their interest to do so because if the metadata is not accessible, significantly more trust will be needed to sell the product/ NFT. Once the NFT is transferred to a new owner, it then becomes the new owner's responsibility to pay for the storage.
During the life cycle of a product, there may be events when the nature of the product changes. For example, locally grown berries are freeze-dried to serve them off-season, or a certified raw material is built into a premium product. Each activity output is detailed in a new NFT, so Industry 5.0’s smart manufacturing can be customized at scale. We refer to these in the system as transformations, and they can occur with the assistance of smart contracts.
We distinguish three fundamental types of transformations:
- 1-1 transformation: In this case, one NFT transforms into another NFT. For example, a container of strawberries becomes a barrel of juice.
- 1-N transformation (split): In this case, one NFT splits into multiple NFTs. For example, a container of strawberries is divided into two containers, which are then shipped to different countries.
- N-1 transformation (merge): In this case, component NFTs merge into one NFT. This is like when parts are shipped or assembled into a complete car.
With these three types, all transformations can be covered. The smart contract executing the transformation locks the source NFT (removes it from circulation) and mints new NFTs in its place. To execute the transformation, the smart contract can verify certain conditions. For example, in the case of a container of berries, a split operation is only permitted if the mass of the resulting new NFTs matches the mass of the source NFT. The mass measurement is performed by reliable external oracles.
We store the NFT metadata in the Beeson format developed for Swarm. The advantage of this is that it is verifiable on the blockchain, enabling the transformation smart contract to perform basic Merkle proof checks on the metadata based solely on the Swarm hash (Merkle root). For example, the full price is paid only if the product is manufactured according to a recipe that is confidential but its hash is known.
Of course, there are many factors in a transformation that may be difficult or impossible to verify with a smart contract. In such cases, permission from external oracles is required for the transformation (e.g. the location of a vessel). This could be a single oracle or a group of oracles. In the latter case, the transformation can be executed if the majority of the group approves it.
Finally, for the sake of example, let's follow this short supply chain:
First, the producer picks the bio berries and packs them into a container. Subsequently, an independent validator checks the field and its bio certificate. Photos of the Real-World Asset are uploaded to Swarm, which is linked to the NFT as metadata. Thus, the NFT representing the food is created.
Tons of berries go bad or require huge energy during logistics, so a nearby food processor is notified that a batch becomes available. A sales contract is drawn up between the processor and the producer, with the condition that if the location of the container is verified (IoT and logistics oracles, DePIN) on the buyer’s plant, the price will be paid and the buyer will be the owner of the NFT.
The processor can merge it with other ingredients, machine capacities, and recipes, so an updated NFT is generated for wholesalers and retailers. On the packaging, a QR code with the NFT ID is placed.
When a customer picks up the smoothie in the store, they can scan the QR code to download the metadata stored on Swarm, which can be authenticated based on the history stored on the blockchain. The product's CO2 and water footprint can be estimated most accurately from this metadata, supporting buyers to involve it in buying factors, thereby encouraging manufacturers to minimize CO2 emissions.
This is how the trace.market project works in a nutshell.
Currently, the project is in testing phase, welcoming API integrations to cope with the urging need for a transparent, Single Source of Truth in products’ sustainability, logistics, resiliency, quality, and custom but structured attributes. I plan to present the system's operation in depth, including the source code level, in a second article once the first version is complete.
Kudos to Balint Drahota, the PM of trace.market for helping me clarify the concept, and inspiring me with excellent use cases.
