Web3 Protocol Interfaces: A Legal Playbook for Developers

This article explores the interfaces of protocols from a legal perspective. Interfaces are generally thought of as pure front-ends to a protocol, which is a type of interface that is currently unregulated. However if your interface performs other roles, then from a legal standpoint it may not qualify as a pure front-end interface and could be subject to regulation.

To help Web3 developers understand if their interface might trigger regulation requirements, we’ve written out a brief playbook that Web3 developers can use as a self-assessment tool on their interfaces. Read on to learn more about the three different types of interfaces and their legal implications.

Why interfaces require different legal treatment compared to protocols

As previously discussed in legal guides for Web3 developers, many protocols are evolving towards full decentralization. This means they are, or will become, permissionless (no longer requiring third-party administration) and borderless (accessible to users worldwide). As these protocols are “on-chain programs” deployed on the decentralized server (blockchain), they require interfaces for end users to access and use them.

However, when analyzing possible suitable legal structures for these interfaces, the question arises: “Should we legally treat the interface in the same way as the protocol?”. The answer is likely “no”. This difference in treatment is due to the fact that the purpose and functionality of the interface's tech layer (dApp) differ from those of the protocol's layer, leading to different risk profiles for each layer. Therefore, a different approach to legal structuring is necessary.

Understanding the differences between protocols and interfaces

Before assessing the suitability of a legal structure for protocols and interfaces, we must first identify the distinguishing factors between interfaces and protocols. These include:

1. Purpose: The interface serves as a user-friendly front-end of the Web3 project, allowing users to access the on-chain protocol. The protocol processes transactions and accrues value as a settlement layer of Web3 project.
2. Functionality: Protocols are “on-chain self-executable programs”, whereas interfaces are usually off-chain websites, mobile apps, browser extensions, etc.
3. Geographic scope: Protocols are borderless because they are deployed into a decentralized blockchain. In contrast, off-chain interfaces require centralized servers, domain names, trademarks, etc., and it is these factors that make it possible to identify the location where the interface operates. Consequently, interfaces are treated as country-specific.

We delve deeper into these distinguishing factors in our article Differentiating DLT, Protocol, and dApp for Proper Legal Structuring of a Web3 Project.

Why should we assess interface types before exploring legal options?

The common approach to the legal qualification of an interface is to treat it as a pure front-end part of the Web3 project. The interface is published for the sole purpose of allowing the end users to access, use, and interact with the protocol. However, upon deeper analysis of the interfaces’ purposes and tech structure, along with market case studies, there are some variables of interfaces worth exploring.

The purpose and functionality of the interface might vary from the pure front-end, which is published for informational purposes only, to the sophisticated front-end and back-end program. The latter facilitates users’ transactions, conducts active promotions and performs other activities that may trigger regulatory requirements, which—if ignored—can result in legal consequences. That’s why this article is focused on the practical steps that builders can take, in the form of a self-assessment tool for their interfaces. By using this tool, you can identify your interface type from a legal standpoint and to make better-informed assumptions of possible legal and regulatory considerations.

Let’s now consider the following 3 categories of interfaces:

• pure front-end
• front-end and back-end
• front-end and custodial on-chain elements

Interface type 1: pure front-end

Two key differentiating criteria exist with front-end interfaces:

• These interfaces are primarily used for informational purposes. Their content does not include active promotions, calls to action, or any other activities that encourage users to use the project, for example, by deploying funds or making trades.
• Their functionality does not involve any of the following: on-chain elements, backend features to facilitate user transactions (such as off-chain order books or off-chain oracles), or on-chain elements (like storing or processing users' virtual assets).

Regarding functionality, the most sustainable types of interfaces may include solutions like Liquity. Here, end-users can become front-end operators themselves. Although these technologies are in the early stages of development and not very user-friendly, they may become the preferred method of offering interfaces to fully decentralized protocols in the future.

Legally, pure front-ends and their operators are typically considered non-regulated interfaces that are not subject to VASP or CASP regulations.

Interface type 2: a combination of front-end and off-chain back-end.

This type of interface, which includes off-chain back-end functionality, could qualify as a dApp and may fall under the scope of crypto and VASP regulations.

To determine if an interface could fall into this category and be subject to regulation, Web3 builders need to examine the interface’s back-end functionality. They should consider:

• If there are off-chain functions that the on-chain protocol relies on, for example, the off-chain orderbook of a DEX protocol that provides transaction settlement information.
• If there are off-chain sources of information provided in a permission-based way to the on-chain protocol. For example, cases where off-chain events trigger on-chain transactions and the process of supplying information about events to the protocol is controlled by the interface operator (developers). To take the example further, imagine a decentralized AMM with an off-chain trading bot that provides smart contracts with off-chain trading strategies and where the trading bot is controlled by the developers.

The importance of this analysis is that it can help identify if the front-end interface operator is able to indirectly influence on-chain transactions. If, for example, a front-end operator is able to alter the workflow of an off-chain orderbook or act as a centralized oracle for the protocol, then they may be considered as an insider of the protocol, necessitating compliance with crypto and VASP regulations.

It is important to note that this second type of interface has not been specifically defined in VASP or CASP regulations. Instead, this approach has been somewhat established through case law in the United States.

Interface type 3: a combination of front-end and custodial on-chain elements on the back-end

For the third type of Web3 projects combining interfaces with on-chain custodial elements, the law is much clearer and these projects qualify as VASP / CASP and require compliance with the appropriate regulations.

The key criteria here is that the front-end operator (the interface provider) also controls the on-chain elements of the protocol, and as a result, they have direct access to users' crypto funds. Examples of these projects include CEXs, custodial wallets, and centralized digital asset managers. Since there is little doubt that this type of project will fall under crypto regulation requirements, two main questions arise:

• Which jurisdiction’s crypto laws apply? This largely depends on the markets that the project plans to target.
• Which specific regulations apply? Once a jurisdiction has been pinpointed, Web3 builders need to determine the scope of regulatory requirements that should be applied to the project, by assessing the types of crypto asset services the project plans to provide.

💡 Worth checking: How to Legally Structure the IP of a Web3 Project

Navigating regulatory uncertainty over Web3 protocols 

Today, the legal qualification of interfaces to Web3 protocols appears to be the least addressed area in VASP and CASP regulations. Now that we’ve proposed a classification of different interface types, it is easier to identify slightly more regulatory clarity for the following two types:

• Interface type 1: front-end interfaces: These are unregulated. As pure front-end interfaces, operators have no access to users' funds or any other means to influence the on-chain layer of a Web3 project that processes users' funds.
• Interface type 3: front-end and custodial on-chain elements: These interfaces are regulated, as the operators in these Web3 projects control both the front-end and a custodial back-end containing users' funds.

This leaves interface type 2, which has a combination of front-end and back-end elements. This interface currently occupies a grey area and further guidance and clarification is required from regulators, along with greater certainty and clarity in VASP and CASP regulations.

It's also crucial to consider more than just the functionality of the protocol when attempting to legally qualify it. The texts along with any marketing and promotion activities structured around the protocol are criteria that also require analysis in the face of upcoming regulations. Web3 builders should be mindful of these changes, as regulated crypto promotions require (or will soon require) special approvals to be executed in specific markets.

Build a solid legal strategy for your protocol interfaces with Legal Nodes

Regulation in the Web3 sphere is rapidly changing and we’re working hard to bring you the latest information. Our resources regularly discuss regulatory risks and requirements and their implications for Web3 founders, builders, and developers. Learn more about the legal aspect of your Web3 projects by exploring these resources: 

• How to approach legal strategy for a Web3 project
• Building a legal roadmap according to the full (sufficient) and progressive decentralization concepts
• How to legally structure early-stage fundraising for a Web3 project
• Search our blog for more legal guides to help your Web3 project

At Legal Nodes we regularly help Web3 founders to navigate the complex and fragmented global landscape of virtual asset regulations. Discover how Legal Nodes helps builders and developers to launch their protocols and dApps. For help with the legal strategizing or structuring of your Web3 project, speak to us.