The (Non)Decentralized Trading Protocol

June 12, 2026

Every lawyer working in this space since 2021 has been asked the same question at least once: where exactly is the line? The SEC’s view, articulated through the Wells notice to Uniswap Labs in April 2024 and the SEC v. Coinbase exchange-registration theory, was that the line might not exist as a useful concept at all. Anything that matched a buyer to a seller in a digital asset was potentially an unregistered exchange, broker, or clearing agency, and the question of whether the matching was done by code or by a human dealer was a detail rather than a distinction. The other view, quietly endorsed by the CFTC’s Ooki DAO consent order to the extent it implicitly conceded the inverse case, was that a protocol that executes solely under pre-encoded rules without an intermediating person is not the kind of thing the Exchange Act was drafted to capture.

§301 of the engrossed Senate substitute draws the line. It does so without using the word “DeFi” as a regulatory category and without granting blanket immunity to anything that wears the name. The drafting move is structurally similar to the §4B move covered in Post #2 of this series. Howey survives as a routing test rather than a substantive trigger; the Exchange Act survives as a regime for “non-decentralized finance trading protocols” that meet a three-prong test, with an explicit list of activities that do not, by themselves, push a protocol into that bucket. The third prong of the test, and the activity carve-out list, are where the practitioner work lives. Everything else is plumbing.

The Three-prong Test

§301(a)(1) starts with a definition wide enough to include almost every venue practitioners think of as DeFi. A “decentralized finance trading protocol” is a distributed ledger system through which multiple participants can execute a financial transaction in accordance with an automated rule or algorithm that is predetermined and non-discretionary, and without reliance on a person other than the user to maintain custody or control of any digital assets subject to the financial transaction. Two structural elements. The execution is rule-bound rather than discretionary. The custody runs through user-controlled wallets rather than through an intermediary’s omnibus account. Uniswap’s automated market maker satisfies both. Curve, Balancer, Aerodrome, GMX’s perpetuals engine, dYdX v4, and the Cosmos chain on which dYdX v4 lives all satisfy both. So does a much wider universe of orderbook DEXs, RFQ systems, and intent-based settlement protocols, provided that custody never passes to a third party at any step in the execution path.

That baseline definition is then put into productive tension with §301(a)(2), which defines “non-decentralized finance trading protocol” as a DeFi trading protocol that meets one or more of three conditions. The protocol is non-DeFi if a common-control person or in-concert group has the authority, directly or indirectly, through any contract, arrangement, understanding, relationship, or otherwise, to control or materially alter the functionality, operation, or rules of consensus or agreement of the protocol. §301(a)(2)(A)(i). Or if the protocol does not operate, execute, and enforce its operations and transactions based solely on pre-established, transparent rules encoded directly within the source code of the distributed ledger system. §301(a)(2)(A)(ii). Or if a common-control group has the authority, via operation of the protocol, to restrict, censor, or prohibit use of the protocol, including any applicable system-based user activity. §301(a)(2)(A)(iii).

The disjunctive “or” is doing the work. Any one of the three is enough to flip the protocol out of the safe DeFi bucket and into the bucket that triggers SEC Exchange Act registration plus Bank Secrecy Act obligations, to the extent the Commission’s §301(b) rulemaking determines that applicable requirements are triggered. Practitioners need to walk each prong carefully against the actual operational facts of any protocol they advise.

• Prong (i) is the control-in-fact test. It is intentionally broad. “Any contract, arrangement, understanding, relationship, or otherwise” tracks the §3(a)(9) common-control language in the Exchange Act and the analogous attribution rules under 17 C.F.R. § 240.13d-3. A protocol whose smart contracts can be upgraded by an admin key held by a labs entity is captured. A protocol whose parameters can be changed unilaterally by a multisig outside of any governance vote is captured. The harder cases involve hybrid governance: a DAO that votes, but where the labs entity holds the timelock and has historically pushed through proposals the team favored. The drafting question is whether the team has authority “directly or indirectly” through the chain of custody from proposal to execution. If the answer is yes on any link, the protocol is non-DeFi under (i). The §301(f)(1) special rule on decentralized governance systems, which I will come to, takes the DGS itself out of the common-control calculus, but does not save a protocol whose governance is nominally DAO-run but operationally team-controlled.
• Prong (ii) is the source-code test. The protocol must operate, execute, and enforce solely on pre-established, transparent rules encoded directly in source code. The word “solely” is operative. A protocol with a single off-chain RFQ component that intermediates pricing fails (ii). A protocol with an off-chain solver network where solvers are themselves running open-source clients on user-controlled signing keys probably does not, although the line gets fuzzy when solvers are paid through a permissioned auction system run by the labs entity. The Across, CowSwap, and UniswapX solver designs each raise this question in slightly different forms. Counsel structuring intent-based protocols should be designing the solver auction to live on-chain or to operate under open-access rules; closed solver sets controlled by the protocol team risk failing (ii).
• Prong (iii) is the censorship test. It asks whether a common-control group has authority, via operation of the protocol, to restrict, censor, or prohibit use, including any applicable system-based user activity. The “via operation of the protocol” qualifier is important. Front-end interfaces that filter OFAC-sanctioned addresses do not, on a straight reading, satisfy (iii) because they do not operate via the protocol; they operate via a separate web application that points at the protocol. The protocol itself remains permissionless. Van Buren v. United States, 593 U.S. 374 (2021), is not directly analogous, but the structural distinction between an access control imposed at the application layer and one imposed at the protocol layer maps onto the same fact pattern. The harder version of (iii) is the hard-coded blocklist. A protocol whose smart contracts check a sanctions oracle and revert transactions from sanctioned addresses operates censorship “via operation of the protocol.” If the censorship authority sits with a common-control group, even a group that updates the oracle infrequently and only in response to law-enforcement requests, (iii) is satisfied. The Tornado Cash OFAC designation arc (the August 8, 2022 SDN listing of smart-contract addresses, the Coin Center and Van Loon v. Department of the Treasury litigation culminating in 122 F.4th 549 (5th Cir. 2024), and the March 2025 OFAC withdrawal) is the policy backdrop. CLARITY’s drafters were aware of it. The bill draws the line so that protocols whose contracts are immutable and whose censorship, if any, occurs at the front-end layer remain DeFi.

§301(a)(2)(B) inserts the DGS rule. A decentralized governance system, solely by virtue of its operation, is not a person or group of persons under common control or acting in concert. This carve-out flows from §2(5) and Post #5 of this series. The DGS itself does not satisfy any of the three prongs simply by existing. A protocol controlled by a properly-constituted DGS is, on the face of the statute, a DeFi trading protocol, not a non-DeFi one. The harder question is whether the DGS itself satisfies §2(5), and that is where the centralized-management exclusion does work.

The Activity Carve-Outs

§301(a)(2)(C) is the practitioner-actionable core of the section. It excludes a list of activities from the definition of “non-decentralized finance trading protocol,” whether engaged in singly or in combination, in relation to the operation of a distributed ledger system or any component of one. The list runs to three clauses but covers the bulk of the infrastructure stack on which any modern protocol depends.

Clause (i) covers compiling network transactions, relaying, searching, sequencing, validating, or acting in a similar capacity. That language is comprehensive. It immunizes block builders (Flashbots and its competitors), relays (mev-boost), MEV searchers, validators (Ethereum, Solana, and every L1 validator economy), and sequencers (the centralized sequencer Arbitrum and Optimism currently run, and the decentralized sequencer designs both networks are moving toward). The “similar capacity” residual is meant to catch the next generation of mempool and ordering services that have not been invented yet. A practitioner advising a sequencer-operator client whose sequencer is centralized today but is the only consensus mechanism for an L2 rollup gets the answer from (i): the sequencer activity, in itself, does not push the rollup or its component into non-DeFi status. That is a meaningful change from how some of the more aggressive Exchange Act enforcement theories would have treated the same facts.

Clause (ii) covers providing computational work, operating a node or oracle service, or procuring, offering, or utilizing network bandwidth, or providing other similar incidental services. Oracle providers (Chainlink, Pyth, RedStone, Switchboard) get an explicit safe harbor. Node operators, RPC providers (Alchemy, Infura, QuickNode), and bandwidth providers do too. The “computational work” clause covers proof-of-work miners, ZK provers, and the emerging class of agent-as-a-service operators who run inference compute against on-chain prompts and pay-per-call markets. Anything that looks like infrastructure underneath the protocol is on the safe side of the line.

Clause (iii) is the incident-response and security-council carve-out, cross-referenced to §301(f). Practitioners coming from §104 will recognize the language; the §301 carve-out tracks the §104(b)(3)(C) cybersecurity emergency-measures safe harbor with parallel mechanics. The council must operate pursuant to pre-defined, temporary, rules-based authority, in response to a specific and documented cybersecurity incident or imminent threat, under publicly disclosed, on-chain authorization mechanisms, strictly limited in scope and duration to the incident, and without unilateral control by any single person. The procedural mechanism must be disclosed in publicly available written documentation reasonably available to the applicable Federal regulator sufficiently in advance of any exercise. §301(f)(2)(A). And the emergency authority cannot be used to push through protocol upgrades, governance decisions, or economic changes unrelated to the cybersecurity incident. §301(f)(2)(B).

The relationship between (i), (ii), and (iii) deserves attention. The three clauses are listed disjunctively (“whether singly or in combination”), which means an entity engaged in multiple safe-harbored activities does not lose the carve-out by virtue of doing more than one. A validator that also operates an oracle and serves on a security council remains within the safe harbor for all three activities. The “in relation to the operation of a distributed ledger system” qualifier is, however, important. It means the carve-outs apply only to activity directed at the operation of the DLS or its components, not to ancillary financial services unrelated to DLS operation. A node operator that also runs a custodial exchange does not get the (i) carve-out for its custodial-exchange activity. The carve-outs are activity-based and apply activity by activity.

§301(b)(2)(B) and the First Amendment hook

§301(b)(2) sets out the substantive requirements for the SEC’s rulemaking under §301(b)(1). Three of the four are unsurprising. (A) requires consistency with the public-interest, investor-protection, and orderly-market purposes of the securities laws. (C) requires legal clarity for development, publication, and operation of distributed ledger systems and their components. (D) directs Treasury enforcement of AML/CFT obligations to the extent applicable under existing law, which is to say that the Commission’s §301 rulemaking is the vehicle through which Bank Secrecy Act obligations attach to non-DeFi trading protocols once the SEC identifies them.

(B) is the constitutional hook. The rules must protect the rights of software developers, publishers, and users to create, publish, and use code and software in a manner consistent with the First Amendment to the Constitution of the United States. That language is not a vague injunction. It is a specific directive that the Commission’s rulemaking comply with the constitutional doctrine articulated in Bernstein v. United States Department of Justice, 176 F.3d 1132 (9th Cir. 1999), and Junger v. Daley, 209 F.3d 481 (6th Cir. 2000): source code is expressive speech, and prepublication restraints on its publication are subject to strict scrutiny. Post #7 of this series picks up the §601, §604, and §605 package that operationalizes the same First Amendment commitment for non-controlling developers, the Bank Secrecy Act money-transmitter definition, and self-custody, respectively. For §301 purposes, what matters is that the Commission’s eventual rule cannot directly or indirectly require registration of source code, distributed ledger systems as such, or non-controlling developers and publishers. §301(d)(1) reinforces the prohibition: nothing in the section, or in any rule adopted under it, can be construed to require a distributed ledger system or any software code to register with the Commission in its own capacity, or to prohibit the launch, deployment, or operation of a DLS. §301(d)(2)(B) reinforces it again with a cross-reference to the §604(b)(3) non-controlling-developer definition. The Commission has no authority over non-controlling developers and providers under §301, and any rule that purported to reach them would be vulnerable on both statutory and constitutional grounds.

The intra-bill cross-reference matters. §604(b)(3) defines a “non-controlling developer or provider” as one without “the legal right or the unilateral and independent ability to control, initiate upon demand, or effectuate transactions involving digital assets to which users are entitled.” The phrase tracks the structural functional-control test that the Fifth Circuit applied in Van Loon to conclude that Tornado Cash’s immutable smart contracts were not “property” subject to OFAC blocking authority. CLARITY codifies the Van Loon analytical move and routes it through the §301 rulemaking process, ensuring that the line between protocol operator (controllable, regulable) and protocol publisher (not controllable, not regulable) becomes a structural constraint on agency action rather than a constitutional question litigated post hoc.

§301(c), Activity-based Application, and the Death of Form-Over-Substance

§301(c) is short but doctrinally important. Rules adopted under §301(b)(1) must determine the applicable requirements only with respect to securities-related activities, based on the functions performed by the controlling person or group of persons, including brokerage, dealing, trading, execution, clearing, or custody of securities, without regard to technological form, distributed architecture, or purportedly decentralized characterization.

That second clause is the kicker. The activity-based test runs in both directions. A protocol whose operators perform brokerage, dealing, or custody functions cannot escape registration by labeling itself decentralized. The “purportedly decentralized characterization” phrase is a direct response to the “we are just software” defense that was floated, with mixed results, in cases like SEC v. Coinbase and the Uniswap Wells correspondence. Distributed architecture, on its own, is not a defense to control-in-fact. But the inverse is also true: a protocol whose operations consist solely of the §301(a)(2)(C) carve-out activities is not pulled into the regime simply because some of its participants perform broker-like functions. Activity is the test. The technological wrapper is not.

§301(c) operates as a doctrinal check on both the agency and the regulated parties. The SEC cannot push a “decentralized” label as a sufficient defense. It also cannot use “centralized in some respect” as a sufficient trigger. The functions actually performed by the controlling persons or groups have to be securities-related under the existing statutory tests in §3(a)(4), §3(a)(5), and §3(a)(11) of the Exchange Act. If they are, the activity-based application of existing requirements follows. If they are not, the §301 regime does not reach the conduct.

This produces a workable line for the most common edge cases. A protocol team that runs a centralized RPC service for user convenience but does not direct or settle transactions is engaged in (ii) activity, not securities-related activity. A protocol team that operates a closed solver network with discretionary order routing engages in conduct that looks like brokerage in fact, and the activity-based application brings it under the regime, regardless of how the surrounding protocol is structured. A foundation that runs a treasury and a grants program but does not maintain custody of user assets or execute user-facing trades is not engaged in covered activity, and §301 does not reach it.

Comparing the FinCEN and FATF Lines

The §301 test is not the only line that matters for DeFi practitioners. FinCEN’s 2019 guidance, FIN-2019-G001, Application of FinCEN’s Regulations to Certain Business Models Involving Convertible Virtual Currencies (May 9, 2019), draws its own line for money-transmitter status, asking whether the operator has independent control over user funds. FATF Recommendation 15 and its 2019 and 2021 guidance on virtual asset service providers (VASPs) draw an internationally harmonized line that captures any “natural or legal person… that conducts one or more of the following activities or operations for or on behalf of another natural or legal person,” including transfer of virtual assets, exchange between virtual assets and fiat, and safekeeping.

§301 and FinCEN’s 2019 guidance run on parallel tracks. Both ask whether the protocol operator has functional control over user assets. The §301(a)(1) custody prong (no reliance on a person other than the user to maintain custody or control) is structurally similar to FinCEN’s “independent control” test in FIN-2019-G001. A protocol that satisfies §301(a)(1) baseline ordinarily satisfies the FinCEN safe side as well. The §301(a)(2)(A) non-DeFi triggers, however, are more granular than the FinCEN guidance, and the §301(b)(3)(B) BSA-rulemaking direction explicitly authorizes Treasury to draw additional lines through tailored rules. Practitioners should expect FinCEN guidance to be updated post-enactment to track the §301 framework.

The FATF VASP definition is broader than either §301 or FinCEN, and is the source of much of the international compliance friction. FATF’s 2021 updated guidance suggested that DeFi protocol developers could be VASPs if they exercised “control or sufficient influence.” CLARITY’s drafters were aware of the friction; §507 of the bill, on international coordination, directs Treasury to engage with FATF and other multilateral bodies on harmonization. But the U.S. domestic line is now §301. The activity-based application of the existing FinCEN money-transmitter definition will track §301 outcomes, not FATF’s broader VASP concept. That is a meaningful divergence and will produce some cross-border friction for U.S.-domiciled DeFi developers operating in FATF-compliant jurisdictions abroad.

Structuring Choices that Preserve Decentralized Status

The §301 framework rewards structural commitment over branding. A protocol that satisfies §301(a)(1) at the architectural layer and avoids all three non-DeFi triggers under §301(a)(2)(A) stays in the safe bucket.

• First, ship immutable contracts where possible, and where upgradeability is required, route upgrade authority through a properly-constituted DGS with public, on-chain governance, not through an admin key held by a labs entity. The §301(a)(2)(A)(i) common-control prong does not bite if the only authority to alter the protocol runs through a DGS that satisfies §2(5).
• Second, do not embed censorship logic in the protocol layer. Front-end OFAC screening does not implicate §301(a)(2)(A)(iii). Smart-contract sanctions-oracle checks controlled by a common-control group do. The structural choice is to keep censorship at the application layer, where it is run by the operator of the front-end and not by the protocol itself.
• Third, on solver networks, intent-based protocols, and RFQ systems, the §301(a)(2)(A)(ii) source-code test requires that the off-chain components operate under transparent rules. Closed, discretionary solver sets are a problem. Open-access solver networks running standardized client software, with auction mechanics that are themselves transparent, are not.
• Fourth, document the structure. The §301(b)(1) rulemaking will, like the §104(d) and §4B(b)(5) certification regimes elsewhere in the bill, run on disclosure and documentation. A protocol whose governance, upgrade authority, custody architecture, and emergency-response procedures are publicly disclosed in on-chain documentation, governance forum posts, and project README files is in a substantially better position than one whose structure must be reverse-engineered from contract bytecode.
• Fifth, anticipate the activity-based test in §301(c). A controlling person whose activities are limited to publishing software, operating infrastructure within the §301(a)(2)(C) carve-outs, and participating in governance is not engaged in securities-related activity. A controlling person who routes user orders, takes custody, or sets prices in a discretionary capacity is. The structural choice is to keep the labs entity, the foundation, and the development team out of the trade execution path entirely.

The takeaway is that §301 produces a workable, structurally coherent line that was not available under any prior agency interpretation. The line tracks the underlying economic reality of who controls the protocol and what activities they perform, rather than reading from the surface presentation of “decentralized” branding or, conversely, the agency-level intuition that anything involving software must be a sophisticated form of intermediation. SEC v. Coinbase on the exchange-registration theory cannot survive in its prior form after §301. The Uniswap Wells correspondence is moot. The harder question is what happens to the protocols whose actual operational structure puts them on the wrong side of the line, and the answer is straightforward. They register, or they restructure. The bill is candid about which protocols are which.

Written by David Lopez Kurtz