Created: `$= dv.el('span', dv.current().file.ctime.toLocaleString(DateTime.DATETIME_SHORT))` Last Modified: `$= dv.el('span', dv.current().file.mtime.toLocaleString(DateTime.DATETIME_SHORT))` This is a culmination of multiple thinkings about how we will use blockchains to manage global supply chains through the use of product tokens. The basics are pretty simple: a token represents a thing, a wallet represents a person or an entity, the relationship between a token and a wallet represents a claim that that person has on that thing. We can mint (create) tokens, transfer (move) tokens, and burn (destroy or lock) tokens; we can also "sign metadata" against a token which is just a fancy way of saying we can generate some information about the token, secure it with a digital signature, and later reproduce it in a way that we can prove we didn't change anything) - each of these activities is a transaction on the network. The transactions build on each other in a time series, the most resent of transactions for a given token define it's "current state" and the complete set of transactions for token are its "history". We do these things on a blockchain because blockchains are the best technology we have for managing digital scarcity. In addition large public blockchains are decentralized and so when the state of something is secured there it is nearly impossible to alter it. This entire handbook is dedicated to picking apart the implications moving supply chain operations onto an existing blockchain (note we are not proposing to build a blockchain for supply chain) - the network should be thought of as a public utility that is available to any valid organization, entity, or person to use. We will discuss the *valid* part in greater detail in [[4. Organizational Account Management for Product Token Flows]]. The principle here is that there is no single gate keeper and that being able to use the technology should never be a barrier to participation. "Product token" is a generic term used to refer to a digital identifier of a physical asset. The term "token" is fitting description in that it is defined as "something serving as in indication, proof or expression of something else; a sign" or "something that signifies or evidences authority, validity or identity". But the term "token" is also confusing because we are talking about using tokens on a network, and "network tokens" are quite different. The truth is we call them "tokens" because because they emerged within Ethereum from the definition of Ether - the "digital currency" used to pay for transactions on the network. Later on various different types of tokens were formally defined through the Ethereum Improvement Protocol (EIP) and these are often referred by their Ethereum Request for Comments (ERC) number; the 20th ERC was used to define a fungible (interchangeable) token which is what we generally accept as cryptocurrency today. *Fun fact - Ether itself does not actually adhere to the ERC-20 standard, because ERC-20 tokens require Ether to operate...* I don't intend to go into a full blown primer on various token standards here - it would be outdated by the time I publish this - but for the purposes of product tokens there are a few worth referencing: 1) ERC-20: Fungible Tokens - these are most similar to FIAT currencies, a dollar in my pocket is equivalent to a dollar in your pocket. The dollars are interchangeable. In context of product tokens these would be used to represent ubiquitous resources (like water) where you just care about a quantity. 2) ERC-721: Non Fungible Tokens (NFTs) - these are the opposite of fungible tokens, each one is unique which is why they became popular for digital artwork. In context of product tokens these would be the equivalent of unique products (like personalized medicine) where each product is distinct and unique. 3) ERC-1155: Semi-Fungible Tokens - these are non fungible tokens that have a quantity attribute. In context of product tokens these are like batch produced products - each batch is unique, but the products within the batch are interchangeable. 4) ERC-3525: Multi Token - these are non-fungible tokens that have a number of "slots" and and the slots are given certain properties (like a max quantity or a specific token standard). In the context of product tokens these could be used to help us manage serialized products that are interchangeable (it's complicated...) ### Some helpful notations: For those of us that like to visualize it's very helpful to draw token flows. These map supply chain events to blockchain events. Here is a small legend to help. ![[Token Flow Legend.png]] Of course we need a couple of other elements to model out a flow - the wallet is where the tokens are mapped to, the data base is where the metadata is stored, and the report is what we humans might want to look at to make sense of it all... ![[Token Flow Elements.png]] Combining these elements we can sketch flows that can be pretty simple (this one would be for a plastics manufacturer that uses a combination of new - virgin - materials and recycled materials to make a new product). ![[Simple Token Flow.png]] When trying zoom out a bit to a multi-tiered supply chain things get a little more complicated, but the basic functions are the same. ![[Multi-tiered token flow.png]] ### Diving deeper So if you are with me so far you probably realize that there is a lot more needed to make this all work. That's why there are several chapters in this handbook! [[1. Token flow - managing product tokens with a claim-states table]] dives into managing multiple claims on a product token; for example the difference between ownership and custody... same product, different claims. [[2. Private Transfers of Product Tokens]] this one is a doozy... all of this only works if the network where the tokens are defined and transferred is easily accessible - so that means a public blockchain. But on public blockchains all of the transactions are visible to everyone. Doing product tokens there would be like publishing your production schedule and all of your available inventory to everyone (including your competitors) so we need a way to have confidential transactions on public networks. Disclaimer: there are several approaches being evaluated here, I've documented just one. [[3. Token Claim Derived Authority (TCDA)]] accessing the information about a token - both its's history and any metadata associated to it - is a critical aspect of this whole thing. But traditional access controls would require a gate keeper. TCDA is a way to bake the access control layer into the network. [[4. Organizational Account Management for Product Token Flows]] this is probably going to be one of the most complicated areas for organizations to agree on. Within a given company who will control which wallets. ### Other readings This post is meant to convey my latests thinkings about product tokens - I often write different perspectives to explain different concepts, and I reserve the right to change my mind! My other posts on this site are a few different aspects of the same theme.