Consensys Responds to the AMF’s Discussion on Decentralised Finance

Consensys encourages the AMF to develop regulatory standards, the flexibility of which will better achieve the right regulatory outcomes while not severely undermining the technology.

Reading time

17 mins

We agree with the discussion paper’s observation that Decentralised Finance (DeFi) requires a new, thoughtful approach to regulating. DeFi poses in many respects unique challenges to regulators, and we are therefore encouraged by the step by step approach the Autorité des Marchés Financiers (AMF) is taking. We further agree that, before regulating DeFi, some common principles should be established, and we generally agree with many definitions outlined in the paper. However, as you will see in the response below, we want to caution against trying to set strict, bright-line rules for the DeFi space. Instead, we encourage trying to develop regulatory standards, the flexibility of which will better achieve the right regulatory outcomes while not severely undermining the technology.

DeFi and web3 more broadly are an innovative space, with new applications of all types constantly being developed and tested. Having a fit-for-purpose regulatory scheme not only requires flexibility to adapt to new developments quickly, but also close cooperation between regulators and market participants. We appreciate your engagement with the public on these issues.

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 decentralisation that this new computer network presented by supporting the development of blockchain-based computing software. We believed then, as we do now, that decentralised networks like Ethereum will 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 build and belong in the world they want to see. As of September 28th, Consensys maintains a global workforce consisting of 814 full-time employees, with 66 of them located in France. This represents over 8% of our total employee count. Linea, a prominent layer 2 blockchain protocol aimed at scaling Ethereum's capacity, was conceptualised and launched by a team based in France during the Paris-based event EthCC earlier this year.

MetaMask is the most broadly used self-custody wallet in the world by both web3 developers and users. In 2022, MetaMask surpassed 100M users, and France ranked 8th globally in terms of Monthly Active Users by country. 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 democratise access to the decentralised web.

Earlier this month, 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 expand 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.

Responses to Questions

1) Discussion point 3 – Use of open source software

We agree that traditional finance (“TradFi”) obviously does not leverage blockchain, and that centralised crypto finance (“CeFi”) involves off-chain services that relate to blockchain tokens (e.g. BTC, ETH) or blockchain functioning (e.g. staking as a custodial service). DeFi, in contrast, is characterised primarily by on-chain financial activity. While we anticipate that more TradFi services will move to blockchain over time, not all of them will be “DeFi” either in the immediate future or over the longer term. That is to some extent because blockchains can and do exist on a spectrum of decentralisation.

Where a particular project lies on that spectrum (with centralised services at one end and decentralised services at the other) depends on a number of factors, which include:

● 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 centralised process. A mechanism that relies on many sources that all serve publicly available data is a more decentralised process.

● Availability of the code - Protocols with unverified, non-public source code that is not permissively licensed are more centralised. Protocols that publicly verify their software and permissively license that software so it may be used, modified, and repurposed are more decentralised.[1]

● 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 centralised. 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 decentralised.

● 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 centralised. Protocols that do not require such administrative functions are more decentralised.

● Decentralisation of the native chain - Whether the blockchain on which the smart contract protocol sits is decentralised 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 centralised when the blockchain is more centralised, 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 decentralised 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 centralised where users access them through one or a small number of user interfaces built in a proprietary manner. They are more decentralised when users have many interfaces to choose from, with some being open source software interfaces. Here, Ethereum and MetaMask are great examples. 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 decentralisation generally.

2) Discussion point 4 – Assessment of risks posed by DeFi activities

We agree that, today, much of DeFi replicates a number of 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 will not bring desired results when the DeFi protocol at issue is not very near the “centralised” end of the spectrum.

We agree that, in situations where the pertinent factors reveal a protocol is mostly centralised, a more traditional regulatory scheme may be possible. Where the factors reveal a protocol that is largely if not entirely decentralised, however, then it is our view that 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.[3]

A jurisdiction’s influence will only go so far on a world-wide system. It therefore seems the choice that every jurisdiction is left with is (i) do not regulate such protocols at all; (ii) institute a blanket jurisdictional ban by penalising use, or (iii) a middle ground where compliance is largely achieved by smartly regulating persons and entities within their jurisdiction, including by incentivizing DeFi participants to comply voluntarily. The third option of incentivizing compliance would be a novel method, but one that is not completely unprecedented. We encourage regulators and supervisors globally to explore this idea further. Such an approach is also attractive because it serves the goal of encouraging decentralisation, which expands opportunity, the distribution of value, and reduces intermediary risks.

Some advocate for alternative approaches, including: (1) some DeFi participant (i.e. DeFi developers, users, interfaces, protocol investors) is selected to have all compliance responsibility, or (2) all participants together share responsibility without any one participant being singled out. In our view, neither of these approaches will work, especially as one gets further towards the decentralised side of the spectrum. That’s because the party or parties assigned responsibility do not have the individual ability to implement the necessary changes that would effectuate the regulatory goals, or do not have the ability to coordinate their conduct to the degree necessary to satisfy such burdens. 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 actually capable of bearing the responsibility, or are able to shield other participants from a loss. A regulatory regime which places impossible burdens on one or more participants as a precondition only serves as a de facto ban on the underlying activity.

While “how to regulate true DeFi” is a hard question to answer, it may in fact be more challenging to regulate protocols that are in the middle of the spectrum between centralised and decentralised, including those that are evolving from centralised to decentralised, in a way that does not unduly inhibit innovation. A regulatory regime should accommodate community efforts to decentralise a protocol over time, and regulators should study available examples of such a regulatory approach.[4]

Lastly, we also agree that not every smart contract has a financial application (i.e. borrowing, lending and investing). Adopting an overly broad definition of DeFi that ignores the type of activity and simply treats all smart contracts as being a financial service would ignore the realities of blockchain and, importantly, thwart French development of non-financial applications. It goes without saying, but the precise activity a smart contract performs is the critical question when deciding whether a certain regulatory scheme is appropriate in relation to that specific software. Moreover, regulators should recognize that some non-financial smart contracts will nonetheless be incorporated due to the composability of blockchain code into other smart contract protocols that do have financial applications. It should not result from this sort of arrangement that the former non-financial smart contract somehow gains a financial character by its incorporation by reference into a distinct lending, borrowing, or investment protocol, just as you would not label a seatbelt a military weapon simply because it has been incorporated into a fighter jet.

3) Discussion point 1 – Permissionless versus Permissioned blockchain protocols

Every network is permissioned to some extent in that only those who run code that satisfies the specifications of the protocol are permitted to participate. But that permissioning is reliable and non-arbitrary. It is reliable because the specifications do not frequently change, and in some instances do not change. And when they do change, they do so only with a wide consensus among the chain’s users, and those changes are transparent to the public. It is non-arbitrary because the system rather than people police whether someone is following the rules, and thus is allowed to participate, or is not following the rules, and is excluded.

In contrast, so-called “permissioned” blockchains are designed to exclude participants based on off-chain criteria that are not inherent to the functioning of the protocol. With such blockchains, it is not enough for a user to simply follow the system’s technical specifications because exogenous criteria must be satisfied too in order to participate. In such instances, whoever is setting those criteria may be susceptible for regulation depending on their authority to determine how expansive or specific those criteria can be.

Permissionless smart contract protocols are more decentralised than permissioned protocols. Permissionlessness may be thought of as where the rules of the system are generally not designed to control for off-chain criteria, and also where no participant has the ability to unilaterally or, without a broad consensus of participants whose interaction is governed by the protocol’s specifications, dictate what such off-chain criteria could be.

4) Discussion point 2 – Smart contracts

We disagree that the best characterization of a smart contract is that it mirrors the functionality of a real-world legal contract between parties. In many if not all cases, they are more analogous to a machine that performs a specific function when given a set of required inputs, and when the user pays to use the machine (i.e. transaction fees).

It is important to remember that a blockchain transaction is really only the activity of the sender, not an agreement between the sender and receiver. Indeed, in many cases, a public address that uses a smart contract will not be impacting any other user public address but itself after completion of the transaction. There is no counterparty in such an instance. It is just a user leveraging the computer logic of a smart contract to conduct a transaction on the user’s own behalf. Similarly, when public address A uses a smart contract to execute a transaction that affects the token balance of public address B, the latter public address has absolutely no ability to stop or reverse the transaction. Public address B can only undo the transaction by entering into a second transaction, one which public address A has no ability to stop or reverse. It is therefore not a proper characterization to say that public address A has entered into a legal contract with public address B. Instead, public address A used the functionality of a smart contract like a person uses the functionality of a physical machine, with specific inputs and outputs, in order to achieve a specific transactional result, regardless of what public address B agreed to or was even aware of. It is for these reasons that smart contracts should be thought of more as machines and less like contracts.[5]

Further, it is more than just rhetorically important to recognize that transactions do not run “through” smart contracts. This analogy of a blockchain transaction being a series of pipes where a transaction commences at one end, passes through a junction where a smart contract processes the transaction, and continues to a destination is not an apt analogy at all. It suggests a linear, assembly line-like process whereby the smart contract is the thing that is acting upon the user’s funds. That is simply not an accurate way to conceptualise what is happening in a blockchain transaction.

Instead, a smart contract is properly understood to be a publicly available set of coded instructions that a user can add to a transaction that the user composes. That smart contract logic forms a basis of the instructions that the user will cryptographically sign using his or her private key and send to an open pool of pending transactions that the validation process compiles into blocks and adds to the network’s data state, not in a series of changes but in a single change reflecting many new ledger entries. The critical insight here is that the only participant that is really doing anything in this process is the user who signs the message and sends it to the mempool. The smart contract is just an expression of computer logic that is retrievable from the blockchain’s data state, dictating what inputs are required and what predetermined outputs are the results of the logic. The process of transaction validation simply determines whether the user’s instructions, which include the smart contract logic, comply with both the rules of the network and the latest state of network data. It is thus true that, through these networks, users are very much conducting a transaction that is not intermediated. It is equally true that smart contracts themselves are not in any sense intermediaries.

5) Concerns regarding Oracles

The key caveat to DeFi being purely on-chain financial activity is that such activity often requires, at least in part, off-chain information that is collected and served via data “oracles.” The availability, accuracy, integrity and latency of this data is critical to the functioning of a healthy DeFi ecosystem. Centralised entities that are operating a business providing data to DeFi protocols are properly the subject of regulation. Manipulation of such data is a meaningful risk as the DeFi ecosystem grows and is the proper subject of regulation, but we caution that both centralised and decentralised oracle solutions are being developed, and just like with on-chain software, whether any one party or collection of parties are actually capable of discharging all relevant compliance obligations will depend on how the oracle protocol operates. Technological solutions to these risks should be encouraged, better understood, and closely monitored by regulators.

Respectfully submitted,

CONSENSYS SOFTWARE INC.

by/

William C. Hughes

Natalie Linhart

29 September 2023

Footnotes

[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 to 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 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] As you undoubtedly recognize, developers in far flung regions of the world can upload a smart contract that can be accessed by anyone in the world. There simply may be no practical way to exert any persistent regulatory influence on such developers outside of one’s jurisdiction. The same can be said in reverse: an on-chain protocol that is published and maintained in one jurisdiction can be accessed and used by people all over the world without limitation.

[4] See, e.g., Hester Pierce, Token Safe Harbor Proposal 2.0 (dated April 13, 2021)

[5] This may simplify the regulatory question: When an identifiable party publishes, markets, and maintains a smart contract for profit (akin to a software as a service business), then they may be the proper subject of regulation. And the legal theory by which compensation for an injury may be pursued may look more akin to false advertising, if the smart contract operates differently than indicated, or product liability, if it is negligently constructed. Further, like many products available to the public, services using smart contracts may be more safely offered if accompanied by informative disclosures about foreseeable risks.