When Malta set out to provide a regulatory framework for the cryptocurrency sector, policymakers and advisers recognized how blockchain, distributed ledger technology and smart contracts, as well as related technologies, imposed new challenges to providing consumer protection and to fitting within existing legal structures.
Immutability of data — and subsequently code, or rather smart contracts — is a desirable feature to provide guarantees to users that data (and smart contracts) cannot be tampered with. However, this also poses a critical challenge: Often, it is impossible, or infeasible, to change code once it has been written to such a distributed ledger. This potentially means that code can be deployed that ends up managing millions to billions of dollars worth of funds, and if a bug is found, it may be impossible to update the code to get rid of it.
Cryptocurrencies, tokens, initial coin offerings, security token offerings, etc., are built on this type of technology. In order to provide consumer protection, regulators around the world have focused on implementing a regulatory regime that ensures due diligence is undertaken regarding the individuals behind such operations, and regarding the financial and legal aspects of the operations, which is great.
Yet, minimal effort has gone into ensuring that there are adequate levels of due diligence regarding the technology. In traditional financial systems, this is not much of a problem, as when something goes wrong, authorities and other centralized stakeholders can reverse actions and/or data as required. However, when it comes to decentralized systems, this is not an option. Neither the crypto operator, users, regulators, enforcement entities nor even the courts can do anything to revert the decentralized transactions. If a bug causes losses of billions in crypto, the tokens are lost forever.
Some argue that such responsibility and risks should be borne by users. Being a computer scientist and programmer myself, I would be in a better position to accept this over many others. However, should we really expect users out there to bear the risks of potential bugs within code?
If the sector wants to achieve mass adoption and not just entice the technology-inclined to use such technology, should we really expect such non-tech-savvy users to understand code — and the intricate types of bugs that often exist within?
Regulators see the benefits in checking financial and business models surrounding operations to ensure consumer protection, as many investors out there may not be experts when it comes to such models. Yet at the same time, should we expect investors to understand code? And this is often code that, when deployed, is not readable by humans but is in an encoding that only computers can understand.
Many would argue that the financial and business models can be more easily comprehended by investors out there than the code — well, at least for most users out there. While it would be great if everyone could understand code, it is not the case.
Personally, even as a coder myself, I would prefer to invest in operations that have undergone technical due diligence over ones that have undergone operational due diligence. It would take much less time to understand underpinning business and financial models than it would be to undertake a functional correctness assessment on my own. Perhaps that is because I am aware of the complexities of the technology.
However, my gut feeling is that most users out there would also prefer that assurances have been undertaken with the code rather than on the business and financial side. That being said, both should be undertaken.
Losses in the industry
Instances of bugs within the sector that have resulted in large losses are plenty. A (nonexhaustive) list of such reported instances is huge. In 2018, exchange Coincheck was hacked; small South Korean exchange Coinrail and crypto exchange Bithumb were hacked; decentralized crypto platform Bancor was hacked; and 27 hacks of decentralized applications on the EOS blockchain occurred during five months. The following year, in 2019, an Ethereum-based synthetic issuance platform and an EOS game of chance, EOSPlay, were impacted. This year has been no exception, as well: Decentralized lending protocol bZx saw two hacks in February; decentralized finance protocol Balancer and the Statera (STA) team were affected in June; an issuance vulnerability in Ravencoin’s (RVN) supply was found in July; and a bug was found in SushiSwap in September, among many others.
Related: Most significant hacks of 2019 — New record of twelve in one year
One can see that such situations are not hypothetical. Now, one school of thought is that regulatory frameworks and licensed activities can help bring about mass adoption, especially for those who do not understand the technology.
However, if such frameworks do not provide assurances with respect to the technology being used, and bugs that result in large losses do happen, will it only be a matter of time until a licensed activity suffers this fate? This would undoubtedly be detrimental to the licensed activity, the jurisdiction and the sector, and it would induce doubt among investors and stakeholders, ultimately creating more hurdles in the way of mass adoption.
We have developed a regulatory framework as part of the Malta Digital Innovation Authority’s remit. Further details are presented in the paper “Regulating Blockchain, DLT and Smart Contracts: a technology regulator’s perspective.”
I feel that such technology assurances have been overlooked by most crypto regulators, and therefore, I have written an open letter highlighting these issues and inviting regulators to discuss them in the aim of creating a regulatory framework that has the adequate levels of technology assurances and provides the required levels of consumer protection that the industry needs to bring about mass adoption.
The views, thoughts and opinions expressed here are the author’s alone and do not necessarily reflect or represent the views and opinions of Cointelegraph.