Institutional blockchain continues to be challenging for many reasons but the one that seems least discussed is missing functionality.
While it’s possible to utilise the current crop of blockchains to achieve some level of efficiencies, they are largely designed and implemented to support a very simple (one-shot) mechanism for pushing value to another account. This reflects the simplest value transfer of payments. We can wrap this same model in some fairly sophisticated ways to enable a broader use across transactions but it leads to considerable operational complexity.
The simplest example to demonstrate this is the lack of a Signature to Receive – anyone that holds a coin can send it to any address by simply signing a transaction on the blockchain. The receiving address doesn’t need to know about the incoming transfer or even be a valid (for some definition of validity) receiver.
In an institutional setting there is (almost) no transfer of value that occurs without the sender and receiver agreeing the validity of the movement. Trade matching, confirmation matching, and settlement matching are required for most financial assets (including large value cash) to have their ownership changed. For assets that confer obligations (legal and financial) on the holder (receiver) this is, of course, even more important.
At large the crypto industry has created an inaccurate short-hand that has seen the ‘public versus private’ blockchain designation refer primarily, and sometimes even solely, to an ‘open versus closed infrastructure’ equivalence. What seems to be overlooked often is the functional differences and it should be no surprise that ‘private’ or ‘consortium’ blockchain implementations have often directly addressed this ‘negotiation’ (pre-transfer) phase (e.g. R3 Corda with the Flow Framework and Finality Flow, Digital Asset Canton with the Daml sub-transactions).
I would propose a simple functional requirement for the next blockchain targeting institutional flows: a Signature to Receive. With this as the foundation model for transfers we can address the following challenges:
- Lower operational burden on custodians and accountants trying to reconcile intended flows from the pervasive ‘dust’ transactions as well as provide for archiving/moving (where possible given gas cost considerations).
- No address poisoning – one of the largest (and easiest) ways of draining user wallets and a driver of operational complexity around white-listed wallets for institutional flows.
- Accounts (addresses) that can be closed! We need better answers for the continuous growth of blockchain data but also the operational burden of having to monitor every address ever used (or exposed) for eternity without being able to declare an address closed and non-receiving.
Simple extensions could allow an address to be marked as ‘always open’ (auto-signed) where necessary, as well as pre-authorised through smart contract. Pre-authorisation could be parameterised to match one or multiple sending transactions across defined or open values.
Current blockchains largely lack the features required to provide a robust financial market infrastructure and it’s time to move beyond a focus purely on performance.