Partnered With:

a16z Regulatory Series: Practical application of the Web3 Regulatory Framework

Read this article in 47 Minutes

How can the Web3 regulatory framework be applied in practice?

Regulate Web3 Apps, Not Protocols Part IV: Practical Application

Original article by Miles Jennings and Brian Quintenz

Yangz, the way of DeFi

This article is the fourth in a series called "Regulating Web3 Applications, Not Protocols," which establishes a Web3 regulatory framework to maintain Web3 The benefits of technology protect the future of the Internet while reducing the risk of illegal activity and consumer harm. A core principle of the framework is that enterprises should be the focus of regulation, not decentralized autonomous software.

The "Regulate Web3 applications, not protocols" framework established in Parts 1, 2, and 3 of this series is based on regulatory agnostic - meaning that it has no fixed view of what types of regulation should apply to Web3. Instead, the framework provides a way to evaluate and apply Web3 business regulation, including in relation to market structure, KYC, privacy, or any other type of regulation currently applied to Web2 businesses. The framework states only that regulation should have a legitimate objective, be appropriate to the entities and activities it seeks to regulate and the risks it seeks to address, and remain truly "technology neutral" (not picking winners among nascent technologies).

In Part 4 of this series, we show how the framework applies in practice to hypothetical market structure regulation (i.e. legislation and corresponding regulation governing the trading of digital assets on trading platforms).

We first define the scope of hypothetical regulation, then explain how the different rules and requirements of regulation apply to different types of participants and applications in the web3 domain. This analysis shows why the most demanding requirements in regulation should be applied to the applications that pose the greatest risk to users, while those that pose the least risk should be subject to less regulation. This risk-weighted approach ensures consumer protection while also protecting innovation.

While the regulatory examples we discuss here focus on financial use cases in the cryptographic direction, this analysis should show that the framework of "regulating Web3 applications, not protocols" can be used in the future to appropriately tailor a range of Web3 regulations, including those related to social media, the gig economy, and content creation applications.

Definition of the Ordinance

We begin our analysis by defining the hypothetical regulation to which we would apply the framework and assessing whether that regulation should be incorporated into the Bank Secrecy Act (BSA).

Market structure supervision

Market structure legislation is the focus of many policymakers and regulators in 2022 (e.g. DCCPA, DCEA, RFIA Etc.), they believe that regulation of the digital asset market is necessary. We expect that, driven by the following policy objectives, 2023 will see renewed efforts to introduce market structure legislation and regulatory implementation.

- Protect users from risks, including those arising from custodial relationships, conflicts of interest, and illegal asset trading on unregistered trading platforms.

- Restrict trading in illicit assets, including tokenized securities and derivatives;

- Promote innovation

While it is possible for decentralized trading platforms to be excluded from any market structure legislation and implementation regulation in the short term, ultimately they are unlikely to operate outside the scope of regulation forever. Such an arrangement would (1 ) Greatly unfavorable to centralized trading platform, (2 ) May reintroduce traditional centralized risk into the decentralized finance (DeFi) ecosystem, (3 ) Thus negating the effectiveness of any market structure legislation and implementation regulation. If policymakers include DeFi in the scope of these legislative and subsequent regulatory efforts, they must tailor their objectives and specific regulatory requirements appropriately to the risks that different DeFi entities and activities pose to the ecosystem and its users.

We assume that the new Market Structure law includes a baseline requirement that any trading facility that directly facilitates the trading of digital assets must comply with the registration requirements of one or more of the new implementing regulations.

The aim is for the law to cover any trading platform (centralized or decentralized) where users can directly trade digital assets. The law also includes certain compliance obligations relating to (1 ) Custody of client assets, (2 ) Listing Rules for digital assets exchanged using trading facilities, (3 ) Record retention requirements for all trading activities, (4 ) Transaction Processing Guide, (5 ) Conflict of interest, (6 ) Governance standards, such as establishing systems to protect against operational and security risks, (7 ) Reporting requirements, (8 ) Minimum financial resources, (9 ) Disclosure of risks associated with the use of trading platforms, and (10 ) Code audit. For our purposes, we shall refer to this hypothetical statute as the Regulations.

Now that we have outlined the principle requirements of the Regulation, it is worth discussing what the Regulation does not cover. First, any market structure legislation is likely to include a statutory definition of when a digital asset should be considered a security or commodity, thus giving the SEC or the Commodity Exchange Commission specific (or combined) authority to enact and enforce the Regulations. However, whether digital assets are securities or commodities is irrelevant to the purpose of the framework, which is to evaluate and apply business-based regulation - not asset-based regulation.

A digital asset is not an application, protocol, or decentralized autonomous organization (DAO), it is an asset. Thus, even though many web3 builders and policy makers are eager for the guardrails provided by this clarification, a clear definition is not actually needed to apply the "regulate web3 applications, not protocols" framework.

Second, any market structure legislation and implementation Regulations may also include rules relating to other market participants (introducing brokers, brokers, custodians, etc.) and other activities normally associated with trading platforms. Regulations designed for these other types of market participants may actually be more appropriate for some decentralized trading platform applications because the nature of the application's activities is more similar to those of these other participants than it is for traditional trading platforms. For example, a decentralized trading platform that guides and directs orders may function more like a referral broker under the Commodities Exchange Act than a normal centralized trading platform; Or it might be better suited like SEC "Best execution" rules, rather than a trading platform system. However, for the sake of simplicity, we exclude the rules that apply to these market participants and consider all applications that directly facilitate the trading and exchange of digital assets as trading platforms. In any case, even if the proposed regulation were to establish rules relating to these other actors, the following analysis could evaluate the application of these rules to decentralized trading platforms in the same way.

Bank secrecy Act

The Bank Secrecy Act (BSA) - legislation designed to prevent criminals from using financial institutions to hide or launder money - and its implementation impose certain obligations on financial intermediaries, including customer due diligence (CDD) and Customer Identification Program (CIP) requirements (applicable to banks and broker/dealers, etc.), Or require verification of customers and fulfillment of certain reporting obligations related to customer data and authentication, often referred to as "KYC" measures (for example, for money services businesses or "MSBS"). Given the role of trading platforms in the wider Web3 ecosystem, market structure legislation and implementation of the Regulations have the potential to make digital asset trading platform activities subject to BSA requirements. These requirements will have little impact on centralised trading platforms because they are already regulated by the BSA as MSBS; However, it may not be necessary or beneficial to apply the requirements of a BSA to an application that provides protocol access to a decentralized trading platform (and is not regulated as a bank or MSB). In practice, these requirements may significantly distort the outcome of the Regulations and ultimately contradict the policy objectives behind the Regulations. Here's why:

First, the policy objectives of the BSA can be achieved without applying KYC requirements to applications that provide decentralized trading platform access. While the Bsas are required to help law enforcement investigate illegal conduct, investigators in practice have been able to effectively obtain the required attribution evidence from legal currency funds already covered by the Bsas, such as centralized trading platforms and payment processors (MSBs), as well as banks. For example, existing regulatory measures already apply to money transmitters, including centralised trading platforms (e.g. Coinbase And Gemini) and other virtual asset service providers, such as Transak and Moonpay, requiring them to verify the identities of users bringing money into the chain. This information allows private sector, law enforcement and regulatory investigators to gather attribution information about users who trade through these mechanisms, including any trades executed through decentralized trading platforms.

Second, adding significant new friction to the user experience of apps that provide decentralized trading platform protocols could undermine all three policy objectives of the Regulations, pushing users away from regulated and legally compliant apps to non-compliant or completely unregulated apps. As discussed in Part 3 of this series, the emergence of such unregulated or non-compliant applications is an inevitable result of establishing open and unlicensed Internet protocols. Therefore, effective regulation needs to be designed to incentivize users to use regulated applications. Requiring all applications to implement KYC measures may have the opposite effect.

Blockchain's transparency acts as a very powerful incentive for users to protect their privacy -- accidental (exploits or hacks) or purposeful disclosures by parties collecting personally identifiable information (PII) can lead to damaging effects, exposing users' entire transaction history and making them potential targets for criminal activity, including identity theft, robbery, and kidnapping. As a result, users are incentivized to provide PIIs to as few parties as possible. Incentives and opportunities to evade KYC requirements jeopardize the success of the Regulations, potentially exposing users to greater risk, increasing trade in illicit assets, and impeding innovation. In addition, the application of BSA requirements to certain applications may, in some cases, raise the possibility of constitutional challenges.

Third, the problem of impeding innovation is compounded by the costs that BSA obligations will impose on start-ups. In particular, compliance procedures and data privacy costs may prove insurmountable for businesses operating nascent for-profit or non-profit applications, creating a disincentive for entrepreneurs to create and operate them. This will reduce the number of applications available to users and reduce competition, which may introduce centralization risks. For example, since for-profit applications that can comply will benefit from a lack of competition, these applications will be able to exert more influence over the underlying protocol. Ultimately, this may result in the protocol's network effects actually ascribe to these powerful applications (e.g., as more users seek to use the web, they will be directed to for-profit applications), which will allow them to extract greater revenue from their users. This dynamic is the antithesis of what blockchain technology is designed to achieve: a free, open, and decentralized Internet. This anti-innovation environment will encourage entrepreneurs to build elsewhere and could lead to less transparency in U.S. law enforcement.

Fourth, adding BSA requirements to the Regulations could undermine the financial inclusion advantages of blockchain technology. For example, decentralized trading platforms are a key pillar of blockchain-based financial systems, which promise to make financial services, including loans, savings and insurance, available to a wider range of people than the current banking system. The KYC requirement would shorten that commitment, making it less likely that poor and vulnerable people, including refugees, will take advantage of the technology.

In summary, it makes sense that current U.S. law exempts most applications and protocols from Bsas. As FinCEN makes clear in its 2019 guidance, non-regulatory, self-executing code or software does not itself trigger BSA obligations because the software vendor is not a money transmitter. FinCEN states that those who provide "services used by a money transmitter to support the delivery, communication or network access of money transmission services" do not fall under the definition of a money transmitter. [ 31 CFR § 1010.100 (ff)( 5)(ii)]. This is because the supplier of the tool (communication, hardware or software) is "engaged in trade rather than money transmission".

For the above reasons, we have not incorporated any requirements relating to the Bank Secrecy Act in the Regulations or our analysis of their application.

Application of the Ordinance

We will now show how the Regulations (without any BSA-related requirements) are applied in practice, including applications with different characteristics, from centralized trading platforms all the way to simple block resource managers. We summarize our analysis in the table below, which charts relative risk, number of users, and regulatory requirements for each type of application analyzed.

a16z：Web3 监管框架的实际应用

In addition, we evaluated the applicability of the Regulations to developers of decentralized autonomous organizations (DAOs) and web3 protocols and applications. The results of our analysis are set out in Schedule A.

Centralized trading platform

The registration requirements and ongoing compliance obligations of the Regulations should apply to any business operating a trading facility that directly facilitates the trading of digital assets through proprietary software rather than through the use of decentralized trading platform protocols. In this case, the business decides which assets clients can trade, acts as a trusted intermediary between clients, and acts as custodian of clients' money - and all of these services are provided for profit. The centralized nature of trading platforms introduces the legacy risks that the Regulations (and other existing financial regulations) are designed to address. Therefore, we hope that every requirement of the Ordinance will be applied to centralised trading platforms. However, given that centralised trading platforms operate using proprietary software rather than via smart contracts deployed on the blockchain, the code audit requirements would provide few benefits - transactions within the trading platform would be entirely controlled by the trading platform, whose execution would be subject to other requirements of the Regulations.

Decentralized trading platform

For the reasons we discussed in the first part of this series, the Regulations should not and cannot apply directly to any web3 agreement, whether or not they directly facilitate the transaction of digital assets. Quite simply, there is no way the agreement could meet such a requirement. For example, it is impossible for software to make the subjective judgments required to comply with listing rules. Even if it could, it would have no way of complying with the conflicting listing rules each jurisdiction is trying to implement. There is no way to apply the Regulations to the agreement without prejudice to the basic principles of the agreement that we discussed in Parts I and II. That is, the protocol must be open source, decentralized, autonomous, standardized, cension-resistant, and permissive.

However, if web3 protocols are exempt from the Regulations, then the definition of what constitutes an "agreement" is important. If the definition is too broad, then centralized enterprises can simply circumvent the Regulations by using smart contracts deployed on the blockchain rather than proprietary software off the chain. If it is too restrictive, no agreement can be excluded.

The statutory definition of what constitutes an "agreement" should be drawn from the underlying principles of the agreement and balanced with the policy objectives of the Regulations. Exempting agreements that comply with these principles will then serve as a self-reinforcing incentive for other agreements to adopt them and contribute to an open, free and trusted neutral Internet.

特别是，直接促进 Token 交易的协议，如去中心化的交易平台协议（DEX），要想获得豁免，应具备以下一些或全部特征：

Open source: The protocol should be open source, as this ensures that the network effects of the protocol belong to its users and not to the owner of the intellectual property supporting the protocol. Making protocols open source also ensures that they can be forked by competitors, which helps prevent the protocols from gaining popularity and then seeking to reap huge revenues from their users, a practice that has played out over and over again in web2's centralized and proprietary systems.

Decentralization: Similarly, the agreement cannot be controlled by any individual or centralized stakeholder, as such control would jeopardize the credible neutrality of the agreement. Maintaining trusted neutrality is critical to maximizing the network effects of a protocol because it is a strong incentive for third parties to build on top of the protocol and develop the protocol network.

Autonomy: Agreements should generally operate as autonomously as possible. The inclusion of human intermediaries in the operation of software protocols greatly weakens the effectiveness of the protocols and carries some risk that these intermediaries may use the protocols to pursue their own interests. In the case of a decentralized trading platform agreement, certain limited exceptions should be made to enable the suspension or suspension of trading to mitigate potential risks to users in the event of abuse of the agreement. In addition, it may be advantageous to allow adjustments to certain parameters of the agreement, such as fees incurred from a particular liquidity pool. However, any such power should not enable the administrator of the agreement to materially alter the primary purpose of the agreement or control the user's funds.

标准化：协议应尽可能地利用标准或建立标准，以最大限度地提高其潜在的可组合性。例如，使用 Token 标准，如 ERC 20 和智能合约标准，可以确保协议的可组合性更强，更安全，并在整个生态系统中更广泛地受益。

Censorship resistance: The agreement must not have the ability to review individuals or transactions. While the power to review may seem attractive, this power jeopardizes the credible neutrality and utility of the agreement, including its vulnerability to abuse by bad actors. For example, a DAO with the power to change protocols to vet users can sufficiently incentivize individuals to seek control of the DAO to vet their competitors. It is conceivable that if the email protocol SMTP has the ability to censor certain vendors, then large email service providers like Google might seek to use their influence to gain control over SMTP and censor rival email services like Microsoft or Apple. In addition, the ability to review jeopardizes the autonomy of the agreement and may subject it to globally conflicting regulatory schemes that are impossible to comply with.

De-licensing: Similarly, the agreement must be de-licensing to maintain its credible neutrality. As with censorship, licensed agreements can be used for malicious purposes by bad actors who can try to prevent their competitors from using them. Furthermore, the de-licensing nature of the protocol is critical to maximizing its potential network effects, which are directly related to the utility of the protocol. If developers need permission before setting up agreements, they will be more likely to build where such permission is not required. Thus, the effect of one jurisdiction imposing licensing requirements on an agreement will encourage builders to simply develop in jurisdictions that allow de-licensing.

Decentralized trading platform application

In Part II, we provide a framework for assessing whether a particular regulation should apply to an application using a particular protocol. The framework analyzes the purpose of regulation, assesses the characteristics and risks of the applications to be regulated (including whether they are for profit and whether their primary purpose is to directly promote the regulated activity), and examines the constitutional significance of applying the regulation.

In applying the framework to many of the rules and requirements of the Regulations, it seems likely that all the rules (other than the regulatory rules) will be formulated in such a way that applications facilitating access to the DEX will be able to comply. For example, applications should be able to comply with rules regarding listing, record retention, and conflicts of interest. Ultimately, as long as the rules do not require the application to control or dictate the operation of the underlying DEX protocol, they should in theory be complied with. However, according to the framework, regulatory rules should not apply to any non-regulated application -- the risks that such regulatory rules address only arise when the application is regulated, so it does not make sense to apply such rules to non-regulated applications.

Next, we can consider the policy objectives for which the Regulations apply and predict that these objectives will vary according to the specific characteristics of the application to be regulated (for example, characteristics relating to the functionality of the application, whether it is operated for profit, etc.). These characteristics reveal where there may be risks of information asymmetry, centralization, or market integrity from the size and impact of the trading environment. In addition, these characteristics indicate where the desire to foster innovation may outweigh the needs of regulatory, nascent for-profit applications, non-profit applications, and block explorers in general.

To illustrate how regulation applies to unmanaged applications that use decentralized protocols, we can break them down into four categories: (i) mature for-profit applications, (ii) nascent for-profit applications, (iii) non-profit applications that are designed to directly facilitate digital asset transactions, and (iv) non-profit applications that are not designed to directly facilitate digital asset transactions.

Mature for-profit applications

The strongest case is to apply the Regulations to mature companies operating apps that directly facilitate transactions of digital assets through DEX. First, if the Regulations do not apply to these applications, the policy objectives of the Regulations can easily be undermined. Without the compliance burden, these apps can offer lower transaction fees and attract users from centralised trading platforms to circumvent the Ordinance. Second, given that these apps are for profit, they may introduce certain risks of conflicts of interest (related to the presentation of trading information, charging or trading routes) similar to those of centralised trading platforms. Ultimately, regulation should be technology-neutral -- not favoring one technology (decentralized trading platforms) over another (favorite trading platforms) -- unless they have different risk profiles or overwhelming policy objectives that require different approaches.

One argument in favor of exempting mature for-profit apps is that the policy goal of promoting innovation outweighs the goal of protecting users from risk and limiting illicit asset trading. We argued in Part 2 of this series that the case for promoting innovation is supported in web3, given that its decentralized protocol effectively becomes a common infrastructure that anyone can use (similar to SMTP/ email). Thus, reducing the compliance burden for applications that leverage DEX infrastructure can help incentivize further development of such infrastructure. However, these applications are mature (they have a large number of users and/or high trading volumes) and exempting them from regulation may increase the overall weight of the above risks, which, combined with the risk of substantial regulatory arbitrage, makes it unlikely that the objective of promoting innovation will outweigh the other policy objectives of the Regulations.

Given the above, these applications may be subject to the same requirements as centralized trading platforms, unless they do not engage in specific activities (for example, if they do not hold user assets). Moreover, they should be subject to requirements tailored to their unique risks. For example, we want these applications to be subject to code audit requirements because they take advantage of smart contracts deployed on programmable blockchains. These audit requirements may also cover application integration with smart contracts to ensure that the application provider does not engage in deceptive activities, such as trading ahead of a user's transaction or offering a slightly higher price to the user and keeping the difference. While these actions may be seen by regulators in turn, the false evidence left behind by these crimes may not be enough to ensure that users are protected from such activity. In addition, such activities may be prohibited by other elements of the Regulations which would be more appropriate if they did not involve the operation of the agreement. Therefore, a code audit may be a more appropriate requirement.

Conclusion: The registration requirements of the Ordinance, excluding custodial requirements but including code audits, are subject to compliance.

New for-profit apps

For nascent or small for-profit applications, the above balance of innovation and competitiveness policy objectives may favor promoting innovation. For example, if the application falls below the threshold related to the number of users, trading volume, or trading commission, the amount of risk for users and illegal trading volume will be greatly reduced. At the same time, the cost of applying onerous regulatory barriers to entry or regulatory economies of scale to nascent or small for-profit applications can be prohibitive for web3 innovation, especially in the early stages of technological development. If applied, the Regulations could effectively act as a moat, stifling competition. Thus, in these cases, the policy objective of promoting innovation may outweigh the risks addressed by the regulation. A "regulatory sandbox" or "safe harbor" that exempts these applications from the requirements of the Regulations may be appropriate.

However, even if regulators believe nascent for-profit apps are exempt, consumer protection regulations, such as disclosure requirements, can help inform users about the risks of using DEX. Code audit requirements can also protect users of the application from smart contract failures of the DEX, while ensuring that the application functions as advertised. Therefore, it may be prudent to condition these applications' exemption from registration on their compliance with prior risk disclosure and code audit requirements, or continuing requirements as the risk profile or code changes. This balance will help protect customers without overburdening new entrants and stifling competition and innovation.

Conclusion: May be exempt from the registration requirements of the Ordinance, but subject to prior or ongoing disclosure and code audit requirements.

Non-profit application designed to directly facilitate the trading of digital assets

If web3 applications are not run by businesses for profit, then the relative weight of the policy objectives of the regulation should be more conducive to promoting innovation. Non-profit apps are less likely to run many of the risks of for-profit apps, especially when it comes to conflicts of interest. Moreover, if no one profits, there is little or no incentive to create conflicts of interest or to encourage operators to facilitate illegal trading.

However, a minimum level of protection can still be achieved by continuing to apply disclosure and code audit requirements. These applications are either developed with the specific purpose of providing users with access to the DEX, or are designed to direct users to a particular DEX, so they should be responsible for providing users with upfront risk disclosure and code audit requirements, or ongoing requirements as the risk profile or code changes. Both of these requirements can be easily met, which means they are less of a barrier to innovation but provide meaningful protections for users.

Conclusion: May be exempt from the registration requirements of the Regulations, but subject to prior or ongoing disclosure and code audit requirements.

Non-profit application not specifically designed to directly facilitate the transaction of digital assets

If an application is simply a block resource manager or other general purpose tool that interacts with blockchain and smart contract protocols, then it should not be subject to the Regulations and their requirements. Applying the Regulations in such circumstances would be akin to directly regulating underlying agreements and would stifle innovation. The boundaries between regulatory software and enterprise need to be protected, and nowhere is this more appropriate than here. Even the disclosure and code audit requirements discussed above should not apply to such generic applications, many of which are tools capable of interacting with every protocol that exists on a particular blockchain. As a result, code audit and disclosure requirements would be impractical or even impossible to comply with.

Conclusion: Excluded from all requirements of the Regulations.

Decentralized trading platform DAO

If DAOs that maintain and manage DEX transactions are able to profit from any transactions executed through DEX, then DAOs will effectively be incentivized to facilitate and encourage trading through unregistered trading platforms that provide the most relaxed and least regulated trading environment, including in the listing of assets. This would significantly undermine the policy objectives of the Regulations relating to the protection of users and the suppression of illicit trade. Therefore, in order to ensure that the policy objectives of the Regulations are met, DAOs of any DEX may be subject to certain additional safeguards (including not allowing DAOs to receive commissions on transactions initiated by non-compliant applications and other transactions). In the case of the Regulations, such safeguards may establish the following restrictions:

A decentralized organization responsible for developing, operating, managing or maintaining any DEX shall be required to (i) utilize reasonably designed mechanisms to prevent fees and/or commissions from being charged to DAOs, directly or indirectly, for transactions initiated through applications facilitating transactions in digital assets, which are not registered under and in compliance with these Regulations; (ii) Waiver of activities whose primary purpose is to facilitate or encourage the execution of transactions through applications that directly facilitate transactions in digital assets and which are not registered under and in compliance with this Ordinance.

These safeguards will ensure that DAOs cannot profit from transactions initiated by unregistered applications, thereby incentivizing DAOs to encourage and facilitate transactions through registered applications, and removing any incentive for DAOs to encourage and facilitate the use of such unregistered applications to circumvent the regulations.

Developers of decentralized trading platforms

There should be no direct regulation of individuals or businesses that develop or distribute software. Such restrictions impose huge costs and do no good. Excessive encroachment on individual freedoms to successfully curb the development and distribution of open source software will be challenged and defeated on constitutional grounds. However, until such restrictions are finally defeated legally, the introduction and approval of such restrictions will have a lasting and irreparable impact on their role in shaping our collective digital future.

conclusion

Effective regulation of Web3 is an important task, complicated by the existence of decentralized and autonomous global software. Instead of regulating this software, however, we must focus on customizing regulations similar to the regulations for the businesses that run applications on it. As shown above, the process must begin by establishing clear policy objectives and include the dynamic weighting of these objectives according to the characteristics of the applications to be regulated. In addition, it does not require the elimination of the possibility that Web3 technology may be used for illegal activities, but it does require measures aimed at reducing the risk of and suppressing illegal activities. In addition, safeguards are necessary to ensure that DAOs are not used as vulnerabilities, but developers themselves should not be regulated under any circumstances.

Finally, proper regulation of Web3 technology can unlock its potential and add many new forms of native functionality to the Internet. This new network layer will act as the public infrastructure upon which millions of new Internet businesses will be built.