Development of a Token Concept.

This is a document part of the Food traceability Fund11 proposal milestone 1.

Food Traceability by Cardano Proposal funded Project Catalyst Fund 11

Development of a Token Concept.

Cristian Rojas

Industrial Engineer, Latam Cardano Community and Intersect MBO Member , Project Catalyst Proposer [e-mail]

At the core of traceability systems are identifiable and traceable objects. Therefore, a blockchain-based traceability system relies on traceable asset tokens as its foundation. Thus, this initial step involves developing a token concept that establishes a basic structure enabling the integration of all object-related supply chain events.

Existing dApp architectures demonstrate the effectiveness of NFTs based on the ERC-721 standard in identifying objects within supply chains. However, these tokens exhibit weaknesses when their minting depends on conditions involving other tokens.Other solutions refer to smart contracts containing minting conditions as 'token recipes'. In supply chains, this weakness often arises when mapping batch productions that involve assembling parts. The challenge lies in the inability to predict token addresses, resulting in token smart contracts only being able to include required tokens after their minting. This issue is negligible for single-lot assemblies. However, it significantly increases mapping complexity for producing non-fungible assembly batches that aggregate inputs of the same type since each assembly necessitates deploying an individual recipe contract.

The ERC-1155 standar addresses this issue to some degree, but primarily for fungible batches comprising fungible components. While the ERC-1155 standard permits the minting of non-fungible token types, it facilitates the minting of a collection of fungible tokens of the same type. Consequently, the ERC-1155 standard lays the groundwork for incorporating token types as minting conditions in the token recipe when mapping tokens representing assemblies. Compared to the ERC-721 standard, the ERC-1155 standard simplifies the complexity of mapping fungible assembly batches that aggregate fungible inputs of the same type, as one token recipe can mint multiple assembly tokens in this scenario. However, when mapping multiple non-fungible assemblies of the same type with non-fungible inputs of the same type, the ERC-1155 standard encounters the same limitations as the ERC-721 standard.

Hence, there is currently no token standard and associated logic that efficiently facilitates the mapping of non-fungible assembly batches of the same type, which aggregate non-fungible inputs of the same type. Figure 1 illustrates the necessary interaction between NFTs and minting conditions for assembly processes. As depicted in the example, it essentially necessitates a token concept capable of minting batches of NFTs of the same type with a single smart contract or not. This approach enables the inclusion of the NFT types of inputs as minting conditions, allowing one token type recipe to mint multiple non-fungible assembly tokens of its type.

This document proposes adopting Cardano native tokens as architecture, users can create native tokens that will serve the above-mentioned purposes and in addition, it is possible to create unique (non-fungible) assets representing value like real estate or intellectual rights.

Unlike ERC20 tokens, the tracking and accounting of native tokens is supported by the ledger natively (ERC20 tokens require smart contracts to achieve the same thing). An important benefit of using native tokens is that they do not require smart contracts to transfer their value and can be transferred alongside other token types. Also, unlike ERC20, native tokens do not require special transfer fees or additional event-handling logic to track transactions.

Cardano is part of the third generation of blockchain. Via the extended unspent transaction output (EUTxO) Model, Cardano blockchain allows the implementation of minting policy at the creation of the token. Cardano also allows abstractions of transactions thus allowing to add metadata to the transactions. At the first stage of token creation, minting, the information that is stored in the token file and metadata are now saved into the blockchain with a transaction signed with a wallet. The minting policy is the set of conditions under which tokens are minted (or burned) and can define a fixed or continuous supply. The minting policy has a specific policy ID that can be retrieved on the blockchain and uses a unique seed phrase only known by the policy owner that prevents the token from external modification. With the minting policy, third parties will lock the token to be modified, re-minted, or burned. The same information can be verified and minted and sent by several qualified stakeholders under the same asset name that will keep information redundancy and increase the trust in the food production.

Figure 1. Structure to create traceability on Cardano Blockchain

Figure 1. Structure to create traceability on Cardano Blockchain

Integrating Object Events

Object events encompass two primary sub-events: creation and deletion. When translated into a blockchain-based architecture, this necessitates the functionality of minting tokens for creation and deleting them when necessary. Consequently, on a system level, object events mark the inception and termination points for tracking objects throughout their lifecycle. They establish the structural framework for all object-related supply chain events mapped by the architecture.

In practice, food producers will be able to query a third party to verify their documentation (Know your Business — KYB procedure). Third party will review and validate the information before minting the non fungible token. the token with their own policy ID, wrap the food producer policy ID and the asset type in the asset name, then add the necessary metadata content before minting the token. By analogy, third party verification will check for third party certification business information and send them a token with their own policy IDs. Federated third party verification can register all verified policy IDs in one or several on-chain text files inside a non fungible token that will be regularly updated. In this way the verified policy IDs are not made by one entity but governed by several federated parties.

Non fungible token asset names keep a structure composed of third party verification policy id, receiver policy id and type of token. Fungible token asset name will include the agent policy id and type of token.

A single policy specifies both minting and burning conditions of tokens scoped under it. Adherence to it is checked both at the time of minting as well as burning.

Figure 2.Integrating object event

Integrating Aggregation/Disaggregation Events

While minting tokens represents object events without conditions, on a system level, the aggregation of tokens signifies object events that occur under the fulfillment of specific object-related minting conditions. In EPCIS, aggregation events create a new entity that includes the input objects. From that point forward, the aggregated objects occupy the same location simultaneously, both physically and on a system level. The architecture seeks to replicate this situation in a token data structure, specifically to enable the traceable disaggregation of tokens at later stages.

Native tokens can be linked to create a more complex system of relation and services. A Cardano native token of a certification can be directly bound to the native token of a food product via a metadata bound that can attest the product quality, certification, test, origin that serve as proof.

This bound is encoded and specialized to understand the link between tokens. For example, FoodOn ontology used “certified”, “has part”, “has quality” to qualify relation between elements. The token policy ID will serve to identify the token provider efficiently thus policyID must come from a third party certification recognized by stakeholders in order to create trust on the document and on the product.

Figure 3.Token asset relation adapted from FoodOn relation

Integrating Transformation Events

Typically, data related to an object’s type remains static, while the individual objects themselves can change state, such as in quality, approvals, or processing. Unlike aggregations, which create a new token with a new identifier, transformations retain the same identifier and merely update the token-related metadata. Applying this concept of token transformations to the architecture necessitates a mechanism for updating the tokens' metadata. The possibility for each token to undergo transformation events highlights the need for each token to have unique metadata, rather than just a copy of the blueprint’s metadata, which usually represents static data describing the token type.

Transaction metadata can efficiently report the operation made on a product and follow a standard for interoperability along the supply chain. Metadata labels that contain a numeric value can be encoded to contain the type of transaction, (for example “Transfer to cold chain/retailer/storage/manufacturer” . Metadata content is a short string (64char) that contains the product change . This metadata content can point to an IPFS folder (for example: “QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D”) that will contain immutable information about the product. Following a standard, this metadata content folder could describe product transformation (physical/ chemical changes), contain information generated by IoT about the product environment (light,temperature,humidity) or transport (vehicles,location, duration) shared between stakeholders. The transaction metadata content can also point to a private server or contain a hash of the information to maintain privacy.

At the product transformation, the process should also be stored in metadata bound and obey to a metadata standard. The burning transaction of the token refers to the policyID of the manufactured product. The manufactured product will be bound with the raw material (part/parent) token (such as “as part”) by referring to the token burning transaction. Part tokens will be burned and the manufactured token will be produced in stoichiometric quantity. These two mechanisms will protect information integrity during the product transformation.

Integrating Transaction Events

In the blockchain all transactions and wallets are stored on the blockchain and possess unique addresses. Blockchain helps to store the product trace by keeping the information on the ledger by the physical owner of the asset. This authentication brings more certainty and interoperability on the data stored about the asset, in turn that becomes more valuable.

Cardano native tokens can support product traceability. At the product transfer, the transaction differentiate a lot of products from another lot. Thus every lot of products can be identified by a unique transaction. From the most recent transaction, a native token can be traced back to the minting transaction, allowing a product auditability. This unique latest transaction can be integrated in a QR code (for example ‘6bfe43e4ec5242d82fb18419eac21b4098c099b2fb11bada9280a97eccab049a’) for consumer to check the physical product full traceability. All Stakeholders participants are identified by their wallets staking address or policyID. To help this identification a system based on users wallet should allow them to add information to clarify the role of every participant in the supply chain and enforce transparency and auditability.

Figure 4. Decentralized traceability system description

Integrating a Token History

Although existing token standards emphasize secure input and interface design, they lack efficient methods for conducting history searches. To gain visibility into tokens’ histories, one must search the blockchain’s metadata, usually via a blockchain transaction explorer. Consequently, the complexity of traceability can increase significantly depending on the length of tokens’ life cycles on the blockchain and the complexity of their event sequences. This complexity contrasts with the primary objective and requirements of traceability systems, which aim to ensure clear traceability of objects' composition and processing.

Transaction metadata content can efficiently report a transfer made on a product by using a metadata bound. For traceability metadata will indicate the product and amount that is transferred (token id), the receiver (staking address) and the previous transaction id (tx). Then from the latest transaction and transaction by transaction go backward until the first transaction, verify all exchanges and make sure that the first wallet is the original product owner. This operation can be done efficiently automatically using a blockchain explorer.

Cardano native tokens are efficient to store information about food traceability. We can therefore use Blockfrost to retrieve all the information about the digital twin transaction and display them for consumer and buyer to analyze timeline and origin of product. In the case of food products it can help to get the food product freshness.

Figure 5. Cardano native token history