Consensys Software Inc respectfully submits this letter in response to HM Treasury’s consultation and call for evidence concerning crypto assets published February 2023. Below, we respond to certain questions pertaining to “decentralized finance” (DeFi) and “other crypto assets.” We are encouraged that the Treasury is taking the step of consulting with the crypto ecosystem on these novel and complex issues, and we welcome the opportunity to discuss with policymakers across government about the innovation in the programmable blockchain ecosystem.
We view this comment letter as an invitation to converse further regarding the ongoing development of Ethereum and other programmable blockchain ecosystems. We hope to engage with you in greater depth on the summarized points set forth below. We appreciate the opportunity to collaborate with you on the important task of bolstering innovation while mitigating the risks that new technologies may present. You may contact us at [email protected] at your convenience.
1. Background on Consensys Software Inc and its Flagship Offering, MetaMask
Consensys was founded in 2016 after the launch of the Ethereum protocol with the goal of facilitating decentralization through the development of blockchain-based computing platforms. We believe that, through decentralized networks like Ethereum, people can innovate and achieve like never before. We have dedicated our personnel, product offerings, and resources to help drive this evolution.
Consensys is a leading Ethereum software company. We enable developers, enterprises, and people worldwide to build next-generation applications, launch modern financial infrastructure, and access the decentralized web. Ethereum is the largest programmable blockchain in the world, leading in developer community, user activity, and business adoption. On this trusted, open-source foundation, people around the world are building the digital economies and online communities of tomorrow. Our software suite, which includes MetaMask, Infura, Quorum, Truffle, and Diligence, is used by millions and supports billions of blockchain calls.
MetaMask specifically is one of the most broadly used unhosted wallets in the world by both web3 developers and 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 also supported by a global community of developers and designers who wish to democratize access to the decentralized web.
2. Blockchain Networks are Programming Platforms
We applaud the Treasury for endeavoring to learn about blockchain systems before reaching conclusions on the risks they may present and what, if anything, public policy can do about it. Those efforts are particularly important because, in other jurisdictions, the focus of the regulatory conversation has unfortunately been off the mark. We hope that this comment process results in the Treasury engaging in policy discussions from the baseline that blockchain networks are in fact entirely new computer programming platforms.
Programmable blockchains like Ethereum allow anyone to write and publish code that is accessible to anyone else in so long as they have access to the blockchain network and the ability to compose and transmit on-chain transactions. In recent years, the increase in blockchain software development, as reflected in the number of developers committed on platforms such as Github to solve particular programming problems, has been notable. According to one analysis published in early 2023, over 23,000 monthly active developers were working on blockchain programming projects. While these numbers may be small compared with the global developer community writ large, the trend of developers expressing their interest in and becoming proficient at blockchain software development is unmistakable.
With respect to the UK’s developer footprint, it has in recent years been less than 10% of the blockchain developer community. The UK can and should want to change that to drive more software development in this new space if it intends to be a crypto hub.
That dovetails with Consensys’s efforts to bolster migration of developers into the space through our software platforms that permit developers to innovate new tools that can be shared with an increasingly broad user base. While the Consensys offering MetaMask is recognized as the world’s most popular Ethereum self-hosted wallet, few recognize that it is as much a developer platform as it is a client-side key management solution. The clearest expression of this is the release of MetaMask Flask, which is an experimental MetaMask application that allows developers to create new features that can be tested and refined before offering to the public more broadly. The first feature offered through Flask is the Snaps system, which allows developers to create their own programs that expand the functionality of the wallet. Consensys is not alone in working to bolster developer engagement and productivity. Examples abound of a thriving developer ecosystem where brilliant minds from all over the globe are tackling the novel problems presented by a nascent technology.
It is from this perspective that the Treasury should consider regulatory issues around blockchain protocols. While considerable attention to date, both regulatory and otherwise, has focused on the price of digital tokens in fiat currencies and the speculation often attendant in their issuance and secondary market trading, sound regulation will only be realized when the technological functionality of nascent blockchain networks is the focus of the inquiry.
3. Responses to Specific Questions Concerning DeFi
Do you agree with the assessment of the challenges of regulating DeFi? Are there any additional challenges HM Treasury should consider?
We generally agree with the assessment and applaud the decision to carefully scrutinize risks attendant to DeFi before prescribing a regulatory framework. Below, we list some additional regulatory challenges for your consideration. Cumulatively, these complex and distinct challenges mean that regulating DeFi requires a bespoke approach that might serve as policy leadership across the globe.
Underlying the question of regulating DeFi is the distinction between the investment and technology sides of the crypto ecosystem. The investment side looks very much like traditional finance. There, digital assets are largely just new assets to invest in with the hope that they increase in value when compared with the pound, the dollar, or the Euro.
The technology side, on the other hand, is the part of the ecosystem that is trying to make these global, permissionless distributed ledger systems actually useful for a variety of activities, including financial and commercial transactions. This side looks very different from traditional finance, as its functioning is determined by cutting edge computer programming and network building. For a deeper discussion of this dichotomy in the crypto ecosystem, read here. It is the technology side that introduces novel risks which we should be careful to understand before we apply regulations. In some instances, public policy may not be the best answer for certain risks. Rather, the technology itself must evolve to address certain consumer protection, security, and other issues.
The risks in traditional finance are well established. They include conflicted insider actors, potential abuse of power, and information asymmetries. The key insight about regulating DeFi is how and the extent to which these traditional risks are inherently mitigated by DeFi structures, and to what extent new meaningful risks arise from the technology itself. Regulatory authorities are not traditionally experienced with addressing many of these purely technical risks, so novel approaches should properly be considered.
Applications, not Protocols
To be effective in mitigating risk and to avoid unduly chilling innovation, these novel approaches must focus on specific applications of blockchain technology and not the composition and functionality of the blockchain itself. By regulating the blockchain system itself rather than applications, we inevitably diminish any efficiencies or new capabilities that blockchain has to offer. Regulating applications offered to the public, on the other hand, takes a more precise approach to mitigating risks such offerings may present.
This application-not-protocol approach would parallel how the web2 internet currently is addressed from a regulatory perspective. There, the internet infrastructure that powers “https” websites is not artificially constrained in order to limit activity or function. Instead, certain activities and services on that internet are directly regulated. Taking such an approach with web3 would lead to more consistent and coherent outcomes, including with respect to how open-source code is handled under the law. Such code, which can be created and deployed from anywhere in the world, may be used to create any variety of blockchain-powered products or services. It should be, and is more practically regulated if, those products or services that pose risks that are regulated, not the purpose-agnostic open source code.
It is for these reasons we encourage HMT to resist the temptation to prescribe substantive requirements or design features for the functioning of blockchain protocols themselves. Doing so would most certainly create concern among software developers that, by developing and publishing open-source protocol code in a way that can be connected to the UK, they will breach some inconspicuous regulatory rules and be exposed to legal liability. Such concerns would have a chilling effect on developers’ willingness to innovate and develop the public good which is a permissionless blockchain ecosystem in the UK.
Additional challenges
There are several challenges that we must contend with when considering a DeFi ecosystem that is as safe, secure, and resilient as possible. As a general resource, we would commend to you the report written by Professor Tarik Roukny and commissioned by the European Commission, which identifies some additional features of DeFi that give rise to unique regulatory challenges.
In addition to these challenges, there is the challenge of off-chain data integrity. While data that is native to a chain can be mathematically proven to be accurate or not, the same cannot be said of data from the real world or external computer systems that has been added to the blockchain data state or used in conjunction with blockchain transactions via a data oracle. Many blockchain applications rely on oracles to feed data that is important for those applications to function as designed. Any instability in or manipulation of such oracles would likely cause the blockchain applications to not function as intended. This oracle risk has not been the focus of a lot of public policy attention or crypto ecosystem attention under the general category of industry best practices. But we agree with Professor Roukny in his assessment that additional measures may need to be introduced to ensure that off-chain data being used on-chain is as safe and reliable as native on-chain data.
How can the size of the “UK market” for DeFi be evaluated? How many UK-based individuals engage in DeFi protocols? What is the approximate total value locked from UK-based individuals?
This is a difficult question to answer because DeFi participation on a jurisdiction by jurisdiction basis is generally not readily identifiable. Protocols are globally accessible, and while certain regions may constitute the majority of participation in a particular protocol, there is no reliable method to really know the true size of a particular country’s footprint with respect to a specific protocol, let alone a country’s footprint in DeFi more generally.
But there are metrics which may shed light on the evolution in the involvement of UK persons in DeFi. The number of active web3 developers is one such metric. A number of publicly available reports have been released which attempt to analyze the change in the web3 developer community, and some include statistics that show where these developers are geographically. One recent report relied upon self-reported locations of developers and the apparent time zones in which developers operated from to reach conclusions on how developers were spread out across jurisdictions. That report concluded approximately 6% of world-wide developers in 2022 were located in the UK, which was one percentage point less than in 2021 but still larger than any European country with the exception of Germany, which has a comparable number of web3 developers.1
Another metric is the number of unhosted wallets in use in particular jurisdictions. Unlike centralized exchange accounts, which are generally designed to permit a person to buy and hold digital assets as an investment, the purpose of unhosted wallets are to allow the user to interact directly, without an intermediary, with DeFi and other web3 services. Wallet providers may have data about monthly active users of their software, including in what regions those users are located.2
There are potentially other sources of information on the UK’s DeFi footprint that ecosystem participants may be able to share. For instance, Consensys has been conducting a broad market survey of public sentiment about web3 and its use around the world. Some of the findings and conclusions of surveys such as this one might be of use to policymakers, and companies like Consensys should carefully consider what information from these surveys would be appropriate to share.
Do you agree with HM Treasury's overall approach in seeking the same regulatory outcomes across comparable "DeFi" and "CeFi" activities, but likely through a different set of regulatory tools, and different timelines?
We agree in principle with the approach of seeking the same “regulatory outcomes'' across comparable "DeFi" and "CeFi" (centralised finance) activities. We understand regulatory outcomes broadly to concern consumer protection, investor protection, combating illicit finance, and market integrity. These are of course important, and should concern not only regulators but also the crypto ecosystem itself.
But certain qualifiers are important. First, those regulatory outcomes must be in balance with the need to ensure that innovation, collaboration, and other commercial activities are not unnecessarily stifled or burdened. Unreasonably burdensome regulation will likely catalyze regulatory arbitrage as projects will move to jurisdictions with less onerous regulatory regimes. Ultimately, overly burdensome regulation is self-defeating, as the activity which it seeks to regulate merely moves to other jurisdictions. Because the conduct at issue relies on blockchains, those relocated offerings remain accessible to users the regulatory regime seeks to protect. The result is that the burdensome regime is of very little protection at all.
In our view, achieving the same regulatory outcome is not possible without understanding and acknowledging that the actual functioning of DeFi is different from that of CeFi, and it is that functioning which will ensure that some risk mitigation measures prove effective and others are unproductive. It is imperative that the underlying technology be properly understood to effectively mitigate specific risks and, as you note in the consultation, to understand how the technology itself functions and is evolving to better avoid risks.
What indicators should be used to measure and verify “decentralisation” (e.g. the degree of decentralisation of the underlying technology or governance of a DeFi protocol)?
We will focus on one concept of decentralization for both the underlying blockchain protocol and a specific DeFi application. With respect to the blockchain protocol, the number of separately engineered and published software programs that can serve as network clients is an important metric. Currently, Ethereum has at least five clients that are independently maintained. Client diversity ensures that the network is not overly reliant on any one instance of code to ensure transactions are executed properly and nodes are maintaining consensus.
With respect to DeFi application governance, an often overlooked factor is who implements the decisions made through a DAO (decentralised autonomous organisation) vote. In a simple scenario, and assuming a perfectly decentralized DAO membership, a DAO vote would automatically trigger an on-chain transaction that would effectuate the will of the voting DAO members. But DAO decisions are often more complicated and require independent, off-chain implementation. If a DAO decision can be put to action only through the efforts of one of the DAO members, or of persons who have some operational role they play for the DAO in exchange for compensation, then whether they can be trusted to implement the will of the DAO precisely as the DAO intends may only be determined through an assessment of how easily they could act counter to the DAO’s explicit instructions.
There have been certain reported instances of the implementers of a DAO decision taking different action. In such instances, decentralisation is plainly belied by a single party asserting control not of the decision but its implementation. Governance arrangements where this level of authority is not properly mitigated should likely not be characterized as decentralized.3 The ecosystem itself is still grappling with the question of what constitutes “sufficient” decentralisation. While considering indicators of decentralisation is a useful exercise, we caution against defining decentralisation in a prescriptive manner in a future regulatory framework. The circumstances of each project needs to be evaluated on a case by case basis, especially as decentralised governance is not a binary state. Most often we talk about a progressive decentralisation, a process in which founding teams hand over control to the community by degrees, over time. The reason behind progressive decentralisation is to enable the community to learn how to govern, slowly opening more sensitive topics to a public vote. Any potential regulation should be flexible enough to allow for a governance framework that changes over the course of the project.
Which parts of the DeFi value chain are most suitable for establishing "regulatory hooks" (in addition to those already surfaced through the FCA-hosted cryptoasset sprint in May 2022)?
As an initial matter, participants in DeFi are most often also active in CeFi and engage with a number of centralized parties. As a result, an important element of any regulatory scheme seeking to reduce risks in DeFi would be to regulate CeFi service providers such as exchanges, custodians, and fiat on/off ramps. Traditional regulations and traditional enforcement are applicable here, such as obligations relating to KYC, AML, segregation and safeguarding client assets. Blockchain analytics tools that can tie DeFi activity to CeFi accounts are proving to be a powerful investigative tool, which in turn meaningfully disincentives illicit activity.
Focusing on DeFi more specifically, the degree of control that certain persons exercise over an application or protocol should be an important criterion for any regulatory scheme. Circumstances such as a party’s retention of administrative private keys that would enable that party to access or redirect collateral locked in the protocol, or otherwise interfere with the automated operation of the smart contracts, may present risks that might be mitigated by a regulatory scheme, the precise nature of which would be determined in part on the nature of the activity the smart contract in question is facilitating. Regulation here should be balanced so as not to stifle innovation and to bolster efforts to progressively decentralize as described above.
The consultation raised the option for regulating DeFi by defining a set of DeFi-specific activities, such as “establishing or operating a protocol,” as regulated activities under The Financial Services and Markets Act 2000 (Regulated Activities) Order 2001 (“RAO”) or the Designated Activities Regime (“DAR”). This approach would be problematic in our view. First, the general activity of “establishing or operating a protocol” is not specific enough to address actual risks that some protocols but not others may present. A better approach would be to distinguish among different types of protocols based on their functions, such as lending, exchange, and liquidity aggregation, before prescribing regulatory burdens.
Second, the activity “establishing a protocol” might inadvertently bring into its scope the activity of developing software that is not subsequently controlled by that developer. We strongly support HMT’s comment in the consultation that “the objective is not to regulate the activity of developing software”, and any indication that the UK is intent on regulating software development would negatively impact the UK’s efforts to encourage blockchain development within its borders. It is self-evident that protocols can be developed anywhere in the world, and any burdens the UK would impose on such development in its jurisdiction would have predictable impact on the desire for developers to work in the UK.
Third, if this approach is taken, the scope of “operating a protocol” should clearly exclude ordinary holders of governance tokens. Deeming ordinary holders, including those with de minimis holdings, as operators on an equal level with parties that have far greater direct or indirect control would severely discourage participation in voting and governance, thereby undermining the very aims of decentralized governance. A better approach would be to focus on those with administrative keys or other powers that enable them to interfere with the running of the protocol.
Finally, the consultation noted that interface providers and other actors facilitating consumer access to DeFi (e.g. aggregators and other consumer “front ends”) could be another viable hook. It was suggested that such entities conduct regular, independent code audits and IT security tests, as well as standards around information disclosures requiring clear, non-technical descriptions of the services provided and associated risks, third party service provider oversight, and governance standards covering best practices around voting and review periods and vesting schedules are complied with.
We urge caution here. First, not all “front ends” are the same. Many are merely interfaces that permit simple reading of and writing to the blockchain using coding language that is open source and easily replicated in new offerings. Regulating these sorts of offerings would be akin to regulating the Google Chrome browser because it is used to interact with banking websites. Second, in some situations, front-end providers are not in a position to bear the burden of all suggested regulations, including because their software offering has not been monetized in a manner that would permit it to bear an expansive compliance burden. They should not be expected to have the financial resources, the expertise, or the appropriate presence or access to perform an oversight function. Third, there is a material difference between front-ends that provide a user with better information and those that facilitate new transactions for the user that would not be otherwise available to the user without the front-end. Regulating information collection, curation, and presentation does not serve the interest of consumer protection, in part because it would strongly disincentivize such information-related services.
What other approaches could be used to establish a regulatory framework for DeFi, beyond those referenced in this paper?
DeFi-native tooling should be fully understood and deployed to appropriately manage risk. At a high level, examples include using decentralized identification, attestations, analytics and the use of smart contracts. The use of smart contracts to automate and self-execute along pre-agreed parameters is already something that the DeFi ecosystem utilizes. For example, if one wishes to borrow on a DeFi protocol, the borrower needs to deposit sufficient collateral. The transaction will not be effected without this step. Further, the smart contracts at play in this protocol measure the posted collateral so that collateral calls and liquidations are automated.
Finally, DAOs are presenting interesting and novel governance and structural features. It is necessary, as the consultation recognises, to wait for clarity of the legal structure of DAOs from the Law Commission. That said, tooling such as gated communities, automated governance and decision making, quadratic voting (which seeks to solve for the power participants with majority holdings exert on governance), could be deployed to manage risk in a DeFi-native manner regardless of the legal status of a DAO itself to the extent implementing such tools outside a DAO is possible.
What other best practices exist today within DeFi organisations and infrastructures that should be formalised into industry standards or regulatory obligations?
Many players in the programmable blockchain space already follow industry standards and best practices. We describe some of these below. The success of these standards and practices is in part due to the fact that they are industry-led, which ensures they are kept up-to-date and can dynamically respond to technological developments. They are developed by groups of responsible players that are incentivised to make the space safer and more accessible for everyone, to drive user adoption. Industry players are aware that compliance with best practices not only increases the likelihood of success of their project, but also increases the confidence of the general public in the blockchain space as a whole by reducing the likelihood of negative events relating to bugs and exploits. Given these inherent incentives and the nascent state of the programmable blockchain technology, we encourage authorities to carefully evaluate the costs and potential benefits of any measures that would hard wire industry best practices or standards into regulation.
Best practices with respect to software development include having a third-party code audit conducted before the software is released. Consensys specialises in this type of service through its Diligence offering. Diligence maintains a suite of blockchain security analysis tools and pairs up that service with in-person review of smart contract code by a qualified code auditor. Many players make the results of an audit publicly available, demonstrating how the issues found have been remedied, and have the code re-audited if applicable.
One example of industry-led initiatives in respect of smart contract auditing is the EEA EthTrust Working Group, which is part of the Enterprise Ethereum Alliance (EEA). The EEA brings together representatives from leading technological companies, smart contract auditors, financial institutions, consultancies, academic researchers, public authorities and others. The EEA EthTrust Working Group works on a technical standard for security review of smart contracts, with a first version published in August 2022. The group is currently working on an updated version. The group has developed the EEA EthTrust Certification, which confirms that a smart contract has been reviewed and found not to have a defined set of security vulnerabilities. To grant the EEA EthTrust Certification, an auditor provides a conformance claim that the tested code meets the requirements of the specified security level for which it is certified. The Certification is available at three security levels, with each providing successively stronger assurance that a smart contract does not have specific security vulnerabilities. The optional Recommended Good Practices, if correctly implemented, further enhance the security of smart contracts.
In addition, the EEA DRAMA Working Group was formed with the goal to develop and promote the use of common assessment criteria for risks involved in the use of DeFi protocols, to encourage mainstream acceptance and enterprise adoption. They have produced a survey on how the industry sees various risks in the area of DeFi in terms of importance. The ongoing results of that survey, alongside the group's own expertise, is used to develop a discussion paper on the risks associated with DeFi that is intended to describe best practices for both risk assessment and mitigation. The paper is currently in an internal drafting phase and will be made available for public comment in the coming months.
Is there merit in regulating mining and validation activities in the UK? What would be the main regulatory outcomes beyond sustainability objectives?
No, directly regulating the validation of blocks in a permissionless, global blockchain network is not advisable because it will not serve desirable outcomes. Before we get into details of why that is the case, we wanted to note that our response will be limited to the validation of blocks on a blockchain employing a proof of stake consensus mechanism.
First, validators in any jurisdiction must abide by the protocol specifications that apply globally. Should a particular jurisdiction institute requirements on validators that cause them to run code that is inconsistent with these specifications, then those validators are removed from the network. The controls that they institute would thus not be able to impact any network activity, which presumably is what the controls were intended to affect in the first place. After those nodes are excluded from the network, other network participants would continue operating as if those nodes never existed in the first place.
Second, even if such nodes did not get removed from the network, then any transactions that this cohort of validators would not process could be freely processed by any other validator that did not implement the same controls, presumably because it was located in another jurisdiction. Again, because the controls the particular jurisdiction enforced on its validators were not imposed network-wide, they do not have a meaningful effect on network activity.
Third, it would be very hard to police such validator regulations in no small part because, through the simple use of widely available VPNs, one cannot tell a validator’s location of operations. Validators running in the regulated jurisdiction could avoid implementing regulations, and the regulating agency would have little ability to identify the noncompliance.
Fourth, an attempt to regulate how the protocol-layer of the blockchain ecosystem works would be construed as a heavy-handed, antagonistic regulatory step that would undoubtedly chill industry interest in participating in the space from that jurisdiction. It would be directly at odds with any goal to become a globally-recognized leader in blockchain technology.
As explained below, validation is a technical activity that, in itself, does not carry the risks that financial regulation traditionally seeks to address. We recognize that reducing money laundering is an important regulatory objective. But an attempt to mitigate illicit finance through direct regulation of validation would not create benefits that outweigh its costs, and would create a situation where all transactions, including those submitted by UK residents, would be largely if not entirely processed by validators in other jurisdictions. For more on proof of stake consensus in the Ethereum ecosystem, read here.
What do you think the most appropriate regulatory hooks for layer 1 staking activity would be (e.g. the staking pools or the validators themselves)?
As discussed above, validators run software that performs a critical data integrity function for the network that is purpose agnostic. They are therefore an inappropriate hook for financial regulation, and would also be a counterproductive tool because regulation would only serve to push blockchain infrastructure like validators into foreign jurisdictions where it would still be accessible to the jurisdiction’s users.
We note HMT’s suggestion in the consultation that some staking arrangements may qualify as a collective investment scheme (CIS). Staking offerings should not be classified as a CIS, unless the offering goes beyond the provision of technical activities and involves the exercise of discretionary managerial activities.
We include the definition of CIS at section 235 of FSMA below for reference:
“(235) In this Part “collective investment scheme” means any arrangements with respect to property of any description, including money, the purpose or effect of which is to enable persons taking part in the arrangements (whether by becoming owners of the property or any part of it or otherwise) to participate in or receive profits or income arising from the acquisition, holding, management or disposal of the property or sums paid out of such profits or income.
(2) The arrangements must be such that the persons who are to participate (“participants”) do not have day-to-day control over the management of the property, whether or not they have the right to be consulted or to give directions.
(3) The arrangements must also have either or both of the following characteristics—
the contributions of the participants and the profits or income out of which payments are to be made to them are pooled;
the property is managed as a whole by or on behalf of the operator of the scheme.”
This definition is widely drawn and is intended to cover a broad variety of schemes beyond traditional investment funds. Staking models that pool customers’ staked assets may be interpreted as satisfying the requirement at section 235(3)(a) of FSMA, but we think that interpretation is not correct.
The requirement for profits or income to arise “from the acquisition, holding, management or disposal of the property” provides an important basis for excluding staking offerings from the scope of CIS. Staking does not involve an acquisition or disposal of property, and staking rewards do not arise from merely “holding” staked assets, even in custodial staking models. In our view, providing staking services cannot properly be described as “management” of staked assets either, unless the activities of the service provider are more akin to those of an asset manager than running software with predetermined functionalities.
Management of assets implies an exercise of managerial efforts and discretion. This must be distinguished from services providing merely technical/administrative support with validation activities without a scope to exercise discretion or deviate from the predetermined constraints of the software. For example, the purely technical/administrative type of services automatically distributes any staking rewards generated by the protocol directly to stakers (minus a predetermined service fee). In the case of smart contract-facilitated liquid staking in particular, there is no scope for human discretion as the functionalities of the software suite are determined by smart contracts.
This view is shared by James Burnie, Partner at law firm gunnercooke, in his article “What’s at stake? The legal treatment of staking” published in the October 2022 edition of the Butterworths Journal of International Banking & Financial Law and available here. We support Burnie’s analysis of CIS in the context of staking, and it is worth reproducing part of this analysis here. According to Burnie:
The breadth of the CIS definition is the biggest single hinderance to validator staking in the UK. It is also UK-specific and pre-dates the concept of proof-of-stake by 10 years. The question is therefore whether it is appropriate for validator staking arrangements potentially to fall within the definition of a CIS.
One principal purpose of the CIS regime is to regulate those arrangements which involve the exercise by managers of investment management decisions in respect of pooled assets aimed at generating wealth. In contrast, validators undertake valuable work (validation) and are rewarded for that work. Their decision making is limited to compliance (or otherwise) with specified, open-source and verifiable protocol rules. Validators do have discretion to engage in MEV related activities but this discretion could be limited through sub-contracting block-builders, contract or other technical MEV mitigation techniques. Where validator discretion is limited in a precise, transparent and openly verifiable way, it is not clear that the “management” element of validator staking poses the same (or equivalent) risk to investors as “management” in the sense of an investment management decision aimed at generating wealth.
Classifying staking arrangements as CIS would restrict access to staking for UK users who do not meet the conditions for participating in a CIS. This would go against the aim of democratising access to securing proof of stake networks. It would also burden staking providers with compliance costs, likely resulting in concentration of larger players at the expense of smaller providers. This would undermine the aim of ensuring the security of proof of stake blockchains through a vast, decentralised network of validators. As Burnie notes:
Validator staking involves the provision of valuable and important work for blockchain systems. Pooled validator staking arrangements potentially allow retail participants to contribute to the provision of this work and share in the rewards generated. This provides retail investors with an opportunity for exposure to a different type of risk than deposit accounts or schemes involving the investment of their assets. Pooled validator staking arrangements help to protect retail users through the reduction of technical/error risk and the reduction of concentration of penalty and slashing risk through the use of multiple validators.
Validator staking is a fundamental part of blockchain ecosystems and, if the UK is to become a global crypto-hub, it will be important to incentivise validators to use the jurisdiction of England and Wales. One option which could facilitate this is to introduce a new specific exemption to the CIS definition to allow for validator staking. Such an exemption could help to clarify and mitigate the types of risk that users take under a pooled validator staking arrangement, while incentivising validators – as some of the most important DeFi ecosystem participants – to base part or all of their operations in the UK.
We agree with this analysis and would encourage HMT to consider the above suggestion for an exemption to the CSI definition for validation activities.
Respectfully submitted,
CONSENSYS SOFTWARE INC.
by/
Natalie Linhart
Shehram Khattak
Bill Hughes
30 April 2023
Footnotes
It should be noted that analysis of web3 participation is not necessarily intended as synonymous with DeFi participation. Both terms are defined in varying manner, and both are often used synonymously, but we conceptualize DeFi as being one component of the web3 ecosystem. Analyses of web3 participation by users and developers should thus be understood as potentially being one step removed from analyses of DeFi specifically.
This data, however, may not paint a completely accurate picture of DeFi participation. Just because a UK person may have an unhosted wallet does not necessarily mean they are using DeFi protocols, although there is some degree of correlation that could be relied upon to get some sense of DeFi usage. Additionally, wallet provider data will be impacted greatly by their collection method. Usage metrics are generally only collected if the wallet holder has specifically opted into sharing such information. Many users do not opt into sharing product-improving data, which is and absolutely should be their right.
This does not mean to suggest that decentralised organisations need to operate without any human involvement. When the concept of decentralised autonomous organisations emerged in 2014, the main idea was to run organisations in a fully automated, human-independent manner. It was a response to the failures of the centralised systems, the lack of trust in powerful leaders and corporations, and the disappointment in existing governance mechanisms. Today, organisations are realising the need for a level of reliability and structure that is inspired by what some would consider “traditional”. The governance mechanisms currently used in the biggest DeFi protocols try to marry the openness and lack of centralisation with frameworks that make participants accountable. To achieve this, protocols introduce guilds or subDAOs that are responsible for management of different areas, including marketing, treasury, community growth, and grants. To become part of those groups, members of a DAO need to present their expertise by participating in the general community activities before being approved for the guilds. The more sensitive the topics the more walled the access to the guilds.