Executive Summary
Non-custodial user interfaces to decentralized finance (DeFi) protocols, aka. frontends, are the most visible part of any DeFi protocol, and frontend operators are often the first point of regulatory inquiry. Yet visibility and regulatory responsibility are not the same thing. No jurisdiction has issued specific regulatory guidance on the treatment of DeFi frontend operators, and the legal position remains subject to considerable uncertainty. This article examines the existing regulatory landscape across the EU, the United States and Switzerland, and sets out our current reading of how non-custodial frontend operators should be treated under applicable law.[1]
You will learn:
- Why the technical architecture of DeFi transactions places the frontend outside the transaction path
- How EU, US and Swiss regulations may apply to non-custodial frontend operators based on our analysis
- Best practices for frontend operators to mitigate legal risk
Our conclusion: operating a non-custodial frontend clearly does not make you the ‘operator’ of the underlying protocol. While this reading has not yet been confirmed by regulators or courts in any jurisdiction, a detailed look at the technical architecture can, in our view, only support this legal position. That does not mean that the operation of a frontend is entirely unregulated and we recommend the following best practices:
- Proper frontend disclaimers and terms: Information displayed on a frontend should be accurate, and proper frontend disclaimers and terms and conditions should be implemented to provide users with transparent, fair and non-misleading information including specific risk disclosures.
- Decentralization of frontend operation: Frontends themselves could be hosted on decentralized infrastructure, or frontend code can be open-sourced to ensure users have easy options to interact with the underlying protocol even if one frontend is down.
- Blocking IP-addresses from sanctioned regions or limiting accessibility from blacklisted addresses can be an additional safeguard to limit exposure.
What Is a DeFi Frontend
To assess the legal position of a frontend operator, it is necessary to first understand what a frontend actually does and, equally important, what it does not do. The legal analysis follows directly from this technical reality.
How a DeFi transaction works
Consider a typical transaction on Ethereum, such as a token swap on a decentralized exchange. The process involves five steps:
- The frontend reads publicly available on-chain data via an RPC provider (such as Infura or Alchemy) and renders it in a human-readable format: token balances, pool states, exchange rates.
- When the user wants to execute a transaction, the frontend assembles a proposed transaction payload and presents it to the user for review.
- The user reviews this proposal and independently signs it with their private key in their self-custodial wallet (such as MetaMask or Rabby).
- The wallet submits the signed transaction to the blockchain through its own configured RPC provider. The frontend is not involved in this step. It does not sign, transmit, route or relay the transaction.
- The blockchain’s validators execute the smart contract logic. Settlement happens entirely on-chain.
The frontend’s role ends at step 2. From that point forward, the transaction flows from the user’s wallet to the blockchain without passing through or being handled by the frontend.
The frontend sits on the information path only. The transaction path bypasses it entirely.
What a frontend is, and what it is not
A DeFi frontend is a user interface that reads publicly available blockchain data and helps users compose transaction proposals. It is a visualisation layer. It does not execute, settle, transmit or route transactions. It is not an intermediary, not a custodian, not a counterparty and not a necessary component of the protocol. The protocol functions identically whether zero or one hundred frontends exist.
Frontends can be single-purpose or general-purpose
While many frontends are specific to a protocol, block explorers such as Etherscan serve as general-purpose frontends for the entire Ethereum blockchain. Through Etherscan’s “Write Contract” function, any user can interact with any smart contract directly, without any protocol-specific frontend at all. This demonstrates that protocol-specific frontends are simply more user-friendly interfaces to functionality that is already publicly accessible. They add convenience, not capability.
The comparison to a web browser is helpful here: a frontend reads data, renders it visually and helps users compose requests. It does not execute server-side logic and is entirely interchangeable. No one would consider a web browser the “operator” of a website it displays. The analogy has limits, as most DeFi frontends are purpose-built for a single protocol rather than being general-purpose tools. But the existence of block explorers like Etherscan shows that general-purpose DeFi frontends exist too, reinforcing that any individual frontend is optional and replaceable.
Regulation: Frontend operators are not responsible for the operation of the underlying protocol (in our view)
Important note: No jurisdiction has issued specific regulatory guidance on DeFi frontend operators. The analysis below represents our current reading of how existing legal frameworks should apply, based on the technical architecture described above and the general regulatory principles outlined in the first article of this series. This reading has not been confirmed by regulators or courts.
The first article in this series established a framework for assessing whether a DeFi protocol has an identifiable operator to whom regulatory obligations can be attributed. The threshold question is whether an identifiable person exercises legally relevant control over the protocol. Applying that framework to frontend operators, in our view, yields a clear result: just by operating a frontend, one cannot alter the protocol’s logic or block or reverse transactions at the protocol level, or transmit or route transactions. The frontend is simply an optional layer that is not necessary for the protocol’s operation. Of course, in practice, the frontend operator is often the same person that may hold admin keys to the protocol and may be regulated as the operator of the protocol because of this – however, the operation of the frontend alone cannot trigger any responsibility for the underlying protocol.
European Union
MiCA (Markets in Crypto-Assets Regulation), applicable since December 2024, provides that crypto-asset services provided “in a fully decentralised manner without any intermediary” should not fall within MiCA’s scope.[2] ESMA has acknowledged that there may be “varying degrees” of decentralisation and that each system must be assessed on a case-by-case basis. No specific guidance has been issued on how MiCA applies to frontend operators.
In our reading, when a non-custodial frontend is assessed against MiCA’s specific definitions of crypto-asset services, it should not qualify as any of them:[3]
- It should not constitute the “operation of a trading platform,” which requires the management of a multilateral system.
- It should not constitute “custody,” as the frontend never holds assets or private keys.
- It should not constitute “execution of orders,” as the frontend does not conclude transactions on behalf of clients.
- It should not constitute “reception and transmission of orders.” The user’s wallet, not the frontend, submits the signed transaction to the blockchain. The frontend neither receives nor transmits orders in any legally relevant sense.
We note, however, that this analysis remains untested. Regulators may take a different view, particularly where frontends incorporate features that go beyond passive data display, such as order routing, account aggregation or custodial elements.
United States
The United States has not enacted comprehensive legislation addressing DeFi frontend operators. However, several recent developments in legislation, enforcement and civil litigation provide useful signals, and the overall trajectory appears favourable.
Legislation. The GENIUS Act, signed into law in July 2025, is the first US federal statute to address digital asset service providers. While it is primarily stablecoin legislation, its definition of “digital asset service provider” (DASP) is relevant. The Act expressly excludes from the DASP definition, among others, “an immutable and self-custodial software interface” as well as the activity of “developing, operating, or engaging in the business of developing … self-custodial software interfaces.”[4] This is notable for frontend operators: a non-custodial frontend that does not hold user assets or keys shares the core characteristics of the excluded category. The qualifier “immutable” deserves attention, as it suggests that mutable frontends hosted on traditional web servers may not benefit from this carve-out, creating an incentive toward decentralised hosting models (discussed below). While the GENIUS Act does not constitute a general regulatory safe harbour for all frontend activities, it represents the first US federal statute to explicitly carve out non-custodial software interfaces from a regulated category. In addition, the CLARITY Act (Digital Asset Market Clarity Act), which passed the House in 2025 and is currently in Senate negotiations, would go further: Section 15H would direct the SEC to clarify when DeFi-adjacent activities, specifically including user interfaces that read or display blockchain data, do not trigger intermediary obligations. The bill also includes safe harbours for “non-controlling” blockchain developers. These provisions are still being negotiated and the bill has not yet been enacted.[5]
Enforcement. The only US regulation to specifically target frontend-like operators was the IRS/Treasury DeFi broker rule, published in December 2024. It was repealed via the Congressional Review Act in April 2025, and the IRS is now prohibited from issuing a substantially similar rule.[6] The SEC closed its investigation of Uniswap Labs in February 2025 without enforcement action.[7] In the Tornado Cash litigation, the Fifth Circuit held that immutable smart contracts that cannot be controlled by any person do not constitute blockable “property” under IEEPA, and OFAC subsequently delisted the Tornado Cash smart contracts in March 2025.[8]
Civil litigation. In Risley v. Universal Navigation Inc., a class action brought against Uniswap Labs, its founder and its venture capital backers, the courts have progressively rejected attempts to hold protocol developers liable for third-party misuse. The district court dismissed the federal securities claims in August 2023, finding that it “defies logic” to hold the drafter of a smart contract liable for a third party’s misuse of the platform. The Second Circuit affirmed this in February 2025, holding that the protocol’s smart contracts merely facilitated transactions and that promoting Uniswap or the UNI token did not constitute solicitation of third-party scam tokens. On 2 March 2026, Judge Failla dismissed the remaining state law claims with prejudice, ending the case. The ruling reinforces that providing permissionless, non-custodial trading infrastructure does not give rise to civil liability for fraud committed by unidentified third parties using that infrastructure.[9]
A note of caution. The criminal case against Tornado Cash co-founder Roman Storm illustrates that the legal environment is not uniformly favourable. In August 2025, a jury convicted Storm of conspiracy to operate an unlicensed money transmitting business, though it deadlocked on the more serious money laundering and sanctions charges. Prosecutors have requested a retrial on the unresolved counts for late 2026.[10] The case is distinguishable from passive frontend operation in several respects: Storm was a co-founder who actively developed, promoted and profited from the mixer, and the prosecution focused on his knowledge that criminal proceeds were being processed. Nevertheless, it demonstrates that US authorities will pursue criminal charges against developers where they can establish knowledge of and participation in illicit activity.
These developments collectively suggest a legal environment that is increasingly favourable to non-custodial frontend operators. However, the US regulatory landscape remains fragmented and continues to be shaped by enforcement and litigation rather than comprehensive ex ante guidance. Frontend operators with a US nexus should monitor developments closely.
Switzerland
No Swiss public authority has issued specific guidance on the regulatory treatment of DeFi frontend operators. However, the Swiss Blockchain Federation (SBF), a private industry association, published a circular in 2025 on the classification and regulatory treatment of DeFi under Swiss financial market law.[11] LEXR co-authored this circular as part of the Federation’s DeFi working group. While the circular is not a regulatory pronouncement, it represents a considered industry position and provides the most detailed available analysis of frontends under Swiss law.
The SBF Circular takes the position that frontends are “typically purely optional and not necessary for the actual operation of the DeFi protocol, nor [are they] involved in the direct interaction with the DeFi protocol.” It concludes that the frontend operator “has no control or influence over the DeFi protocol and thus cannot legally be considered its ‘operator.’”[12]
We share this reading. Based on the technical architecture described above, we believe that operating a non-custodial frontend should not establish the operator as the person responsible for the protocol’s activities under Swiss financial market law. However, we emphasise that this position has not been tested by FINMA or by Swiss courts, and it remains possible that a public authority could arrive at a different conclusion.
Best Practices
Regardless of how the regulatory treatment of frontends develops, we currently recommend (i) proper marketing language with appropriate frontend terms and risk disclosures, (ii) decentralizing the frontend operation itself as much as possible, and (iii) limiting access both on an IP-address as well as a blockchain-address level. In detail:
Marketing, frontend terms and disclosures
Under general legal principles such as unfair competition legislation, any website operator is also responsible for transparent communication. Also, be careful with the promotion of specific products as, for example, the active marketing of 100x leveraged options to retail users may by itself be a regulated activity in certain markets. Make sure you cover the following:
- Careful with active marketing: Assess whether the marketing or distribution of the financial product that the DeFi protocol offers access to may be a regulated activity itself. For example, Uniswap made certain tokens invisible in its frontend even though the tokens were still available in the protocol itself.
- Accurate information: Make sure information provided to users is accurate, and the protocol is characterised in a transparent, fair and non-misleading manner, which should include appropriate risk disclosures to users.
- Proper disclosures: Include proper and specific risk disclaimers for users and draft the terms with care to ensure legal liability and responsibility is clearly set out to the users. This includes clarifying that the frontend and the protocol are two very different pieces of the software infrastructure.
Decentralisation of the DeFi user interface itself
To emphasize decentralization, consider decentralizing the operation of the frontend or to host the frontend itself on decentralized infrastructure. Several protocols have developed approaches to frontend operation that further reduce regulatory risk and increase censorship resistance.
- The Liquity model. The Liquity protocol team does not operate its own frontend. Third-party operators are incentivised through a “kickback rate” mechanism that shares a portion of protocol rewards with the frontend. Anyone can launch a Liquity frontend without permission. This distributes risk, eliminates a single point of failure and creates meaningful censorship resistance.
- Immutable frontends. Hosting frontends on decentralised infrastructure such as IPFS or the Internet Computer ensures that they cannot be unilaterally taken down. After OFAC sanctioned the Tornado Cash smart contracts in 2022, the primary domain was seized, but decentralised frontend deployments maintained access to the protocol.
- Open-source frontend kits. Making frontend code open-source and providing deployment kits lowers barriers for third-party operators. This reduces single-point-of-failure risk and reinforces the principle that the frontend is a replaceable interface, not a controlling infrastructure.
Access limitations
The scope of sanctions is generally much broader than the scope of financial market regulations, that is, a service that is not regulated may still be subject to sanction regimes. As such, we recommend geo-blocking IP addresses from sanctioned countries to limit the access from users from these countries. Also, consider limiting access from blacklisted addresses.
Key Takeaways for Frontend Operators
The legal position appears favourable, but is not yet settled. In our reading of EU, US and Swiss law, operating a non-custodial frontend should not make you the operator of the underlying protocol and should not constitute a regulated financial service. The technical architecture of DeFi transactions supports this conclusion. However, no jurisdiction has issued definitive guidance on this point, and frontend operators should be aware that the regulatory position may evolve.
Communicate responsibly. Ensure that information displayed on the frontend is accurate and that the protocol is characterised in a transparent, fair and non-misleading manner. Be careful with marketing language and include well-drafted risk disclaimers and terms.
Consider decentralised hosting. Immutable frontends, open-source deployment kits and third-party operator models further reduce risk and increase resilience.
Distinguish the frontend from the protocol. As the first article in this series established, the threshold question for regulation is whether an identifiable person controls the protocol. Frontend operators, by definition, do not. Maintaining this distinction through architecture, communication and governance is both legally sound and practically important.
What Comes Next
This article addressed the regulatory position of frontend operators. Future posts in this series will examine other activities commonly associated with DeFi protocols: smart contract development and deployment, governance participation, staking and validation, running oracles, and providing liquidity. Each activity raises distinct regulatory questions, independent of whether the underlying protocol has an “operator.”
Do you need clarity on your frontend’s regulatory position? LEXR offers structured assessments of DeFi activities based on the framework outlined in this series and can assist with drafting frontend disclaimers and terms and conditions. Contact us to discuss your project.
[1]This article is the second in a series on the regulation of DeFi. The first article, The Regulation of DeFi: A Global Framework for Assessing When Decentralised Protocols Fall Within Financial Regulations, is available at lexr.com/en-ch/blog/the-regulation-of-defi.
[2]Regulation (EU) 2023/1114 of the European Parliament and of the Council of 31 May 2023 on markets in crypto-assets (MiCA), Recital 22.
[3]MiCA, Articles 3(1)(16) to 3(1)(26), defining crypto-asset services.
[4]GENIUS Act (Pub. L. 119-27), Section 2(7)(B)(ii)-(iii), defining exclusions from the “digital asset service provider” definition.
[5]Digital Asset Market Clarity Act of 2025 (CLARITY Act), H.R. 3633, 119th Congress. Passed the House in July 2025; Senate negotiations ongoing as of March 2026. Section 601 (proposed Exchange Act § 15H) and Section 604 (Blockchain Regulatory Certainty Act) contain the relevant safe harbours.
[6]Congressional Review Act Joint Resolution, signed into law April 2025, repealing Treasury/IRS Rule T.D. 10021 (Dec. 2024). The CRA prohibits the agency from issuing a substantially similar rule.
[7]SEC, Closing of Investigation of Uniswap Labs, February 2025.
[8]Van Loon v. Department of the Treasury, No. 23-50669 (5th Cir. 2024). OFAC delisted the Tornado Cash smart contracts from the SDN list on 21 March 2025.
[9]Risley v. Universal Navigation Inc., No. 22-cv-2780 (S.D.N.Y. 2023) (district court dismissal); No. 23-1340 (2d Cir. 2025) (Second Circuit affirmance); No. 22-cv-2780, 2026 WL 572065 (S.D.N.Y. Mar. 2, 2026) (final dismissal with prejudice of remaining state law claims).
[10]United States v. Storm, No. 23-cr-430 (S.D.N.Y.). Jury convicted on one count (conspiracy to operate unlicensed money transmitting business) on 6 August 2025; mistrial declared on two remaining counts. Prosecutors requested a retrial for October 2026. Storm’s Rule 29 motion for acquittal is scheduled for argument on 9 April 2026.
[11]The Swiss Blockchain Federation (SBF) is a private industry association, not a public authority. Its circulars represent industry consensus and best practice guidance but are not legally binding regulatory pronouncements. To date, neither FINMA nor any other Swiss public authority has issued specific guidance on the regulatory treatment of DeFi frontend operators.
[12]Swiss Blockchain Federation, Circular on the Classification and Regulatory Treatment of Decentralized Finance (DeFi) under Swiss Financial Market Law (2025), Section 4.2, para. 7 (User interfaces).