In its recent report, the International Organization of Securities Commissions (IOSCO) has consulted on a set of policy recommendations relating to Decentralized Finance (DeFi). The recommendations are addressed to regulatory authorities around the world to guide their approach to the regulation of DeFi in the coming months and years.
The report’s key recommendation is to identify the natural persons and entities in a DeFi arrangement that could be subject to a regulatory framework. According to IOSCO, these “Responsible Person(s)” include those exercising control or sufficient influence over a DeFi arrangement or activity. Responsible Persons may include, depending on the specific facts, founders and developers of a project, holders of governance tokens, DAO participants, or providers of a user interface to a DeFi protocol. Our commentary below focuses on this recommendation (numbered 2 in the report).
Once a Responsible Person is identified, IOSCO recommends applying a regulatory framework that should achieve outcomes that are the same as, or consistent with, rules for comparable activities in traditional finance (TradFi). Other recommendations relate to addressing conflicts of interest, identifying and addressing material risks, and requiring clear disclosures.
Following the public consultation period, IOSCO aims to finalize the DeFi recommendations and publish a final report around the end of 2023.
1. Many DeFi arrangements have no Responsible Person
Recommendation 2 seems to presume that, in any given DeFi arrangement or activity, it is always possible to identify a Responsible Person who could be subject to regulatory obligations. As the lack of a centralized, controlling party is the hallmark of decentralization, the report could be interpreted as suggesting that decentralized arrangements are either inexistent or impossible in practice, or should not be allowed to exist. The implicit presumption that the way people will interact online in the future cannot be fundamentally different from the way people interacted online in the past (through centralized intermediaries) is troubling and antagonistic to innovation.
We encourage IOSCO to clarify in their final recommendations that some DeFi arrangements may have no Responsible Person, similar to the approach taken by the European Union in carving out “fully decentralized” arrangements from the scope of Markets in Crypto-Assets Regulation (MiCA).
2. All decentralization factors should be considered, not only the level of human influence
We agree with IOSCO’s view that “[t]he delineation between centralized and decentralized finance (or CeFi and DeFi) is more a spectrum than a bright line”. However, this nuanced approach is not reflected in recommendation 2, which takes a binary approach to determining a Responsible Person, and seems to encourage regulators to find such a party “at any cost”. In our view, recommendation 2 should be revised to acknowledge that, similarly to decentralization as a whole, the level of control of humans over a project is a spectrum. Any regulatory obligations should be proportionate to the level of control, and should only target parties towards the “centralized” end of the spectrum.
The role of humans is just one of the factors we need to consider. A number of technical factors (set out below) may point to decentralization or the lack thereof and may alter the risk profile of the project. Regulators should therefore evaluate the role of humans (which is the focus of recommendation 2) in a project not in isolation, but alongside other factors. Failure to do so may result in imposing disproportionately burdensome obligations. In particular, IOSCO’s recommendation that “[o]nce a regulator identifies Responsible Persons, their activities should be assessed using Existing Frameworks or New Frameworks, as appropriate, in accordance with the principle of “same activity, same risk, same regulatory outcome” should, in our view, be clarified to encourage regulators to evaluate whether such frameworks are in fact appropriate or necessary in light of all decentralization factors.
Below, we consider several factors to consider when assessing where a particular project lies on the spectrum of decentralization:
Governance decision-making - protocols where decisions are made by, or must be ratified by, a single participant or a small group of participants who interact outside of the technical parameters of the protocol are more centralized. Protocols where decisions are made by a large and diverse group of users, according to the parameters of the protocol, and with low barriers to being involved in such decisions are more decentralized.
Administrative control - protocols where one or a small number of participants control technical functions of a protocol, often by safeguarding an administrative private key, are more centralized. Protocols that do not require such administrative functions are more decentralized.
Oracle data - if the mechanism for off-chain data to be included in on-chain transactions is operated by a single entity and comes from a private source, then that is a centralized process. A mechanism that relies on many sources that all serve publicly available data is a more decentralized process.
Availability of the code - protocols with unverified, non-public source code that is not permissively licensed are more centralized. Protocols that publicly verify their software and permissively license that software so it may be used, modified, and repurposed are more decentralized. (1)
Decentralization of the native chain - whether the blockchain on which the smart contract protocol sits is decentralized can also be an important factor because that blockchain provides the mechanism through which users can execute transactions using the protocol. Protocols are generally more centralized when the blockchain is more centralized, such as when one participant processes most of the transaction or has the authority to deny a user permission to send transactions. Conversely, they are more decentralized when use is permissionless, many entities process transactions and the source code is available and permissively licensed, among other things. (2)
Access - protocols are more centralized where users access them through one or a small number of user interfaces built in a proprietary manner. They are more decentralized when users have many interfaces to choose from, with some being open-source software interfaces. Here, Ethereum and MetaMask are a great example. While many people use MetaMask to read the Ethereum blockchain and send transactions, it is but one of many software interfaces that a person could choose from to do such activity. This speaks to Ethereum’s decentralization generally.
3. Any obligations imposed on a Responsible Person should directly match their activity in a DeFi arrangement
Assuming a Responsible Person can be properly identified, any regulatory obligations imposed on such a person should directly match the activity carried out by them in the given DeFi project. We respectfully encourage IOSCO to clarify this important point in the final recommendations.
As currently drafted, the Report could be interpreted as requiring a Responsible Person to ensure compliance with all of the proposed regulatory obligations, irrespective of whether such obligations directly relate to the part of the DeFi project over which the person has control or influence. If this interpretation is correct, such treatment would be inconsistent and out of balance with how regulatory obligations are imposed on TradFi actors. The threat of a disproportionate liability for regulatory compliance would effectively make it impossible for good faith actors to engage in DeFi protocols.
4. The scope of the term “Responsible Person” should be significantly narrowed
We agree that today, much of DeFi resembles several TradFi services, but it is important to recognize these services function in an entirely new way. The new processes underlying DeFi mean that applying the traditional regulatory approach centered around a Responsible Person will not bring the desired results when the DeFi protocol at issue is not very near the “centralized” end of the spectrum. Therefore, the proposed scope of the term “Responsible Person” should be significantly narrowed for the following reasons.
First, and related to section 3, IOSCO’s broad description of a Responsible Person risks assigning responsibility to persons who do not have the individual ability to implement the necessary changes that would effectuate the regulatory goals or cannot coordinate their conduct to the degree necessary to satisfy such burdens. Such persons might be DAO participants, holders of governance tokens, or early developers who are no longer actively involved in a project. If we think of regulation as assigning responsibility for risk mitigation and loss, we should recognize that it only works if the party or parties given the burden are capable of bearing the responsibility, or can shield other participants from a loss. A regulatory regime that places impossible burdens on one or more participants as a precondition only serves as a de facto ban on the underlying activity.
Second, the broad description of a Responsible Person risks imposing obligations on parties that did not “sign up” to take on such responsibilities when getting involved in a project. In traditional finance and traditional corporations more generally, duties and responsibilities are assigned in advance and parties can voluntarily decide whether to take on such responsibilities. For example, a director is aware of and voluntarily accepts the clearly defined director duties when taking the job. Given the myriad of ways in which a DeFi project can operate, in our view, it would be impossible to create clear ex-ante rules for identifying a Responsible Person that would be suitable irrespective of the specific circumstances of a project. As IOSCO acknowledges, the proposed process of identifying Responsible Persons would necessarily be fact-specific.
Identifying Responsible Persons among parties such as developers, investors, DAO participants or token holders would therefore amount to imposing regulatory obligations ex-post. This practice would create legal uncertainty. The practical effect would be to discourage developers from innovating, investors from supporting promising projects, and ordinary members of the public from participating in governance.
Third, attempts to identify a Responsible Person “at any cost” would force centralization and create intermediaries where they otherwise would not exist or where the parties’ involvement would otherwise be much more limited (as the level of involvement is a spectrum, as noted above). Instead of reducing risks, this could achieve the opposite effect by creating new vulnerabilities associated with a greater level of centralized human control. Creating new intermediaries would also impede the benefits of DeFi such as faster cross-border transactions or improving financial inclusion thanks to its permissionless nature.
Further, many projects start as centralized and progressively move towards decentralization. Parties’ level of involvement and influence over the project fluctuates during this process. A regulatory approach focused on rigidly identifying Responsible Persons risks entrenching the founding members’ roles and blocking a project’s path toward decentralization. A regulatory regime should accommodate community efforts to decentralize a protocol over time, and regulators should study available examples of such a regulatory approach. (3)
In summary, we agree that, in situations where the pertinent factors reveal a protocol is mostly centralized, a more traditional regulatory scheme that imposes regulatory obligations on Responsible Persons may be possible. Where the factors reveal a protocol that is largely if not entirely decentralized, however, then traditional regulatory approaches will not achieve the results they are intended to achieve. That is in large part because the protocol will be global, and its builders and users, who can come and go as they please, will also be global.
Given the difficulties with frameworks centered around Responsible Persons, we encourage regulators to explore alternative approaches. One option would be to incentivize DeFi participants to comply voluntarily. Incentivizing compliance would be a novel method, but one that is not completely unprecedented. Such an approach is also attractive because it serves the goal of encouraging decentralization, which expands opportunity, and the distribution of value, and reduces intermediary risks.
Background on Consensys
Consensys was founded in 2016 by Joseph Lubin, one of the co-founders of Ethereum. The company was created after the launch of the Ethereum protocol with the goal of achieving the promise of decentralization that this new computer network presented by supporting the development of blockchain-based computing software. We believed then, as we do now, that decentralized networks like Ethereum would allow people to collaborate in ways never before possible. We have dedicated our talents, product offerings, and resources to help drive this evolution.
Today, Consensys is a leading blockchain and web3 software company. We have been at the forefront of innovation, pioneering technological developments within the web3 ecosystem. Through our product suite, including the MetaMask platform,Infura, Linea,Diligence, and our NFT platform, we have become the trusted collaborator for users, creators, and developers on their path to building and belonging in the world they want to see. As of 19 October, Consensys maintains a global workforce consisting of over 800 full-time employees.
MetaMask is the most broadly used self-custody wallet in the world by both web3 developers and users. In 2022, MetaMask surpassed 100M users. It is open-source software that can be downloaded from the Apple or Google app stores and run locally as either a mobile application or a browser extension. The software is maintained by a development team at Consensys and is also supported by a global community of developers and designers who wish to democratize access to the decentralized web.
In late September 2023, MetaMask announced the global public launch of MetaMask Snaps. Snaps are new features and functionality created by third-party developers that MetaMask users worldwide can install directly into their wallets. Previously, MetaMask features were exclusively developed by MetaMask developers employed by Consensys. Now, any web3 developer in the world can add to the MetaMask wallet by building features directly into the wallet which expands MetaMask’s utility. By providing users with a new set of tools developed by third-party developers across the globe, MetaMask Snaps will empower individuals to shape their web3 experience according to their unique needs and preferences.
CONSENSYS SOFTWARE INC.
by Natalie Linhart and William C. Hughes
19 October 2023
(1) Not all smart contracts are open-source code, despite them all being readable on-chain. When you look at the blockchain, you see a smart contract’s byte code, not its source code. While going from source code to byte code is reliably done by a compiler, the reverse is not as reliable. This means it is not always possible to know the source code from the byte code unless that source code is separately published, generally on GitHub or with block explorers such as Etherscan.io. That said, even the byte code-only smart contracts are much more transparent than black-box TradFi processes and related software applications, as the consultation notes.
(2) The base functioning of a blockchain, while designed to include economic incentives, is distinguishable from a financial product or service. More specifically, the proof of stake (“PoS”) consensus mechanism is not a financial activity, but instead, a data integrity function that is critical to the processing of transactions and the security of network data. That is not changed by the fact that the protocol offers incentives to participate in staking, or by the fact that CeFi may offer off-chain products or services that focus on those economic incentives over the data integrity function of the PoS mechanism.
(3) See, e.g., Hester Pierce, Token Safe Harbor Proposal 2.0 (dated April 13, 2021) (available at https://www.sec.gov/news/public-statement/peirce-statement-token-safe-harbor-proposal-2.0) (accessed 19 October 2023).