Can "ERC721 protocol" be used for supply chain traceability and integrity?

Question

As I understand it, ERC721's, also known as NFTs (Non-fungible token) are tokens where each one is unique. The individual tokens often come with metadata.

They're usually indivisible (ERC20s you can usually have as little as 1*10-18 of it, but ERC721 you can have multiples of 1). An example: a game where you have an inventory. All the different items in the inventory could be considered NFTs, where you have 5 arrows, a sword, a fish, etc.

Another example is of course CryptoKitties. A kitty is an NFT with metadata that isn't divisible (you can't sell someone half your cat...) ELI5: Tradeable assets that are unique from each other. Houses, cars, rare/unique collectibles. Baseballs could be traded as NFTs where a baseball has metadata related to all the players who pitched it, who it's signed by, etc.

The fact that each token can have metadata attached to it, means we can store specific data relative to the factory, supply chain, production chain, producer etc etc in the metadata as a proof of integrity, right?

Suppose we are talking about a production line of pils or vaccine or meat or anything produced in mass, we can insure the integrity of the product by storing specific data (producer, date time of production, unique identifier) in the metadata that we can send in the transaction in our blockchain and then verify at any moment the metadata via our blockchain explorer.

is all that scenario possible with the ERC721 or am I just imagining thing?

Answer 1

Short answer: yes, it's possible to use non-fungible tokens (NFTs) which support ERC721 standard for supply chain.

Long answer: Yes! But first things first. ERC721 is just a standardized interface which ensures some interoperability between apps that work with NFTs. It would be hard to support hundreds of different non-fungible token contracts if each of them would have its own set of rules and methods. Now, even if you pick ERC721 standard there are many ways how to implement a NFT token contract which could be applied to supply chain.

One simple example: each NFT represents a product and can hold a list of meta-data records (on-chain):

1. First meta-data record is factory and product information (location, timestamp, materials, etc.).
2. When this product is sent to a warehouse, we imprint (on-chain) new meta-data with transportation company and warehouse information including pickup and delivery times.
3. Previous step could probably repeat a couple of times before our product gets to a store. And here the same thing happens - we add another record of meta-data about the store, date, etc.

This all looks good, except in reality all the meta-data that we pushed on-chain add up really fast! So, the first step is to reduce the size - instead of raw meta-data, we store only hash digests of raw data. Let's call them proofs:

1. Factory:

   • meta-data: hash({"companyName": "Foo", "address": "...", ...}) -> "proof1"
   • NFT meta-data is a list of proofs: ["proof1"]

2. Delivery 1:

   • meta-data: hash({"companyName": "Bar", "timestamp": "...", "containerNo": "...", ...}) -> "proof2"
   • NFT meta-data: ["proof1", "proof2"]

3. Warehouse 1:

   • meta-data: hash({"companyName": "Bar", "address": "...", ...}) -> "proof3"
   • NFT meta-data: ["proof1", "proof2", "proof3"]

...

10. Warehouse 10:
    • NFT meta-data: ["proof1", "proof2", "proof3", ..., "proof10"] <- A chain of "proofs"

This is much better than storing the original meta-data on-chain. However, now we have to store raw data somewhere off-chain where interested parties can query it and validate (by using the proof which is on-chain). You could go even further and look into side-chains in order to further reduce the costs of transferring and storing data on-chain.

Disclaimer: I'm a part of the team who works on open source 0xcert protocol for non-fungible tokens. One of the supported use cases is supply chain (using ERC721 NFTs: https://github.com/0xcert/ethereum/blob/master/contracts/tokens/ChainableXcert.sol) and the example above briefly describes it. It's currently under heavy development (alpha release probably a month away) but it might still be helpful/interesting. You are welcome to take a peek/open a PR/Issue: https://github.com/0xcert/ethereum

Answer 2

Yes, this is possible with an NFT.

Firstly, it's important to note that NFT and ERC721 are not the exact same thing, the ERC721 Standard is just a set of rules for making your NFT easy for other people/apps/contracts to interface with. But you can have an NFT which is not ERC721 compliant, but is still a perfectly valid and working NFT.

With that in mind, I'll answer your question first without mentioning ERC721:

The fact that each token can have metadata attached to it, means we can store specific data relative to the factory, supply chain, production chain, producer etc etc in the metadata as a proof of integrity, right?

Yes, you could create a smart contract which allows all of these bits of data to be attached to your NFT. Storing small amounts of data on-chain is probably fine, but if you're going to be storing anything sizable, you probably want to store that off-chain and on-chain only store a reference to it, and maybe its hash.

Suppose we are talking about a production line of pils or vaccine or meat or anything produced in mass, we can insure the integrity of the product by storing specific data (producer, date time of production, unique identifier) in the metadata that we can send in the transaction in our blockchain and then verify at any moment the metadata via our blockchain explorer.

Precisely, once the data is committed to the blockchain, it is immutable. Then anyone along the supply chain could check to make sure their records match up with the "true" record.

If you are dealing with many parties, you would probably want to develop an easy to use/check/understand interface for verifying data though because much of blockchain is not very intuitive for the non-tech-savvy.

Now for ERC721:

As I said earlier, the ERC721 standard is just a set of rules to which your contract code has to adhere in order for it to interface easily with other things. You can see the rules in the link posted above, but it's important to note that there is nothing in the standard that says you can't add other things that aren't covered by the standard.

Part of the ERC721 standard includes the optional ERC721Metadata addition. This just adds a token Name, Symbol and a Metadata URI for each token. I suspect this is not what you need for your purpose, but there is nothing preventing you from ignoring this addition, adding your own methods for storing data like production date etc for each token.

Answer 3

This scenario should be possible with ERC721. That said to be cheaper and more useful I think the additional concept of a "class" is needed. A class could be the pill - all pills could have the same metadata. As far as I understand ERC721 is thought for use-cases where all tokens are different (like cryptokitties) - but in the case of provenance a class of things can be useful as there are batches of things with the same properties (unlike cryptokitties)