The Basel Committee on Banking Supervision (BCBS) published a paper exploring the risks of permissionless blockchains and how they can be addressed. Of late, the Basel Committee has emphasized that it doesn’t believe that banks can sufficiently mitigate permissionless blockchain risks. Hence, the crypto rules for banks make it very expensive for them to hold assets on permissionless blockchains, including digital securities or tokenized versions of conventional securities. Digital securities issued on permissioned blockchains are more-or-less treated like conventional securities.
Most public blockchains are permissionless. However, the Basel Committee doesn’t have such an issue with the public aspect. It’s the permissionless aspect that it sees as a bigger problem.
The paper represents the author’s views, not necessarily those of the Basel Committee. It outlines the known issues, such as the risks of a hard fork of the blockchain and lack of oversight over validators. It explores KYC, AML and CFT challenges and the lack of settlement finality on many DLTs.
That reminds us of a prediction a couple of years ago made by Custodia Bank’s Caitlin Long. “Bitcoin’s going to take a G-SIB (global systemically important bank) down at some point because they don’t understand that the settlement risk is so different between Bitcoin and traditional assets.”
One of the trickiest issues with many permissionless blockchains is the low transaction throughput, which becomes a bigger problem in a crisis when everyone is simultaneously heading for the exits.
Addressing permissionless blockchain risks
While the steps to address permissionless blockchain risks are well known, this may be the first time anyone has documented them on a useful list. We’d speculate there’s a good chance the list will become more formal. When the Basel Committee gets more comfortable with the workarounds, perhaps it might relax the permissionless rule, but only if banks engage with assets and activities that tick the boxes. From that perspective, this might be an important document.
The first step is business continuity planning (BCP) such as having an off-chain copy of the asset ownership. This could also define an alternative blockchain where the assets could be moved in a crisis.
Many institutional tokens already make use of allow listing, although deny listing is another option. Zero knowledge proofs are mentioned as one path to privacy preserving identity, although we’d favor truly decentralized identity.
Another commonly used de-risking strategy is to specify a token controller that can reverse fraudulent transactions and address other issues. That’s a concept that the crypto crowd rejects because of the trust-no-one ethos. On the other hand, the same group has an uncanny willingness to park hundreds of millions or even billions of dollars at unregulated asset managers without independent oversight. For regulated institutions, the concept of a controller is a no-brainer.
In theory, confidentiality issues can be addressed with privacy preserving Layer 2 permissioned chains. Alternatives include sidechains and various kinds of cryptography. Layer 2 chains may also address congestion issues, but they are still dependent on Layer 1 for final settlement.
Which public DLTs already qualify as permissioned?
There are quite a few public permissioned chains, although many of them don’t have huge numbers of users. The more institutional ones include IDB’s LACChain, Spain’s Alastria, EBSI and the European Public Network.
Based on the Basel Committee’s definition, we believe the public Hedera DLT qualifies as permissioned and it has a reasonable user base. The 31 corporate members of the governing council control the nodes that write to the network. Those members include the likes of Google, IBM, Shinhan Bank, Standard Bank, Worldpay, Nomura and abrdn. Another bonus is Hedera offers speedy settlement finality. However, Hedera doesn’t plan to remain permissionless indefinitely. When the council member count reaches 39 it aims to transition to being permissionless.
Circling back to the methodologies to mitigate permissionless risk, the paper concludes that “Practices for mitigating these risks are in various stages of development and have generally not been tested under stress.”
