How blockchain can revolutionize budget spending and tracking

The word “budget” arose from the Latin word bulga which literally meant a knapsack. The word went through the etymological blender and eventually became a term that defines the financial outlay that needs to be managed.

Budgets are characterized by:

1. A steering committee that fields proposals from different concerned groups and prioritizes the money that needs to be spent on behalf or for them
2. Proposals deemed worthy are received from different applicants and put up for creating financial outlays. These outlays are discussed threadbare, partitioned, returned for modifications and eventually accepted
3. A consensus that evolves from all members of the committee that amalgamates all accepted outlays into a single proposal which is modified, voted upon and eventually accepted
4. Money being released in Toto or in varying tranches into a common account which is administered by pre appointed financial departments or individual(s)
5. Transaction invoice based disbursal of money into accounts of each individual applicant against proof of work. It is also possible that proof of work is submitted latter on where advances are concerned
6. A complete end to end audit of all disbursals to reconcile money spent versus actual work done
7. Inordinate delay in release of money thus delaying work in progress
8. Lack of transparency in registering individual financial outlay applications
9. Waterfall model of money disbursement through hierarchical systems leading to corrupt practices
10. Arbitrary invoice approvals without timely transaction verifications

Note that the above is still true if software automation systems are involved since there is a large scale centralization of budget management through a few administrative personnel.

The traditional bitcoin approach will not work because budgets fall back on existing currencies which are the only means of assessing quantum of work and are tightly woven into the bank driven financial network. But what will work is a controlled cluster that scales up/down depending upon resource demands. So let us go ahead and make some assumptions:

• The blockchain network is a closed loop environment with miner nodes that are spawned on demand by a central authority. It also runs a specific set of full network nodes that will be used as a counterweight to keep the system honest
• Client users of the system can elect to run SPV(Simple Payment Verification) nodes that can validate the transaction without being part of the system (no surprises here)
• The crypto currency needs to allow transactions in the system but be supported by physical currency for realization of any compensation
• Full nodes can also be run but the system will have to control the registration of these nodes based on existing load dynamics so that the 51% problem is always handled
• It is assumed that all collaborating nodes (vendors, members or external parties will not collaborate to cause loss to one another)

The simplified diagram above hints at a different variation of the standard blockchain implementation. We start out with the assumption that there is money somewhere outside of the system. We call it Spending Coin (ok, sounds corny!) or SPC. The CMDA is nothing but a proprietary exchange. There are two types of transactions allowed:

• Minting transaction (miner) infuses SPC into the blockchain. The primary transaction in this case will be to force ownership of the SPC to a CMDA user. The real world value (RWV) of the SPC is controlled by the CMDA which essentially creates an exchange preset for the SPC. The minting transaction is the only one within the block that creates the SPC.
• Invoice transaction which occurs between every other user in the system and that includes advance money disbursals as well. There could be multiple invoice transactions that are appended to each and every SPC

The budget control center is the primary application that interacts with all users within the system. A user logs into the control center and monitors transaction status, uses wallets, converts SPC, views transaction history and processes incentives.

The net asset value of the SPC is completely controlled by the CMDA. It functions as a real time exchange with unclaimed profits within the exchange driving up the RWV of SPC.

What about the proof of work? Since the CMDA is a trusted authority the proof of work for minting the SPC is predetermined and held infinitely. Once the SPC is generated then the transactions keep getting appended to the coin just like the regular blockchain network.

This means that anyone can run a full network node but not miners since all miner nodes have to be leased from the CMDA and it is up to the concerned authority to grant miner leases. This not only secures miner access but also will control new block generation thus limiting the number of SPC infusions.

There is one caveat here about the smart contract nodes. The controlled cluster will have to be responsible for all smart contracts that are executed taking care to adjust the value of the execution within the transaction itself. This means that the smart contract execution compensation value is embedded within the transaction value without which we will have no way to control infrastructure costs.

How does it all start?

The system infuses SPCs. Transactions are created to allocate money to department or business unit heads. These transactions are part of the disbursement smart contracts that are triggered automatically or manually.

How are advances treated?
Vendors raise invoices that are controlled by smart contracts that can later recall the money based on accepted parameters. These invoices are honored by a workflow mechanism which triggers appending transactions into appropriate coin blocks.

How is compensation carried out?
Since the compensation is triggered when the transaction is complete, the CMDA will automatically convert the owed coins based on RWV and deposit it electronically into registered accounts. The conversation of the coins is another transaction appended to the respective blocks.

What about unspent money?
Typically this will result in another transaction sending coins back to the CMDA user. It is optional for the CMDA to burn these coins or to leave it in to be rolled over for the next budget.

What about legal compliance?
The nicest approach would be to discard the physical contract system and file for compliance based strictly on digital audit trails of every transaction. An instant audit layer will have to be build that keeps application level transactional view of the entire system rather than a coin view. A necessary aspect of this system would be to design audit reports that can be physically signed.

How can we build these systems?
Google, Amazon and Microsoft can all be used to build both the controlled clusters as well as the CMDA. The CMDA is merely a web app and hence any platform can be used. It does not have to be physically coexistent with the controlled cluster at all and that makes it easy to scale. Microsoft and Amazon both provide blockchain as a service. Microsoft provides Ethereum which makes implementing smart contracts easier. Amazon provides HyperLedger which also has some basic smart contract implementation. A detailed architecture is the subject matter of a different post and probably not relevant here.

Let us look at the pros and cons of the described model:

Implementation	Benefits	Landmines
Controlling miners	This is absolutely essential as it enables fixed inflation free coin usage	There will be perception of lower trust since the controlling authority can override soft budgets with new infusions
Smart Contracts	Since the budget system works across different participants that could be external and internal, rules of transaction are vital	Too much customization required and constant updates are a must
Budget Control Center	This homogenizes the entire system and provides a consistent interface at all times irrespective of user role or location	Single point of failure and can be hacked
Coin Payouts or SPC conversion	Integrates into the banking system and leverages existing transaction fundamentals	The entire network is useless if the payout process is compromised and hence needs highest security
Automatic Audits	In such a system the audits trails are in built and created at the time of transaction. This will bring enormous efficiency to the budgetary spending system	Archiving will demand constant compaction of past transactions and there will bandwidth, computation and storage overheads

Clearly blockchain can be adapted to do budget tracking and implement robust spending controls. The system is presented as a simplified concept and I am sure that most implementers will have to tailor this with more complicated variations based on use cases. It is a very fledgeling view of a very complex problem and serves to be a starting point towards eventual architecture. I do hope that you found it useful.