IOTA for Inventory ManagementAPB360
IOTA is being considered for our next-generation ledger of things.
Paper is for targets.
Blockchain for ledger? Sounds nice but there are some show stopping issues with blockchain technologies that exist today. Aside from the scaling issues of blockchain, there are transaction fees associated with every coin implementation, especially smart contract currencies.
In the world of mission critical record keeping for firearm manufacturers, law enforcement, public safety, and military organizations; a fully decentralized ledger is our 2018 mission at APB360, using IOTA and the Tangle.
“IOTA is a futuristic protocol in distributed ledger technology. It is more than just a cryptocurrency. Even as a cryptocurrency, with it’s zero transaction fee, unlimited scalability, ability for nano transactions and quantum resistance, IOTA overcomes all the limitations of traditional cryptocurrencies like Bitcoin, Ethereum and Ripple. It works on a technology called DAG (Direct Acyclic Graph) and the IOTA implementation of DAG is called ‘Tangle’. IOTA has the potential to disrupt the entire financial, database management systems of the world by enabling micro/nano transactions in the IoT (Internet of Things) , as a facilitator in the IDoT (Identity of Things) , as a replacement to money in human to human transactions, in secure messaging, data storage, data security and validation.” –Medium Article
If you are interested in our intended architecture and would like to participate, please continue on.
APB360 currently manages millions of assets and custody records. For every asset, it is common in manufacturing to have multiple acquisitions and dispositions. The current APB360 implementation of the Acquisition and Disposition (A&D) ledger is a highly available, geographically clustered, distributed database with heavy redundancies. This results in many millions of rows across hundreds of normalized schemas. For every asset, there is likely 4 to 6 different A&D records.
For every asset, depending on if we are referring to the law enforcement version of the ledger engine, or the Federal Firearm Licensed (FFL) manufacturer or distributor version, an acquisition record must exist at minimum for every asset. This record is supplemented with a variety of useful meta, but most importantly, the serial number, manufacturer of record (Make), the model, the type, caliber, the source of acquisition (where from), date, active storage location, and potentially a manufactured date and licensing information. This is the start of the chain of custody, and FFL users are legally liable to maintain these records in an immutable fashion. Failure to comply is costly, federal entities can close your business and take your freedom away.
The nature of the Tangle provides the “unchanging over time or unable to be changed” requirement for ledger purposes. In addition, the IOTA implementation is a fee-less network of many nodes, all providing consensus for transactions. Now that we have that covered, let’s talk about implementation.
For every asset, there is a seed. For every acquisition source and destination, there are also seeds. The APB360 database will have to track and manage these private seeds in the millions.
IOTA has total fixed supply of 2,779,530,283,277,761 units with zero inflation. If we utilize one IOTA for every asset and custody source, we will barely deplete the money supply. A million IOTA’s (Mi) is currently trading around $3.70 (12/29/17).
Here is a PoC scenario to work with (a more complicated than necessary example):
- A Glock 17 9mm Luger, serial number 123, is purchased from Company A and stored in an active location (safe) on premises.
- An armorer (employee) extracts the Glock from the safe (serial# 123) to inspect and prepare for employee assignment
- An employee is assigned the firearm for a qualification shoot and ultimately for duty
- Time passes, and the firearm needs preventative maintenance. The employee returns the firearm to the armory employee
- The armory employee accepts the firearm and places it in the safe, it will be several days before the firearm can be inspected.
- The armorer extracts the firearm, serial 123, from the safe to do work.
- After the work is completed, the armorer returns the firearm to the safe.
- The employee is contacted to return to the armory to get the firearm. The armorer then extracts the firearm from the safe.
- Finally, the armorer assigns the firearm back to the employee for duty.
This represents 9 records in the ledger. Note how the firearm is treated in this example as a constant flow from Acquistion to Disposition. As it enters an individuals hands or enters a physical storage location, the event must be recorded in the ledger. Using RFID and NFC, or 2D barcodes, the bureaucracy of all this is pretty much eliminated. But there is one particular thing to note, the high fidelity of custody records. If the firearm location status is “On Premises”, it cannot be Acquired again. This is a constant opportunity to correct the real chain of custody.
For example, the employee returns the firearm to the armorer, but the firearm ledger shows that it is still on premises. How can this be? The armorer didn’t perform the correct operating procedure to assign the firearm back to the employee, and APB360 makes it clear to them. Enter IOTA.
- An asset is acquired from a vendor. Every asset is born with 1i.
- A SEED is created for that asset and a wallet is attached to the Tangle.
- APB360 transfers 1i to the asset wallet.
- The location for storage is given a SEED, and a wallet is made and Tangle attached. The asset is stored in a safe, and the safe’s wallet receives 1i
- An asset is inspected.
- A SEED is created for the armorer because the armorer is going to take custody of that asset and a wallet is made and attached to the Tangle.
- The safe wallet transfers 1i to the armorer.
- We know the asset is in employee custody (off-premises essentially) because the asset’s seed/wallet has zero balance and a historical transaction to the armorer (trace)
- The armorer completes the inspection and returns the asset to the safe.
- The armorer’s wallet transfers 1i to the safe’s wallet
- An employee is coming to the armory for the firearm, the armorer removes the gun from the safe.
- The safe’s wallet transfers 1i to the armorer’s wallet
- The employee arrives to acquire the firearm.
- The armorer’s wallet transfer 1i to the employee.
You probably get the idea. The wallet balance servers as the fidelity checkpoint. If the wallet has no IOTA, it shouldn’t have the asset. The big question is:
- Will we make a seed/wallet for every transaction, and when they are zero, the chain of custody should have a continuation?,
- Will we allow for employees and or locations to have one wallet with several IOTA, and depend on APB360 to decipher what should be with them or not?,
- Or should we have one wallet, transfer IOTA to itself, and simply store the transaction hash in a database to correlate to something?
- I’m sure there are more, which is the point of writing this blog post.
In case #2, the safe or designated storage location could have thousands of IOTA, each IOTA representing an asset. In addition, the armorer could have several IOTA. Also, the employee as well could have several dozen IOTA. Often, LE employees will have several firearms, OC spray, tasers, taser cartridges, body armor, holsters, belts, helmets, and more. Each asset would have a seed identification, and chain of custody would be in the Tangle.
Tangle communication would exist using micro-service architecture talking to our own nodes, asynchronously, to avoid being a bottle neck during the work flow. Like a batch job. However, checking an asset or employee wallet would be real-time while consulting the APB360 engine.
Feasible? We invite you to communicate with our team on Slack on the #iotatangle. Look for @Adam Lyons or the APB360 channel on iotatangle’s slack (#apb360)!
Comment below with your IOTA address or connect direct, quality feedback will receive IOTA!