Consensys Software Inc. respectfully submitted a letter in response to the discussion paper by ACPR, a division of the Banque de France, concerning decentralized finance (DeFi) published in April 2023. We are encouraged that they are consulting the crypto ecosystem on these novel and complex issues. As an initial matter, we generally agree with their “disintermediation” framing of the programmable blockchain space and welcome the opportunity to discuss further with them about the innovation in the programmable blockchain ecosystem. It’s important that blockchain native projects take the opportunity to collaborate on the important task of bolstering innovation while mitigating the risks that new technologies may present. Below are several of our responses to their questions.
You can download the full response in pdf here.
Do you have any comments on the definition of DeFi used in the paper? Does the document correctly reflect the real level of decentralization of services?
We agree that the essence of DeFi is replacing the trust between players with the transparency and immutability of computer code, and that this code serves to disintermediate transactions that have traditionally required an intermediary. We also agree that many projects currently remain reliant on project founders, with some intent to eventually decentralize. With legitimate efforts to decentralize, it is critical that regulatory regimes do not construct barriers that explicitly require or practically result in centralization.
Do you have any comments on the description of the risks related to the application layer of DeFi?
We agree that open-source smart contract code, which allows all nefarious actors the opportunity to expose and take advantage of vulnerabilities, ultimately results in more secure applications over time. We further agree that composability is a trade-off, namely that smart contracts calling other smart contracts can greatly increase what transactions are possible but also can proliferate buggy or malicious code if precautions are not taken.
We recognize the importance that data availability plays in DeFi and the crucial role of oracles in that process. Despite their infancy, oracles have proven remarkably efficient and reliable to date, while risks certainly remain. General understanding of oracles and their risks should improve throughout the crypto ecosystem and among policymakers if the proper policies are to be fashioned.
Do you have any comments on the identification of DeFi risks for retail customers?
Everyday users of DeFi applications would be best served by reliable, coherent, and informative disclosures about how a particular protocol works and risks attendant to its use. These would be more easily implemented and policed, and far more effective, than explicit restrictions on the type of transactions in which specific users are permitted to engage.
Do you have any comments on the description of the potential AML/CFT risks of DeFi?
We agree that pseudonymous blockchains do not provide anonymity, as is widely believed. We recognize that illicit activity on-chain, while not remotely comparable in volume or frequency to illicit activity in traditional finance, is a serious matter that requires both public policy and technical solutions to address. We note that the traceability of blockchain transactions has been a boon to law enforcement in their efforts to identify illicit behavior on-chain, but they must use this tool in a way that does not unduly sacrifice the privacy of lawful users, who represent the overwhelming majority of DeFi participants.
Should public blockchains be governed by a framework or by minimum security standards?
Regulating public blockchains by way of implementing certain minimum standards would not achieve the desired security outcomes and would come at the cost of greatly restricting innovation. Additionally, the practical difficulties of imposing jurisdictionally-determined standards on otherwise global ecosystems should not be ignored and would render any such framework either ineffective or, worse, counterproductive.
Like the approach taken with the broader internet, and communication channels more generally, regulation should not focus on the underlying blockchain technology infrastructure, but on commercial applications built on blockchains. The best approach to ensure reliable, secure, and resilient blockchains is to encourage software development, diversity of software offerings, and organic incentive structures.
Should public players directly manage the blockchains that provide the infrastructure for DeFi operations?
Having a centrally managed blockchain defeats the purpose of a distributed ledger and the data integrity, accessibility, and ownership that comes from distributing the data updating and maintenance function and placing ownership in the hands of users, nor providers. Such a framework would completely undermine a blockchain’s central purpose, resulting in a more complex system that can be much less efficient than a hub-and-spoke model while not providing any real benefit. A government-supervised blockchain network is unlikely to be able to compete with any alternative that operates under and evolves according to market forces.
Policymakers could, of course, create and manage a blockchain and assess for themselves how successful they might be if they put this strategy into action on a grander scale. Alternatively, policymakers could begin participating in public blockchains like Ethereum now, and test whether participating in such a system rather than attempting to run an independent one is a better approach.
Is a certification mechanism an effective solution to determine the scope of "safe” smart contracts (for a given state of knowledge)?
At Consensys, we believe in the value of auditing smart contracts and have built a successful line of business around that belief. We have seen first hand the positive impact that proofing and auditing can have on end users of applications. We also recognize that auditing is a finite supply service and can be beyond the reach of some projects, at least initially, or simply be out of reach due to very high demand.
We are not in favor of requiring all smart contracts, regardless of use case, being subject to such certification requirements, nor are we supportive that all developers should be required to get one. What we would never be able to support is a regime that purports to limit the deployment and use of free, open source contracts that are akin to free, open source software that is liberally licensed and accessible on a public code repository. Any regulation that would have the effect of, let alone seek to, chill the development and deployment of freely usable software tools would be very negatively received by the public and particularly the software developer ecosystem, and rightly so.
Who should set the security standards for smart contracts and why?
While regulators and policymakers can play an important role as collaborator in any process, the best result would be achieved if the ecosystem itself established any and all technical standards that would come to form one or more ecosystem-wide benchmarks. The participants in the space have the highest technical expertise and the most practical experience with the subject matter and are thus in a far greater position to set standards. The best role for regulators in such a scenario is to collaborate on a road map and to facilitate ecosystem participation and cooperation in such an effort.
Do you have any comments on the description made of the risks inherent in the decentralized oracle model?
We note at the outset that the risks outlined in the discussion paper regarding decentralized oracles, namely the risk of collusion, incentive to tamper, and risks of a highly automated system, are also risks that a centralized oracle presents, and even perhaps to a more troubling degree.
Setting that aside, the problem with obligating oracle providers to comply with a certification system, at least at the current moment, is that oracle technology is still in its infancy. With that said, oracles can be seen in some sense as an intermediary, ones that connect real-world information with blockchain data structures. Their reliability, accuracy, and transparency are crucial. Policymakers should become very familiar with these protocols, and expect that, if regulation of these information providers is indeed necessary, the path to implementing regulation should be incremental and involve considerable collaboration with the space.
What requirements should apply to intermediaries facilitating access to DeFi?
Any regulatory requirements should be limited to those services that do more than serve as purpose-agnostic tools that allow users to safeguard their own data and conduct transactions on their own. Just as it would be entirely inappropriate and overly burdensome to require web browsers like Chrome and Safari to screen, monitor, advise, and warn their users for all manner of dangers as they browsed the web, it would be unreasonable to place requirements on open source software tools to do the same in the context of a blockchain network.
Should the same rules apply to all intermediaries in DeFi (including, where appropriate, decentralised web interfaces)?
Web interfaces, such as unhosted wallets, are not intermediaries in DeFi. They are software tools that the users of DeFi (those actually moving their own funds and interacting with the on-chain smart contracts) use on their own to compose their transactions, read the data structure, and send signed transaction messages to the blockchain.
As the discussion paper itself recognizes, DeFi can be thought of as disintermediated finance, where the traditional counterparty or middle man is replaced by a system which offers you access to code that you can use on your own to execute transactions for yourself. That purpose-agnostic software makes this system more accessible to people who are not comfortable using a command line interface does not render that software package an intermediary in any sense.
To the extent that some interfaces offer other services, including information aggregation or curation, or access to off-chain computer programs that facilitate on-chain transactions, a one-size fits all approach to rules makes very little sense, given the variability in what the services are and how they impact the user.