CLARITY Act Check-In

The CLARITY Act has had a long road. The House passed a strong bipartisan bill last July and as we approach the finish line for the Senate version, the Senate Banking Committee's markup in May diverges from that foundation in some meaningful ways. We are closer to final legislation than we have ever been, and the next iterations, including the Agriculture Committee markup, are potentially the last real opportunity to shape what that looks like.

The bill is an omnibus market structure regulation effort in the sense that it focuses on regulating the tech stack in addition to being a token trading framework. This update will focus on Title I and Title III. The clean way to hold the two frameworks in your head: Title I regulates tokens; Title III regulates the technology stack. 

 Below is the full scope of the bill:

Because we are very late in the process - any remaining issues that we try to rehash must be material enough to warrant another pass. With this in mind, this update is focused on certain material problems concentrated in specific provisions, most of which require targeted drafting changes rather than structural rework. The goal of this effort is to push for improvements in these provisions to make any legislation as workable as possible.

On Title I, the framework is workable and the remaining problems are targeted drafting issues. Title III is the sleeper. It is described as the DeFi framework, but its scoping limiter: a distributed ledger system 'through which multiple participants can execute a financial transaction': turns on a term the bill never defines, and for a technology whose design pattern is native monetization, an undefined 'financial transaction' gate captures essentially the entire stack. Fail the purity test that follows and the consequences run through Exchange Act registration into Bank Secrecy Act treatment by operation of law. 

I. How the Bill Works

A. The Go-to-Market Framework (Title I)

Title I is, at its core, a go-to-market framework for token-issuing projects. It creates a structured path from initial offering through eventual exit from securities treatment. The Regulation Crypto exemption is the operational center of that path.

1. Reg Crypto Eligibility Requirements

Before anything else, a project must qualify to use Regulation Crypto. The eligibility requirements are summarized below, including material issues that are flagged for later discussion.

2. Token Issuer Lifecycle

For projects that clear eligibility, the bill creates a five-stage lifecycle from ancillary asset through certification and, if circumstances change, back again. The design mirrors the maturity test in the House b¡ill; how the Senate defines the exit is where the material issues sit. The stages and the regulatory status at each are below; exposure points are flagged for the deep-dive analysis.

The regulatory exposure at each stage is noted below.

3. Transition for Launched Token Issuers

The bill is not only for new launches. Tokens already trading at enactment are pulled in through a default presumption, but the framework is opt-in and comes with a meaningful carrot: a launched-token originator that certifies out can avoid the periodic disclosure regime entirely, and the retroactive disclosure exposure is capped at a defined look-back rather than running open-ended. The mechanics, with timing, are below.

B. The Tech Rails Registration Framework (Title III)

Title III is the sleeper issue in this bill. It has been described as the 'DeFi regulatory framework,' and that framing does a lot of work to keep people from paying attention. What Title III actually creates is a registration framework for crypto tech rails. Currently, Title III is scoped to securities and Bank Secrecy Act obligations. That will not hold: an equivalent provision under CFTC jurisdiction is a near-certain addition in the Agriculture Committee process, which means whatever baseline emerges from the Banking bill becomes the floor for a parallel framework on the commodity side.

The scoping with regard to the tech stack sits in the DFTP definition: a distributed ledger system 'through which multiple participants can execute a financial transaction.' Everything turns on those last three words: and 'financial transaction' is not defined anywhere in the bill.

This is worth sitting with. Tokens are, under existing FinCEN guidance, convertible virtual currency, and a transaction in a token is by definition a transfer of value. The technology that moves tokens between people is, almost by construction, technology that facilitates financial transactions, so Title III reaches it. Native monetization is the design pattern here: value transfer is not a feature some distributed ledger systems happen to have, it is how the technology coordinates participants at all. Read 'financial transaction' at face value and the gate captures essentially the entire stack: payments, DEXs, lending, bridges, NFT marketplaces, staking systems, DePIN service payments, gaming economies. How the gate should be narrowed is a material issue, taken up below.

The drafters understood the breadth of the tech being drawn into Title II - it is explicitly and intentionally far reaching. Sec. 302 layers onto 301 and creates separate illicit finance obligations for 'distributed ledger messaging systems': the software interfaces, front-ends, and notification layers that sit above the underlying protocol. A messaging system under Sec. 302 is a system that 'facilitates the transmission of messages between participants in a distributed ledger system,' which covers essentially every user-facing application regardless of whether the underlying protocol is a DFTP. So the scope is two-tiered: Sec. 301 reaches the tech infra layer, and Sec. 302 independently reaches the interface layer. Nothing falls outside. 

A team that builds a DFTP-qualifying protocol and deploys a front-end for it separately faces Sec. 302 Treasury obligations for the interface even where the underlying protocol is fully protected.

The mechanism the bill uses to screen for that risk, and whether it measures the right thing, is the central Title III material issue. See Title III Deep Dive, What the Test Measures, below.

The test screens for control: whether any party can alter the system, extract value preferentially, or restrict use. Whether a system qualifies for the Title VI developer protections in Sec. 15H is a separate question from whether it passes the Sec. 301 analysis. The adequacy of a binary, structural test as the screen is taken up in the deep dive.

Whatever the Agriculture Committee adds to either gets layered onto the Banking baseline: which is why scope vigilance and duplication risk run through the rest of this process.

1. The DFTP Qualification Test

To qualify as a DFTP under Sec. 301(a), a protocol must satisfy the two requirements and avoid all three exclusions set out below. Note that the DFTP definition in Sec. 301(a)(2) and the Title VI definition in Sec. 15H are separate frameworks with different coordination concepts. A protocol may qualify under Title VI while still failing the Sec. 301 test, and vice versa. The practical implications are summarized below.

II. Material Issue Analysis

A. Summary of Material Issues

What follows is a summary of the material issues that we are tracking coming out of the Banking Committee markup, organized by where they sit in the bill's structure. The Ag process will add obligations, not remove them: so the baseline we carry in will matter, together with any duplication risk created from Ag in the combined product is something to watch throughout.

B. Title I Deep Dive: Token Regulation

1. The U.S. Nexus Problem

Problem: The U.S. nexus rule is badly calibrated. The nexus rule renders ineligible projects that never leave the United States in any way that matters. Teams routinely structure through offshore foundations, protocol labs, co-issuers, and DAO entities for ordinary tax, operational, and liability reasons. Where the nexus test keys to the nominal issuer's domicile rather than to operational substance, a project with U.S.-based developers, U.S.-based management, and a U.S.-facing product can be treated as foreign on paper or, under the foreign originator exclusions, denied the foreign path and pulled into the domestic regime, with adverse tax consequences either way. The structuring has nothing to do with where the team works, where the product is built, or who the users are.

Furthermore, the strict U.S. domicile requirement in Sec. 103(c)(3)(A) creates a severe tax and operational dilemma for founders. Many U.S.-based developers and management teams use offshore equity-less foundations or offshore SPEs for a variety of operational, legal and tax reasons. Relevant to this analysis, it includes mitigating tax burdens associated with token generation events, sales and distributions. 

A U.S. nexus test in securities law is designed to ensure a U.S. operational nexus, not restrict or prevent tax structuring. This requirement, as drafted, serves no policy justification other than locking in punitive tax consequences. It is a disincentive to issue tokens over equity raises, which have preferential tax implications and a disincentive to use Reg. Crypto.

Compounding the Problem: Being ineligible for the US nexus rule creates a massive compliance trap for offshore projects. The nexus rule renders projects ineligible for the Regulation Crypto exemption if they are organized outside the U.S. Because SEC and CFTC guidance confirms that distributing a token is itself an investment contract transaction requiring an exemption, Regulation Crypto is effectively the only compliant on-ramp to the U.S. market. By tying eligibility to the nominal issuer's domicile rather than operational substance, foreign originators (and U.S.-operated projects utilizing offshore foundation structures) are formally shut out of the "front door" to the U.S. market.

Thus, the issue here is the absence of a clear, tailored market-access pathway for offshore-structured projects that want to come into compliance and access U.S. users. While the existing foreign-jurisdiction language gives the Commission authority to pull such originators into the disclosure regime; it does not by itself explain the conditions under which those projects can confidently launch, distribute, or transition into the U.S. market. That uncertainty can push legitimate projects to avoid the U.S. market, adopt artificial entity structures, or operate under continuing legal uncertainty rather than through a defined compliance path. 

So while foreign originators are blocked from using the Regulation Crypto safe harbor, the bill simultaneously creates a backdoor that drags them into the full U.S. disclosure regime involuntarily.

Under Sec. 4B(c)(1)(A)(ii)(I), the mandatory initial and periodic disclosure requirements are automatically triggered upon: "The first secondary market offer, sale, or distribution of an ancillary asset in the United States... that constitutes a public offering, whether by the ancillary asset originator or any other person".[7] The disclosure regime, by its terms, attaches to offers, sales, and distributions made in reliance on Regulation Crypto or an effective registration statement, and to U.S. resales.[8]

This compounds why the U.S. eligibility limits bite so hard, and recent guidance sharpens the point. In March 2026 the SEC, joined by the CFTC, issued an interpretation confirming that while most crypto assets are not themselves securities, the offer, sale, or distribution of a token is the regulated event, an investment contract transaction that a project cannot conduct without either registration or an exemption.[9] That is the same architecture the bill codifies through the ancillary asset definition. The practical consequence is that Regulation Crypto is not an optional convenience; a project can decline in favor of doing nothing; for any team that wants to distribute a token to U.S. persons, it is effectively the only compliant on-ramp for a broad distribution to U.S. users. Once the exemption is the gate to the U.S. market rather than a nicety, every eligibility limit on it becomes a limit on market access itself. The U.S. nexus requirement and the guidance that was meant to provide clarity therefore raises the stakes of getting the eligibility rules wrong, because it confirms there is no path around them.[10]

The Ultimate Trap (Disclosure Burdens without Section 5 Protection). This combination creates a severe "form-over-substance trap". A foreign originator can be involuntarily dragged into the U.S. regulatory regime and forced to file extensive initial and semiannual disclosures simply because an unaffiliated third party initiates a secondary market sale in the U.S..

Critically, even if the foreign originator fully complies and perfectly furnishes all mandated disclosures, they still do not qualify for Regulation Crypto because of their offshore domicile. Without the Regulation Crypto exemption, any primary distribution by the foreign originator into the U.S. remains an unregistered securities offering. Therefore, the foreign originator faces Section 5 liability for distributing their asset, despite being forced to shoulder the bill's heavy disclosure regime. They are subjected to the burdens of U.S. compliance without receiving the core legal protection of the framework.

3. Scope of Issuer Obligations

Problem Statement: A material-omission standard works poorly where facts are dispersed and emergent; without a knowledge or reasonable-inquiry limitation, omission liability becomes effectively strict as to system-level facts the team cannot observe.

The primary gap is in the disclosure section itself. The initial and semiannual disclosure obligations under Sec. 102 carry a catch-all completeness duty: the originator must furnish 'such further material information, if any, as may be necessary to ensure that the statements made in the disclosure are not, in light of the circumstances under which the statements are made, materially misleading': with no knowledge qualifier or reasonable-inquiry limitation, and with Securities Act Sections 12(a)(2) and 17 expressly preserved as the liability hooks for Reg Crypto offerings. As a system genuinely decentralizes, material facts distribute across validators, governance delegates, independent developers, and infrastructure providers the originator cannot observe, while the semiannual completeness obligation keeps running against the full set of those facts. The disclosure duty is sized for a system the issuer controls and persists into a phase where the issuer controls less and less.

The termination certification, by contrast, is made to knowledge: 'based on the knowledge of the certification covered party after due inquiry and supported by reasonable evidence.' That is worth noting, and it slightly mitigates the related-party attribution problem: the team certifies what it knows after due inquiry about 4% holders and other covered parties, not what is objectively true about them. But the mitigation only goes as far as the consequences respect the qualifier, and they do not. The Commission may deny or unwind upon determining that more than a nominal level of efforts 'has been undertaken by any certification covered party': an objective finding about parties the team may have no ability to monitor: and material misstatements or omissions in an effective certification remain grounds for revocation and enforcement. The team certifies to knowledge; the certification lives or dies on facts outside it.

Applying centralized disclosure logic to systems designed to become decentralized creates three problems:

• Fairness: certification requires demonstrating maturity, but maturity means knowing less and controlling less. The law punishes exactly the outcome it's designed to reward.

• Policy: teams may rationally delay genuine decentralization to preserve their ability to defend disclosure completeness: the opposite of what the certification framework is designed to incentivize.

• Administrability: without a knowledge qualifier or reasonable-inquiry limitation, omission liability risks becoming effectively strict as to system-level facts the team cannot observe or verify.

Problem: The related-party scope is too broad for certification; it creates liability and attribution for the actions of disparate parties, a team neither selected nor can account for or control.

The 'Related Person' definition in Sec. 2(13) is layered: it includes any founder who was also a beneficial owner of 4% or more of outstanding units within the prior 36 months; any executive officer, director, or 10%-plus equity owner within 12 months but it also covers any tokenholder holding 10% or more of units within 6 months; and any holder of 2% or more of covered tokens within 6 months. That definition then feeds directly into 'Certification Covered Party': the set of persons whose activities the originator must certify about.

The practical problem is that originators may have no operational visibility into a significant portion of this population (ie. where the nexus is solely holding tokens). Holding an originator responsible for certifying about parties it cannot contro and may not be able to monitor, and has no contractual relationship with is closer to strict liability than disclosure. It also pushes teams toward actively monitoring or restricting large tokenholders: the opposite of what the bill should reward.

4. The Control Test

Problem: the Control Test is poorly calibrated, resulting in a number of cascading issues, which ultimately lead to the utter lack of bright line legislative safe harbor for maturity (ie. the standard for certification and decertification).

Start with why this legislation exists at all. The industry came to Congress because token classification had been left to a facts-and-circumstances Howey analysis applied after the fact by the SEC and the courts, and that uncertainty was the core problem a market structure bill was supposed to solve. A workable bill replaces an open-ended, after-the-fact inquiry with a clear, self-assessable standard a project can plan around. The House version did that: a bright-line concentration test a team could measure itself against. Judge the Senate's control test against that purpose, because that is the bar it has to clear.

It fails on every front. First, the Senate moved off the House's bright line: the concentration test is now one factor among five in a Sec. 104(b) rulemaking, so the thing a project could once measure itself against is gone. Second, and worse, clearing that control analysis is no longer enough. The bill layers a separate and stricter standard on top: to certify out, a project must also show that entrepreneurial or managerial efforts are not more than nominal and not a primary driver of value, an inquiry that is itself facts-and-circumstances all the way down. So the design reintroduces exactly the open-ended, after-the-fact test that prompted the call for legislation, and it does so twice over, while adding a layer of mandatory rulemaking, certification, and ongoing exposure that did not exist before. The result is more uncertainty than the status quo, not less, wrapped in considerably more red tape. The sections below take the two failures in turn: the standard a project must meet to certify out, and the control factor at the center of the rulemaking.

Problem: If this concept stays in, at the very least, the standard should be 'material' rather than 'nominal,' and the control test should be unified with the disclosure-exit criteria so the network's economic independence, not a bare efforts finding, is what governs. 

This is the standard bolted on top of the control test, and it is the more consequential of the two. Going in, it is conjunctive. The certification covered party certifies, on knowledge after due inquiry and supported by reasonable evidence, that it engaged in not more than a nominal level of entrepreneurial or managerial efforts, and that any such efforts were not a primary factor in determining the value of the ancillary asset, which may include whether essential promises have been fulfilled. Every operative term there, the level of efforts, whether they drive value, whether promises are fulfilled, is a facts-and-circumstances judgment of precisely the kind legislation was supposed to retire. The parenthetical imports the SEC's own framework guidance, so the bill is, in effect, writing the Howey reliance inquiry back into the statute under a new name.

Coming out, that work disappears. The Commission may deny: including after submission: 'upon determining that more than a nominal level of entrepreneurial or managerial efforts has been undertaken by any certification covered party.' Full stop. No value-factor prong, no promises analysis, no reliance inquiry. The marketing and promises language appears in only one of the two analyses. The result is that a team can satisfy the certification standard: efforts not a primary value driver, essential promises fulfilled: and still be denied or unwound on a bare efforts finding. The decertification standard is stricter than the certification standard, and the omitted piece is exactly the part of the analysis that tracks Howey and the Commission's own guidance.

Problem: One of the root causes of the issues described above is poor calibration of the Control Test. The design of this test is one of the more disappointing elements of this bill. Instead of a bright line safe harbor, we are stuck with facts and circumstances the SEC determines, oriented to a particularly ridiculously 49% threshold for evaluating the distributed network component of the House control test (and even more unhinged to include as a governance power threshold).

The control test itself shows the same regression. The 49% figure is one of five considerations the Commission must weigh in the Sec. 104(b) common control rulemaking: open source status, permissionless and credibly neutral operation, the extent to which any person or group holds not less than 49 percent of outstanding units, autonomy, and economic independence. The underlying criteria are sound, and the economic independence factor in particular is what the industry asked for. But the House gave a project a bright line it could measure itself against, and the Senate converted that into a weigh-everything rulemaking with no line at all. A multi-factor balancing test is, by definition, facts-and-circumstances. So even the half of the framework that was supposed to be the clean, structural test has been turned back into the open-ended inquiry the bill was meant to replace, and the 49% anchor at its center is not a credible threshold for what is being measured.

Two reference points show how far off 49% is. The first is blockchain security: a 'not less than 49 percent' anchor reflects 51%-attack logic: the stake needed to rewrite transaction history: which is a network-integrity question, not a control question. The second is securities law itself. The factor now applies to governance tokens, where holdings map directly to voting control of the protocol, and against the SEC's own baseline 49% is an outlier: beneficial ownership of 5% triggers Section 13(d) reporting, 10% triggers Section 16 insider treatment and presumptive affiliate status, and control under Rule 405: 'the power to direct or cause the direction of the management and policies': is regularly found well below majority ownership. A statute that treats sub-49% governance concentration as presumptively consistent with decentralization provides a poorer standard around control share than the analysis the Commission already applies to equity. Layer on typical governance participation rates of 5-15%, delegation, validator concentration, and off-chain coordination, and the anchor is exactly backwards.

Problem: The goal was always non-exclusivity of any safe harbor as there is no one size fits all analysis that works. L2s and applications derive security from the base layer and need different control-test considerations; a mandated non-exclusive safe-harbor development should be built for those specific circumstances.

The coordinated control criteria were developed with base-layer L1 networks in mind. L2 and L3 systems inherit security and trust properties from lower layers, operate under different governance assumptions, and decentralize on different timelines than standalone chains. A single threshold-based control test applied uniformly across all layers of the stack does not distinguish between fundamentally different architectural realities: and penalizes legitimate scaling designs that are actually beneficial for users.

C. Title III Deep Dive: Tech Rails Registration

1. What the Test Measures

Problems: The three-prong test is too broad in its application, covering way more than decentralized finance and the exclusions are not scoped to intermediary risk; the Commission should adopt rules addressing specific intermediary risks rather than a wholesale application of existing broker-dealer rules, with a clear boundary that a non-DFTP is neither an exchange nor automatically a registrant.

First, it is worth being explicit about scope at this point. Title III as passed by the Banking Committee is limited to securities-related activities and BSA obligations. The Agriculture Committee is very likely to add a reciprocal provision under CFTC jurisdiction covering digital commodity transactions. The two frameworks will create a layered compliance landscape, and provisions that might look targeted in isolation (they don't though) would compound in combination. The analysis below addresses the Banking bill's Title III; the Agriculture risk is flagged in the Path Forward.

Scope. Section 301 is purportedly designed to cover systems that present risks analogous to those addressed through broker-dealer, exchange, and clearing agency regulation. It scopes in DeFi and L2s. A system with an exclusive sequencer, a conflicted operator, or discriminatory access creates real user harms that justify regulatory attention. That is a legitimate objective.

However, the bill’s undefined 'financial transaction' gateway also effectively sweeps in the entire tech stack because the burden of filtering out technology that lacks true intermediary-like risks falls entirely on Section 301.

Because the bill defines a Decentralized Finance Trading Protocol (DFTP) around the undefined term 'financial transaction,' it inherently captures any token transfer. We do not even need to rely on existing agency guidance to prove this sweeps in the crypto ecosystem: Section 307 of the bill explicitly amends the Bank Secrecy Act's definition of 'monetary instruments' to include 'digital assets.' Therefore, by the bill’s own statutory terms, any operation involving a token is inherently a transfer of a monetary instrument, meaning it automatically triggers the financial transaction gateway.

One way to more appropriately scope these provisions is to define 'financial transaction' in the DFTP definition. The definition must be scoped exclusively to:

“transactions involving the brokerage, dealing, trading, execution, clearing, or custody of securities [or digital commodities], where such functions are material to the ability of a person or group to exercise intermediary-like control or extract rents (such as through the charging of percentage-based transaction fees or success fees that are distinct from standard programmatic network fees).”

Test Applies the Wrong Filter. Even if scoped to appropriate “financial transactions”, the filter applied to determine non-DFTP status is wrong. The test should be the 2 prong test to determine non-DFTP status and the result would be the Exchange Act registration currently contemplated.

However, for tech that meets the 2-prong test, the exclusions are incredibly punitive. They amount to a strict liability test, on whether a system is 100% structurally pure, whether it checks the formal boxes for decentralization, rather than whether it actually presents intermediary-like risks to user transactions. That is the wrong question for the policy objective. The right one is whether the technology is designed to be ‘trustless’ (ie. dont be evil): whether a user can be harmed by someone performing a discretionary intermediary-like function they cannot avoid relying on. The risk that securities and intermediary regulation exists to address is the discretion of a party a user is forced to trust, and the mitigant in this technology is not decentralization for its own sake but trustlessness in the ways that actually matter to users. A system is trustless in that sense when anyone can join, verify what happened, and act without permission, and when no single actor holds critical secrets, occupies an indispensable position in the flow, or can produce outcomes others cannot check. A protocol can fail the bill's purity test while being trustless in every way a user would care about, and it can pass while still leaving users dependent on intermediaries they cannot replace.[11]

A useful proxy is the degree of genuine disintermediation: can a team or operator step between the user and the transaction to perform a discretionary, intermediary-like function that the user cannot bypass? If an open protocol allows anyone to permissionlessly join, verify what happened, and act without relying on a centralized intermediary, it inherently neutralizes the risks regulators care about. Framed this way, the regulatory question moves from 'is this structurally pure?' to 'does this technology successfully disintermediate the transaction so that users are never forced to trust a central operator?'. That is the same instinct underlying the control-based approach to decentralization that informed the House framework: the reason control matters is that retained points of control are where information asymmetries, conflicts of interest, and value extraction actually live. Title III should directly measure whether a protocol successfully eliminates those centralized chokepoints, rather than using a rigid structural purity test as a flawed stand-in for assessing actual intermediary risk.[12]

Interactions between the Aggregation Rules & Exclusions. The non-DFTP definition turns on whether "a person or group of persons... acting pursuant to an agreement to act in concert" has the authority to control or materially alter the protocol (Exclusion A) or whether a group under common control can unilaterally restrict its use (Exclusion C). However, the bill does not define what actually constitutes a group acting in concert. The aggregation rules, meaning how individual token holdings, governance votes, and coordinating relationships are combined to determine whether a group exists, are left entirely to Section 301 rulemaking.

This is significant because it invites the same types of hindsight reconstruction by regulators. A protocol with distributed governance could have a third-party in control or no single controlling party, but still fail Exclusion A if the Commission’s rulemaking aggregates governance participants based on the vague "agreement, arrangement, or understanding" formulation that runs throughout the bill. This formulation can easily sweep in conduct that reflects aligned interests rather than actual coordination: validators performing normal functions, governance participants voting on the same upgrade, or independent developers contributing to shared infrastructure. 

What’s more, the statutory exclusions do not dictate that the operator of the non-DFTP must be the same group that failed the control exclusion. If the SEC aggregates distributed tokenholders or validators into a "group acting in concert," the protocol automatically loses its DFTP status. Once it becomes a non-DFTP, the heavy regulatory obligations under Section 301, such as Exchange Act registration and Bank Secrecy Act compliance, fall on whoever is deemed to "control" the operation of that non-DFTP. As a result, an independent developer or a separate front-end operator could be subjected to full intermediary regulation simply because a third party triggered the non-DFTP classification. This is a nonsensical outcome. The regulatory burden should fall on the party triggering the compliance obligation.

Until these rules are published, a protocol cannot reliably assess whether it passes Exclusion A, nor can an operator know if they will be penalized for the aggregated actions of others.

2. Consequences of Failure

The difference between what Sec. 301 is designed to do and what it currently allows is significant. The table below maps the intended consequence structure against the risk created by Sec. 301(b)(3)(B)(ii) as currently drafted.

Consequences. The all-or-nothing consequence structure compounds the problem. The structure of the test makes this worse than it appears. The two prongs and the three exclusions are separate analyses. A protocol can satisfy both prongs where it executes transactions through a predetermined algorithm, non-custodially and still trip an exclusion through upgrade authority. Under the current drafting, that protocol is a non-DFTP subject to the same Sec. 301(b) rulemaking consequence as a protocol that fails the prongs entirely because it is functionally custodial. Those are not the same risk. A protocol that is automated and non-custodial but has a residual control point presents a bounded, identifiable risk the targeted rulemaking is supposed to address. Routing it into the same bucket as a full intermediary is the wrong policy outcome and the bill gives the Commission no instruction to treat them differently.

The registration regime 'without regard to technological form, distributed architecture, or purportedly decentralized characterization' direction in Sec. 301(c) has catastrophic consequences for projects that meet the 2 prongs but fail the exclusions. It instructs regulators to ignore the architectural facts that most directly determine who exercises control, what risks are actually present, and what compliance obligations are feasible. As we learned in the Gensler era, there is a meaningful difference between refusing to accept labels at face value and refusing to look at how systems work.

In modern risk-based financial regulation, obligations are calibrated to the nature and magnitude of the risk identified. Failing one exclusion prong of the structural purity test should not trigger the same consequence as failing the requirements themselves, let alone carry the consequence of operating a systemically important intermediary. This bill currently has no materiality threshold.

3. Section 302 Overlay. If you pass the DFTP test in 301, you are not out of the clear. Section 302 layers onto 301 to create separate illicit finance obligations for 'distributed ledger messaging systems.' While framed as a DeFi regulation, the statutory definition captures any 'web-hosted software application' interacting with a DFTP (see above discussion on wide scope) or 'distributed ledger application' (which the bill defines as any smart contract). The statute dictates that Treasury 'may' require these interfaces to purchase analytics screening measures and actively block transactions. This provides regulators an unconstrained blank check to apply bank-like compliance to independent web developers. 

The mechanism is in Sec. 301(b)(2)(D) and (b)(3): the Commission 'determines, through that rulemaking,' which controlling persons are 'required to register with, or comply as a registrant under, the Securities Exchange Act,' and BSA obligations follow by operation of law for anyone so determined. Two clarifications from the text. First, the consequence attaches to the person or group that controls the protocol, not the code: Sec. 301(d)(1) expressly bars requiring software to register in its own capacity or prohibiting the deployment of an application. Second, Sec. 301(d) frames the inquiry as activity-based: requirements apply 'only with respect to securities-related activities, based on the functions performed.' Those are real guardrails. But the core problem stands: the Exchange Act's definitions of broker, dealer, exchange, and clearing agency were developed over decades of regulatory and judicial interpretation, and whether a controlling person satisfies those definitions is a different question from whether the Commission, through Sec. 301 rulemaking, says they must register.

The concern is not hypothetical as the Commission's proposed Regulation ATS amendments generated significant pushback on exactly this theory: that the Commission was using rulemaking authority to expand Exchange Act registration beyond its statutory scope through expansive reinterpretation. Sec. 301(B)(ii) creates the same structural risk in a different context.

The Exchange Act determination is not the end of the consequence chain. Sec. 301(b)(2)(D) requires that the rules 'result in, by operation of law, the application and enforcement by the Department of the Treasury... of anti-money laundering and countering the financing of terrorism requirements under the Bank Secrecy Act' with respect to any person the Commission determines must register. Sec. 301(b)(3)(B) then directs the Treasury, in consultation with the Commission, to define BSA compliance for controlling persons of non-DFTPs: 'to the extent that registration or compliance... causes that person... to be treated as a financial institution under the Bank Secrecy Act pursuant to existing law.'

Read together: an SEC rulemaking determination about registration bootstraps Treasury AML/CFT jurisdiction by operation of law. A controlling person of a protocol that fails the DFTP test does not just face Exchange Act compliance: they become a 'financial institution' subject to KYC, suspicious activity reporting, and program obligations designed for banks and broker-dealers. Two guardrails exist: the existing-law limitation, and Sec. 301(d)(2)(A)'s instruction that nothing in the section expands or contracts Treasury's statutory BSA authority. But the trigger for all of it is the same rulemaking determination challenged above, which means the backdoor registration concern is also a backdoor financial-institution concern: and the Title III framing as mere 'DeFi rules' obscures that the BSA is riding along.

The bill contemplates that systems can evolve from more centralized toward DFTP-qualifying. Sec. 301 should function as a transitional compliance framework for systems in that process: not as a mechanism that makes the destination unreachable. The current drafting creates a structural inconsistency between the Sec. 301 and Sec. 601 frameworks (they use different coordination standards and aggregation concepts) and leaves open the possibility that Sec. 301 rulemaking could impose burdens permanently incompatible with Sec. 601 qualification.

Because of the sheer scope of the types of tech pulled into this test, this analysis and guidance should also be nuanced.

D. Global Issues

1. Coordination Language: A Watch Item for Both Titles

Throughout Sec. 301 and in the Sec. 2 definitions, the phrase 'agreement, arrangement, or understanding' is used to aggregate persons for purposes of coordination and control analysis. The anti-evasion logic is sound but the implementation risk, and potential for overinclusiveness, is real.

'Arrangement' and 'understanding' are not defined, and in the context of decentralized networks they naturally sweep in conduct that reflects aligned interests or roles rather than actual coordination: validators performing functions necessary to normal network operation, governance discussions in public forums, independent voting on the same side of an upgrade proposal, shared advocacy for ecosystem development. The mechanism for ex post regulatory reconstruction of ordinary participation as implicit coordination exists in the current text, and it creates uncertainty that extends well beyond any specific bad actor.

This is also relevant to the Title I definitions through the 'Related Person' and governance aggregation concepts. Both titles carry coordination language that, if read broadly, creates material attribution and aggregation risk.

2. Scope of Rulemaking Delegations

To put it plainly, the bill provides certainty about which agency will decide: not what the rules will be. An unusually large share of the substantive policy decisions are punted to rulemaking, mostly with no deadline attached. The definitions that make the framework actually operate are all deferred: 'entrepreneurial or managerial efforts' (which determines what counts as an ancillary asset at all), 'coordinated control' (the gateway to certification, delegated to SEC rulemaking under Sec. 104(b) with no completion date), the 'disqualifying financial rights' boundary between ancillary assets and network tokens, the Sec. 105 financial interest test, and the entire consequences framework for non-DFTPs under Sec. 301. Until those rulemakings are done, the framework exists on paper but not in practice.

There is still a terminology and implementation issue buried in the delegations, but it is narrower than a direct definitional mismatch. Sec. 2(4) defines “coordinated control” by reference to rules the Commission must adopt under Sec. 104(b), and Sec. 104(b) in fact uses that same term. The complication is that the coordinated-control rulemaking is built around indicia that repeatedly turn on whether a “person or group of persons under common control” has certain rights, ownership, or authority. That aggregation concept also appears elsewhere in the bill, including the decentralized-governance provisions, the related-person / distributed-ledger-control-person framework, and Sec. 301. As a result, the SEC’s eventual coordinated-control rule will likely depend in part on how it interprets “under common control” and related coordination concepts across multiple provisions. The statute is therefore aligned on the label “coordinated control,” but some of the operative concepts doing the work underneath it remain open until the rulemaking lands.

In terms of having a timeline until we get more certainty, Dodd-Frank is the cautionary tale here. Davis Polk tracked 390 required rulemakings under that bill. At the seven-year mark, when they stopped counting, roughly 72% had been finalized and one in five had never even been proposed. The closest analog to where CLARITY sits: Title VII's swaps regime, which needed definitional rulemaking before the framework could function at all: took over a decade to become fully operational; the SEC's security-based swap registration did not go live until 2021. And Section 956's incentive compensation rules had a nine-month statutory deadline and remain unfinished fifteen years later.

The realistic read is that on the material issues identified throughout this update: what coordinated control means, what the certification standard requires, what happens to non-DFTPs: legal certainty could easily take five-plus years from enactment. That may even be optimistic. Dodd-Frank at least had statutory deadlines for most of its rulemakings; agencies missed them at a 60%-plus clip, but the deadlines created pressure points for oversight. CLARITY mostly has none. Layer on post-Loper Bright litigation exposure for any agency rule built on thin statutory guidance, and the timeline stretches further.

III. Path Forward

The Senate effort is workable, and given where we are in the legislative calendar, getting a durable framework enacted (and making it as good as possible) is the right objective. The Agriculture markup is the next real window. That process will add provisions: likely additional intermediary obligations and CFTC-focused market structure rules: and any excess or duplication from the Banking bill becomes the floor for the combined product. The items below are the ones worth pressing.

Before the Agriculture markup

• Conform the decertification standard to the certification standard. The bill's multi-part test: efforts plus value reliance, including the promises-fulfilled analysis that imports SEC guidance: should govern both directions. A bare efforts finding should not unwind a certification granted on the full standard.

• Limit 'Related Person' certification duties to known or affiliated parties. Add a knowledge qualifier to Sec. 2(13) obligations and the Sec. 102 disclosure completeness obligation: the certification already has one; the disclosure section, where the ongoing exposure actually sits, does not. Align decertification consequences with the certification's knowledge qualifier so teams are not punished for facts about ‘related persons’ they could not control. They should be responsible for parties under common control and the latter standard should be information reasonably available.

• Fix the U.S. Nexus Trap and create a foreign originator pathway. Anchor the Reg Crypto nexus test to operational substance rather than the nominal issuer’s legal domicile to avoid penalizing standard offshore structuring. Furthermore, if foreign originators are going to be involuntarily subjected to U.S. disclosure obligations due to secondary U.S. market trading under Sec. 4B(c)(1)(A)(ii)(I), they must be provided a structured pathway to receive the corresponding Section 5 safe harbor protections.

• Address the coordinated control ripple: re-anchor the Sec. 104(b)(2)(C) concentration factor to securities-law control-share analysis, pair the facts-and-circumstances factors with mandated bright-line safe harbors, and conform the structure so clearing the control test maps to certification rather than serving as a necessary-but-not-sufficient gate.

• Mandate, not permit, architecture-specific safe harbors in Sec. 104(b)(3) for L2s, L3s, and modular systems. A control test designed around L1 economics requires statutory safe harbors for the models it does not fit.

• Supplement references to 'agreement, arrangement, or understanding' with ‘to jointly exercise control' in both Sec. 301 and the Sec. 2 definitions. Watch for this language throughout the Agriculture process.

• Define 'financial transaction' in the DFTP definition, or scope it to transactions that would trigger intermediary regulation if performed by a centralized actor. As drafted, the only limiter on Title III's scope is an undefined term that captures value transfer generally: which, for this technology, is the entire stack.

• Mandate a graduated consequence structure in Sec. 301(b). The non-DFTP category currently contains two meaningfully distinct populations: protocols that fail one or both prongs (functionally custodial or discretionary, presenting genuine intermediary-like risk) and protocols that satisfy both prongs but trip an exclusion (automated and non-custodial but with a residual control point such as upgrade authority or a pause function). The statute routes both into the same rulemaking with no instruction to distinguish between them. The right outcome is narrow, risk-calibrated obligations for the second population and broader intermediary-style obligations for the first. Congress should require that result rather than leave it to agency discretion.

• Clarify that Sec. 301(b)(2)(D) supports risk-calibrated rules for controlling persons but that Exchange Act registration requires independent satisfaction of the statutory definitions. Build on the guardrails already in Sec. 301(d).

• Conform that Sec. 301 rules may not block the path to DFTP status.

• Set statutory deadlines for rulemakings and establish interim safe harbors. The bill delegates core functional definitions (like 'coordinated control' and the 'efforts' standard) to SEC rulemaking with no deadlines. Congress must set strict deadlines for these rulemakings, resolve the 'efforts' standard directly in statute, and mandate interim safe harbors effective at enactment so projects have a basis to operate while rules are pending.

• Close the BSA/AML Backdoor in Section 301. Explicitly clarify that failing the Sec. 301 structural purity test cannot be used via rulemaking to automatically bootstrap a controlling group into 'financial institution' status under the Bank Secrecy Act by operation of law, thereby preserving the developer protections intended in Title VI.

Workable legislation that gets the fundamentals right is worth having and these fixes are achievable. The window to make them is still open but barely.