Temporary Aggregation of Different Assets in Supply Chain

+1 vote
Let's say I have two different real world items (e.g. a racket and a ball) and I issue each of them as a new asset type with quantity 1 to make them NFTs (https://www.multichain.com/qa/12997/non-fungible-tokens?show=12999#a12999).

Now I want to ship them together in a box from A -> B -> C. When C receives the box they should be able to open it and get the items back. How can I make sure the items cannot be separated while in transit? Does it make sense to issue a new asset for the box? I can't send the racket and ball assets to a burn address as is recommended here: https://www.multichain.com/qa/1913/asset-tracking-in-supply-chain-management, because I need to get the assets back in the end.
asked May 5 by MartinJaskulla

1 Answer

0 votes

If your goal is simply to send them together one time in a single atomic transaction, this can be done with a regular send or sendfrom API call, which allows multiple assets to be sent together.

If your goal is to never allow them to be separated in any future transaction, you could use a transaction filter for that. The basic logic could be for it to call the getfilterassetbalances callback for both assets, and ensure the response is the same for both.

answered May 5 by MultiChain
Thanks a lot!

Does it scale though? Let's say there are thousands of items and boxes. Seems inconvenient to publish new transaction filters for every box and then remove these filters again every time a box is opened etc.

Let's say at point B boxes are opened and items reshuffled into different boxes etc.

Would it make sense to add inline meta data to the assets describing which other items are packed with them? Or would it make more sense to publish this information to a stream? Maybe:
1. Assets with meta data type=item | box
2. Stream with e.g key=item-id value=box-id and key=box-id value=item-id-array
3. Smart filter looks up each asset id and makes sure everything is send together?
You're on the right track with streams, but transaction filters cannot read streams, because each node can independently decide which streams to subscribe to. Instead you should use variables – you could have one variable for each asset, and that variable would set the rules for that asset, which are then read by the generic transaction filter.
...