Software, Speech, and the Blockchain

June 15, 2026

The prosecutions of Roman Storm and Alex Pertsev sat at the center of every digital-asset policy conversation for the three years before CLARITY was engrossed. The U.S. case, United States v. Storm, No. 1:23-cr-00430 (S.D.N.Y.), charged the co-founder of Tornado Cash with conspiracy to commit money laundering and to operate an unlicensed money transmitting business based on his role in developing and publishing the protocol’s open-source smart-contract code. The Dutch prosecution of Pertsev produced a five-year prison sentence in May 2024 on substantially similar theories. Van Loon v. Department of the Treasury, 122 F.4th 549 (5th Cir. 2024), held in parallel that OFAC could not designate immutable smart-contract addresses under IEEPA because the addresses were not “property” capable of being blocked under the statute. The result was a doctrinal split that put publishing source code somewhere between protected First Amendment expression (Bernstein v. United States Department of Justice, 176 F.3d 1132 (9th Cir. 1999); Junger v. Daley, 209 F.3d 481 (6th Cir. 2000)) and a federal felony, depending on what the code did once it was published and whether the publisher could be characterized as still controlling it.

Title VI of CLARITY resolves the split in favor of speech. The resolution runs through three operative provisions and one rulemaking direction. §601 amends both the Securities Act and the Exchange Act to immunize a defined list of activities from securities-law liability. §604, which incorporates the Blockchain Regulatory Certainty Act in substance, defines “non-controlling developer or provider” and exempts that class from money-transmitter status under 31 U.S.C. § 5330 and 18 U.S.C. § 1960. §605, the Keep Your Coins Act, prohibits federal agencies from restricting self-custody. §301(b)(2)(B), covered in Post #6 of this series, directs the SEC’s rulemaking on non-DeFi trading protocols to protect the First Amendment rights of software developers, publishers, and users. Read together, they are the most explicit congressional accommodation of code-as-speech doctrine since the Crypto Wars of the 1990s.

§601 and the new Securities Act / Exchange Act safe harbors

§601(a) inserts a new §27C into the Securities Act of 1933 titled “Application to Software Developers.” §601(b) inserts a parallel §15H into the Securities Exchange Act of 1934. Both sections operate as carve-outs. They provide that a person is not subject to the underlying Act, or to the regulations under that Act, “solely based on” engaging in any of a defined list of activities, whether singly or in combination, in relation to the operation of a distributed ledger system or any component of it. The lists in §27C(b) and §15H(b) are not identical, and the differences matter.

The Securities Act §27C(b) safe harbor lists two activity categories. (1) compiling network transactions, relaying, searching, sequencing, validating, or acting in a similar capacity. (2) providing computational work, operating a node or oracle service, or procuring, offering, or utilizing network bandwidth, or providing other similar incidental services. The Securities Act safe harbor stops there. The list maps onto the §301(a)(2)(C)(i) and (ii) activity carve-outs covered in Post #6 of this series, and the drafting parallel is intentional.

The Exchange Act §15H(b) safe harbor adds a third category: (3) developing, publishing, or constituting a distributed ledger system, or software or systems (including wallets) that facilitate user self-custody. “Constitute” is defined in §15H(a)(1) to mean compiling, assembling, integrating, or otherwise combining software components into a complete software system. So the Exchange Act safe harbor protects, in plain English, building or distributing the protocol itself, plus building or distributing wallet software. The Securities Act safe harbor protects only running infrastructure for it. The asymmetry is reasonable: the Exchange Act has historically been the source of the broker, dealer, and exchange registration claims that have been pressed against software publishers, while the Securities Act has been the source of issuer-side registration claims that would not apply to pure development activity in any event.

Both safe harbors apply “solely based on” the listed activity. That phrase is important. It does not immunize a developer who is doing the protected activity plus other unprotected conduct. A developer who publishes a protocol and also operates a custodial business using that protocol is not within the safe harbor for the custodial business. The carve-out tracks the activity, not the actor. A developer who limits her activity to the listed categories cannot be a respondent in a Securities Act or Exchange Act proceeding founded on those activities. A developer whose activities exceed the listed categories has to defend the excess activity on its own terms.

§15H also incorporates a clarification regime. §15H(d)(1) directs the Commission, through notice-and-comment rulemaking, to clarify the circumstances under which a person engaging solely in one or more of four additional activities, in relation to the operation of a decentralized finance trading protocol or any component, is not subject to the Exchange Act. The four are: (A) providing a user interface that enables a user to read and access data; (B) administering, maintaining, or distributing a decentralized governance system or a decentralized finance trading protocol; (C) administering, maintaining, or distributing a decentralized finance messaging system or operating a smart-contract-based liquidity pool; and (D) administering, maintaining, or distributing software or systems facilitating user self-custody. The clarification rulemaking imports the §15H(d)(2) considerations: consistency with securities-law purposes, applicability of the Lummis-Gillibrand RFIA §108(a), protection of First Amendment rights of developers, publishers, and users, and legal clarity for DLS development.

§15H(d) is the bridge from the categorical safe harbor in §15H(b) to the activities that surround front-end interface operation, governance facilitation, and liquidity-pool participation. The bill does not categorically immunize those activities. It directs the SEC, instead, to draw lines through rulemaking, with First Amendment compliance as a binding statutory directive. The structural choice is sensible: front-end operators and liquidity-pool participants are closer to the edge of the protected zone than core developers or infrastructure operators, and the lines need to be drawn with attention to operational facts. The §15H(d)(3) rule of construction is also important. It confirms that the Commission has no authority over persons, systems, software, or activities that do not otherwise fall within the Commission’s jurisdiction under the Exchange Act, and creates no presumption that any activity is subject to the Act.

§15H(e) preserves the Commission’s anti-fraud, anti-manipulation, and false-reporting authorities. The §15H(b) and (d) determinations of non-subject status do not extend to those authorities. The point is structurally the same one made in §4B(b)(4)(B) and §4B(h): the offering and registration regime is the regime being immunized. Anti-fraud authority continues to run, on its own terms, against anyone who satisfies the elements of an anti-fraud violation.

§15H(f) prevents the Commission from leveraging the section to expand its authority over digital commodities or to regulate the §15H(d)(1) activities beyond what existing law permitted. §15H(g)(1) preempts state securities, commodities, and digital-asset laws as applied to the §15H(b) activities, with §15H(g)(2) preserving state AML, anti-fraud, and anti-manipulation authority. The federal-preemption choice for the §15H(b) activities, but not the §15H(d) clarification activities, is deliberate. The categorical safe harbor activities are protected fully, including from state blue-sky enforcement. The clarification-rulemaking activities are protected only to the extent the SEC’s rule provides protection, and state law may continue to operate in the meantime.

§604: BRCA and the money-transmitter line

§604 incorporates the Blockchain Regulatory Certainty Act as a discrete subtitle. The substantive provision is §604(c), which states that “notwithstanding any other provision of law,” a non-controlling developer or provider shall not be treated as a money transmitting business under 31 U.S.C. § 5330 or as engaged in money transmitting under 18 U.S.C. § 1960, and shall not be subject to any registration requirement substantially similar to those in §§ 5330 or 1960, solely on the basis of creating or publishing software, providing hardware or software facilitating customer self-custody, or providing infrastructure support to maintain a distributed ledger service.

The definitional work in §604(b)(3) is where the law gets decided. A “non-controlling developer or provider” is one that, in the regular course of operations, “does not have 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, without the approval, consent, or direction of any other third party.” The phrase tracks the structural test the Fifth Circuit applied in Van Loon to the Tornado Cash smart contracts. The court held that immutable smart contracts were not “property” capable of being blocked under IEEPA because no one had the ability to control them. §604(b)(3) takes the same control-in-fact concept and applies it as a statutory test for BSA money-transmitter exposure.

Three structural elements deserve attention. First, the test is conjunctive on its enumerated dimensions (”control, initiate upon demand, or effectuate”). A developer who lacks the ability to do any of these things on her own is non-controlling. A developer who has the ability to do any one of them is controlling. Second, the inability must be operational, not contractual. The phrase “in the regular course of operations” means that a developer with a theoretical legal right to control that she does not exercise is still controlling if she could exercise it. The test is functional. Third, the consent of a third party defeats independent control. A developer who can only act with the consent of a multisig she does not control, or only at the direction of a DAO vote she does not control, is non-controlling. This is the structural exit for protocol teams that have migrated upgrade authority to DAOs.

§604(d) clarifies that the safe harbor does not extend to a person who acts “with the specific intent to transfer, on behalf of another person, funds that are known… to be derived from a criminal offense or intended to be used to promote or support unlawful activity.” That language tracks 18 U.S.C. § 1960(b)(1)(C) and the United States v. Velastegui line on knowing and intentional unlicensed money-transmission liability. The point is that the §604(c) safe harbor protects publishing and infrastructure activity; it does not protect knowing facilitation of criminal money movement. A developer who builds a mixer with the specific intent to launder criminal proceeds is still exposed under §1960(b)(1)(C) even if she meets the structural non-controlling test.

§604(e) is the conduct-based residual. It preserves application of money-transmitter classification based on conduct outside the scope of §604(c). A developer who is non-controlling with respect to the protocol but also operates a custodial exchange remains subject to BSA classification as to the exchange activity. The carve-out tracks activity, again, and follows the same architectural pattern as §15H(b) and §301(a)(2)(C).

The interaction with FinCEN’s 2019 guidance is direct. FIN-2019-G001 already drew a similar line, exempting from money-transmitter status persons providing “anonymizing software” but treating as money transmitters persons providing “anonymizing services” with control over user funds. §604(b)(3) codifies the control-in-fact line and overrides any FinCEN interpretive position that would treat a non-controlling developer or provider as a money transmitter. FinCEN’s existing guidance on developers of unhosted-wallet software, mining-pool operators, and protocol publishers is now interpretive support for, rather than independent authority over, the §604 line.

§605: self-custody as a federal right

§605 is the Keep Your Coins Act. The operative provision is §605(c): a federal agency may not prohibit, restrict, or otherwise impair the ability of a covered user to self-custody digital assets using a self-hosted wallet or other means to conduct transactions for any lawful purpose. A “covered user” is defined in §605(b)(1) as a U.S. individual who obtains digital assets to purchase goods or services on behalf of that individual, without regard to the method of acquisition. A “self-hosted wallet” is defined in §605(b)(2) as a digital interface used to secure and transfer digital assets where the owner retains independent control.

The provision operates as a statutory bar on federal-agency action restricting self-custody. The 2020 FinCEN NPRM (Notice 2020-CVC-2), which proposed reporting and recordkeeping requirements for unhosted wallet transactions, is foreclosed in the form it took. The IRS Final Regulations on Broker Reporting, T.D. 10000, which extended Form 1099-DA reporting to certain unhosted-wallet intermediaries, would need to be re-evaluated under §605 to the extent any provision could be characterized as restricting individuals from self-custody for the purchase of goods or services. The provision does not preempt state law (state AML and state consumer-protection authorities remain operative), and it does not bar lawful enforcement under existing federal authority.

§605(d) preserves federal-agency enforcement authority under the Bank Secrecy Act, the Combating Russian Money Laundering Act §9714, the Fentanyl Sanctions Act §7213A, and any other law relating to illicit finance, money laundering, terrorism financing, or U.S. sanctions. The drafting choice is to immunize ordinary self-custody activity by individuals, while preserving the enforcement authorities that target unlawful activity. The line is narrower than some self-custody advocates wanted, but it is broad enough to take the 2020 FinCEN NPRM, and any successor proposal in that form, off the table.

§301(b)(2)(B) and the First Amendment as binding directive

§301(b)(2)(B), covered in Post #6 of this series, directs the Commission to “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.” The directive is binding on the §301 rulemaking and, through cross-reference, on the §15H(d) clarification rulemaking. The same First Amendment compliance directive recurs in §15H(d)(2)(C).

The legal substance of the directive is Bernstein and Junger. Both circuits held that source code is expressive speech subject to First Amendment protection, and that prepublication restraints on source-code publication are subject to strict scrutiny. Bernstein, 176 F.3d at 1140-46; Junger, 209 F.3d at 484-85. The doctrinal posture has been stable for twenty-five years, but the Tornado Cash prosecutions tested it under contemporary money-transmitter and OFAC theories. The Fifth Circuit in Van Loon reached the OFAC question and held that immutable smart contracts were not “property” capable of being blocked. The criminal prosecutions of Storm and Pertsev pressed past the First Amendment defense on the theory that the developers were not merely publishing code but operating the resulting protocol. CLARITY codifies a line that tracks the Fifth Circuit’s reasoning and preempts the prosecutorial theory that conduct adjacent to publication can be reached on a code-equals-conduct basis.

Three points about how the directive operates. First, the directive is binding on agency rulemaking, not on the agency in litigation. The SEC and Treasury can still bring enforcement actions that would have been brought under existing law against persons whose conduct exceeds publishing and operating infrastructure. What they cannot do is promulgate rules that themselves restrict the protected activity. The directive is structural, not adjudicative. Second, the directive is enforceable through the Administrative Procedure Act. A rule that fails to comply with the First Amendment directive is “not in accordance with law” under 5 U.S.C. § 706(2)(A) and can be set aside. Third, the directive is paired with the §604 categorical safe harbor and the §605 self-custody right. A First Amendment violation by an agency would, in many cases, also be a §604 or §605 violation. The directive operates as a backstop to the categorical provisions, not as the sole protection for the protected activity.

What the Tornado Cash defendants would have under CLARITY

Roman Storm was charged with conspiracy to commit money laundering under 18 U.S.C. § 1956(h), conspiracy to operate an unlicensed money transmitting business under 18 U.S.C. § 1960, and conspiracy to violate IEEPA under 50 U.S.C. § 1705. The §1960 count is the one most directly affected by §604.

Storm’s defense, in substance, was that he was a software developer who published open-source code and that the code, once published, ran without his ability to control it. The Department of Justice’s theory was that Storm and his co-defendants continued to operate the Tornado Cash front-end, maintained relay infrastructure, and were paid by the protocol’s token economics in ways that constituted operation, not just publication. The factual question of how much operational control Storm retained is for the jury. The legal question of whether non-controlling-developer status is a defense to §1960 is for the court.

Under §604(c), if Storm met the §604(b)(3) non-controlling test for the relevant activity, the §1960 charge based on that activity could not proceed. Whether he met the test is fact-specific. The protocol’s smart contracts are immutable; the relay network was, as a structural matter, an open infrastructure layer that anyone could run; the front-end was open-source and forkable. On those facts, a substantial portion of the §1960 charge would not survive the §604(c) safe harbor. The §604(d) intent carve-out preserves prosecution to the extent the government can prove specific intent to transfer criminally derived funds, but that is a meaningfully higher evidentiary standard than the general money-transmitter theory of liability the government pressed at trial.

The IEEPA charge sits outside §604 and is unaffected directly. The OFAC designations of Tornado Cash smart-contract addresses were withdrawn by Treasury in March 2025 following Van Loon. Whatever criminal exposure remains under the IEEPA theory is a function of whether the defendants knowingly transacted with sanctioned addresses during the period the designations were in effect, which is a question independent of the §604 safe harbor.

The §1956 money-laundering charge requires proof of intent to conceal or to promote unlawful activity. §604(d) confirms that the safe harbor does not reach intentional money laundering. The §1956(h) charge survives on its own elements, but its application to publishing and infrastructure activity is constrained by the §604(c) categorical immunity for the publishing and infrastructure conduct itself.

The structural shift is what matters. Under existing law, a developer of an immutable mixer protocol faced the same nominal exposure as the operator of a custodial mixing service, with the defense to be litigated case-by-case. Under §604 and §605, the developer of an immutable mixer protocol is not a money transmitter under §5330 or §1960 by reason of the publication, and the user of that protocol cannot be restricted by federal-agency rulemaking from self-custodying her own funds and using the protocol for lawful purposes. The unlawful-purpose conduct remains prosecutable on the unlawful-purpose elements. The publishing and self-custody conduct does not.

The takeaway is the one Coin Center has been articulating for years. Code is speech. Publishing is protected. Self-custody is a right. Conduct that exceeds publication, infrastructure operation, and self-custody remains regulable on its own terms. CLARITY does not invent any of this; it codifies what the constitutional doctrine has said since 1999, with the operational definitions that the criminal-law and BSA enforcement regimes have lacked. The cost of getting these provisions through Congress was the §305 temporary-hold regime and the §307 monetary-instrument amendment covered in Posts #14 and #15. Whether the trade was worth it is a separate question. But the protections that did make it into Title VI are, on their face, the most substantial statutory accommodation of code-as-speech doctrine in the history of U.S. financial regulation.

Written by David Lopez Kurtz