Asset Tracking in Supply Chain Management

Question

Hi,

Any inputs on how we can model parts tracking in supply chain on multichain?

Suppose we have 4 participants - Tier 3 supplier, Tier 2 supplier, Tier 1 supplier and OEM which manufactures the end goods. Tier 3 supplier supplies parts to Tier 2 which creates bigger parts and supplies to Tier 1 and Tier 1 supplier to OEM then

How can we represent this on multichain? Should we create separate assets for supplies parts or should we create just 1 asset and through meta manage their linking?

Thanks.

Answer 1

In general you should use different assets for different types of things, because all units of an asset are fungible from the perspective of the blockchain. If you want to naturally express the conversion of asset units of type A into asset units of type B, I would recommend creating a single transaction which does all of the following:

a) takes some type A assets as an input (you can use preparelockunspentfrom to isolate them)

b) sends those type A assets to the chain's burnaddress (from getinfo). This means they can provably never be recovered.

c) follow-on issues some assets of type B in the same transaction

d) if appropriate, adds some metadata to represent what is going on

So it will be a single atomic operation on the blockchain that destroys assets of type A and creates assets of type B. You will need to have done the initial issuance of the type B ahead of time, with open=true, to allow these follow-on issuances. It will also help you if the same address which performed the original issuance of type B is sent the assets of type A, so that the signature on the single input of this transaction can be used both for burning the type A assets and issuing the type B ones.

There is no high-level API to do all this in a single transaction, so you should use the raw transactions interface:

http://www.multichain.com/developers/raw-transactions/

Comments

Thanks for the reply. What if we want to use 2 assets from different addresses to create a 3rd asset like Tier 2 supplier using parts from Tier3 supplier-1 and Tier3 supplier-2 to create its bigger part?

---

You'd extend the same logic. Create a single transaction which burns both of the Tier 3-provided assets (spending them in multiple inputs, and sending them both to the burnaddress, either in one output or in two separate outputs - it doesn't matter) while simultaneously issuing new tokens of the Tier 2 asset.

If neither of the addresses holding the assets to be destroyed are the ones used to issue the Tier 2 asset, you'll need an additional input from the issuance address (created using preparelockspentfrom with an empty asset list).

In any event, the transaction will need to be signed as appropriate for each of its inputs - you can use this by calling signrawtransaction, and if necessary passing it on to other nodes which hold the private keys for other addresses.

---

Ok Thanks.
One more question, I am able to burn and create an asset in the same transaction but I am only able to attach metadata with the creation of the asset. Is it possible to attach metadata with the burn part as well?

Did the following 2 commands:-

createrawtransaction '[{"txid":"<tx1>","vout":0}]' '{"<burn-address>":{"<asset-name>":1},"<node-address>":{"issue":{"raw":<some-int-value>}}}'

appendrawmetadata <hex> '{"name":"<asset-name>","multiple":<some-int-value>,"details":{"info":"asset-creation"}}'

So how to attach metadata with the burn part as well?

---

You're right, the same piece of metadata must apply to both, since it's a single transaction. So I recommend simply using a custom field of the issuance metadata to say something about the burning taking place simultaneously. Is that a viable option for you?

---

Yes that can be done but in getrawtransaction, those details will be shown as part of the issue field even though they belong to the burn part. Ideally I would like to add separate metadata with each sub-part of the tx.

---

Understood. You have the possibility now of adding extra OP_DROP metadata into each transaction output, but MultiChain does not currently have any APIs to make that convenient, so it would require manually working on the raw transaction (there are many libraries available for doing this, since they are bitcoin-compatible).

What about allowing multiple OP_RETURN outputs per transaction, i.e. one for the issuance metadata and one for burn-related metadata. Would that be helpful? It's not possible now but could be a simple future feature.

---

Ok. Yes multiple OP_RETURNS seems to be a good option.

---

OK, it's on the roadmap. Thanks.