Revised CLARITY Act Would Set Rules for Controlled DeFi Protocols

A revised version of the CLARITY Act would direct the Securities and Exchange Commission and Commodity Futures Trading Commission to develop activity-based rules for people or coordinated groups that control certain decentralized-finance trading protocols. The proposal uses the term "non-decentralized finance trading protocol" for protocols where a person or coordinated group has a material ability to alter functionality, operation, or rules; restrict users; or affect transactions that are not governed solely by transparent, pre-established code. The revised text is available in the bill PDF posted on Senator Cynthia Lummis' website.

The language narrows attention to control over an activity rather than treating software or a distributed ledger system as the regulated actor. Under the proposal, the SEC and CFTC would have to address registration, conduct, disclosure, recordkeeping, and supervision through rules tied to the activities of people or groups that meet the bill's test. Treasury would separately address how existing Bank Secrecy Act obligations apply to those controllers.

The revision arrives before a procedural Senate vote reported for Sept. 15. Cointelegraph reported that the procedural vote requires 60 votes. The bill text describes a proposed framework; it does not itself establish that the rules have been written, that a protocol has been classified under the definition, or that any particular person is subject to a registration or Bank Secrecy Act requirement.

Control is the threshold in the revised text

The definition starts with what a person or coordinated group can do. A protocol falls within the described category if its functionality, operation, or rules can be materially altered by a person or coordinated group. The text also reaches a protocol when those actors have the material ability to restrict a user from accessing the protocol, or when transactions are not governed solely by transparent and pre-established code. Those are alternative parts of the definition, not a checklist that must all be present at once, according to the revised bill text.

That drafting places practical authority at the center of the inquiry. Calling an application a protocol, publishing code, or recording activity on a distributed ledger does not answer whether someone retains the specified ability to change rules, alter operations, exclude a user, or determine how a transaction is handled. Conversely, the language does not say that every participant in a protocol is a controller. It identifies material ability held by a person or coordinated group as the relevant condition.

The word "material" limits the provision to authority that matters to the protocol's functionality, operation, rules, access, or transaction governance. The bill does not turn every technical contribution, service relationship, or community role into control by name alone. Its test is framed around the ability described in the definition. How regulators would apply that standard to particular arrangements would depend on the rules the agencies would be directed to develop.

The reference to a coordinated group is also consequential to the text's structure. A protocol need not have one plainly identified operator for the proposed definition to apply. The question can concern authority exercised by people acting together. The bill does not, in the cited provisions, supply a public list of protocols or people that satisfy the definition. It instead establishes the category to which the agencies' future activity-based rules would be directed.

The code condition supplies the other side of the distinction. Transactions governed solely by transparent, pre-established code are treated differently from transactions that are not. The proposal does not say that code must be immutable in every respect, nor does it reduce the question to whether source code is visible. It states a condition involving transactions and whether they are governed solely by transparent, pre-established code. That wording leaves the regulatory task centered on the facts of functionality and transaction governance rather than on a label attached to a project.

Agencies would write activity-based requirements

For controllers of a non-decentralized finance trading protocol, the revised bill would direct the SEC and CFTC to prescribe rules based on activities. The areas named in the proposal are registration, conduct, disclosure, recordkeeping, and supervision. The text therefore identifies subjects for rulemaking without setting out a finished rulebook for every type of protocol or controller.

Registration is one of the named areas, but the proposal does not say that software itself must register. Its carveout states that a software developer, a person engaged in the provision of a distributed ledger system, or the distributed ledger system itself shall not be required to register in its own capacity. The language separates the existence or provision of software and ledger infrastructure from an inquiry into whether a person or coordinated group has the material authority described elsewhere in the definition.

That qualification is specific. It says that the listed software and distributed-ledger actors or systems do not register "in their own capacity." It does not erase the bill's separate provisions about people or coordinated groups that control covered protocol activity. A developer or infrastructure provider's legal status under a future regime cannot be determined from the carveout alone, because the proposed rulemaking is directed at conduct and control as defined in the bill. The operative text is in the official PDF, rather than in a regulator's final rule.

The same division appears in the bill's structure: a technical system is not presented as the entity that completes a registration filing, makes a disclosure, keeps records, or carries out supervision. Those functions, where the rulemaking applies, concern people or coordinated groups undertaking regulated activity. This is not a finding that a particular application is decentralized or non-decentralized. The bill would establish the standard under which the agencies would write rules addressing those questions.

The proposal assigns work to two market regulators. The SEC and CFTC are directed to formulate activity-based requirements in the listed areas, but the revised text does not report a completed joint classification process for existing DeFi protocols. It also does not identify an effective rule, a registration form, a disclosure document, or a supervisory program that affected parties could use today. Each of those would be a product of the contemplated rulemaking process.

The activity-based formulation matters because the provision does not rest solely on the name of a technology. A system may use software, smart contracts, and a distributed ledger while a person or group retains authority that meets the proposed definition. At the same time, a person's participation in a technical ecosystem does not by itself establish the material ability specified in the statute. The bill's wording requires a connection to the actual powers it identifies.

Treasury's Bank Secrecy Act assignment

The revised proposal would also direct the Treasury Department to establish how existing Bank Secrecy Act obligations apply to controllers of non-decentralized finance trading protocols. That is an assignment concerning existing statutory obligations and their application to the controller category in the bill. It is not a statement that every DeFi protocol, every user, or every software developer is already subject to the same obligation.

The Bank Secrecy Act reference places anti-money-laundering compliance in a separate part of the framework from the SEC and CFTC's activity-based rules. The bill gives Treasury the task of determining applicability, while it directs the market regulators to address the named registration, conduct, disclosure, recordkeeping, and supervision subjects. The split of responsibilities is described in both the revised text and Cointelegraph's report on the revision.

The bill does not use this provision to announce a new Treasury rule in force on the publication date. It proposes that Treasury establish how existing Bank Secrecy Act requirements apply to the defined controllers. That distinction is material for readers assessing immediate obligations: the language describes what the department would be directed to do if the proposal became law, not a completed determination under a final rule.

Nor does the provision turn the term "controller" into a free-standing title divorced from the definition. The Treasury assignment follows the bill's approach to non-decentralized finance trading protocols, which turns on material authority over functionality, operation, rules, access, or transactions not solely governed by transparent, pre-established code. The question posed by the proposal is thus about persons or groups with the stated kind of control, rather than about an abstract category called DeFi.

A security role alone would not establish control

The revised language includes an express limit for incident-response and security work. Participation in an incident-response or security council, by itself, would not establish that a person or coordinated group controls a non-decentralized finance trading protocol. The bill PDF makes that point alongside the broader definition of control.

The qualification does not say that a security participant can never have control. It says participation in such a council alone is insufficient. A person's other authority could still be relevant under the material-ability test, but the council role cannot be treated as conclusive on its own. The provision draws a line between being involved in incident response or security coordination and possessing the operational powers that the definition describes.

That line is particularly relevant to protocols that organize technical responses to vulnerabilities or other incidents. The bill does not require the reader to assume that every security process is proof of control, and it does not treat a title on a council as a substitute for examining authority over the protocol. Instead, it preserves the same underlying inquiry: whether a person or coordinated group has the material ability to change functionality, operation, or rules; restrict a user; or affect transactions outside the solely transparent, pre-established-code condition.

The provision is also a limitation on overreading the rest of the proposal. It prevents an automatic conclusion from a single kind of participation. That leaves the facts of authority, rather than mere affiliation, to do the work in the statutory test. The text does not provide a universal safe harbor for all security-related conduct, and it does not identify every possible form of protocol governance. It addresses one specified circumstance: participation in an incident-response or security council alone.

Software and ledgers are not the registrant in their own capacity

The bill's treatment of software and distributed ledger systems is similarly narrow and direct. It says those systems, and people engaged in providing them, are not required to register in their own capacity. This recognizes the difference between a technical artifact or network and a person or group that may exercise material authority over a covered protocol. It does not eliminate the separate inquiry into control that precedes the proposed regulatory obligations.

The phrase "in their own capacity" keeps the scope of that assurance tied to the role being described. A distributed ledger system cannot itself submit disclosures or conduct supervision as a legal actor. A software developer's provision of code also is not the same fact as the authority to alter a protocol's functionality, operation, or rules. The bill places both propositions in the same framework without equating them.

This construction also avoids treating transparent code as a complete answer in every case. The proposed definition asks whether transactions are governed solely by transparent, pre-established code, alongside the other specified forms of material authority. Published code and distributed infrastructure may be relevant facts, but the bill's text directs attention to the governing condition of transactions and to the powers a person or coordinated group actually holds.

The revised proposal therefore describes two related limits. First, software and distributed ledger systems do not register in their own capacity. Second, security or incident-response council participation alone does not establish control. Neither limit removes the proposed framework for people or groups that meet the control test. The revised CLARITY Act text leaves the detailed implementation to agency and Treasury action that would follow the bill's enactment.

The immediate Senate development reported by Cointelegraph is the Sept. 15 procedural vote, which requires 60 votes to advance. The reported vote is a procedural step, not an agency rulemaking result. Until the legislative process and any required rulemaking produce further action, the confirmed revision is the bill language: an activity-based framework for controllers of non-decentralized finance trading protocols, a Treasury assignment concerning Bank Secrecy Act obligations, and explicit limits for software, ledger systems, and security-council participation.