TL;DR:
- Charles Hoskinson attacked efforts to remove Section 604 from the Clarity Act, saying open-source developers could face unfair liability for third-party misuse.
- The National Fraternal Order of Police argued the provision may weaken cryptocurrency crime enforcement by shielding non-controlling developers and infrastructure providers.
- The fight could influence whether US crypto development remains open and permissionless or shifts toward closed, monitored systems to reduce legal exposure in the coming market cycle.
Charles Hoskinson escalated a Washington fight over the Clarity Act after efforts emerged to remove Section 604, which shields non-controlling developers from money transmitter treatment. The founder called the push āinsanityā and a ādystopian nightmareā for open-source software. At stake is a question: should developers face liability when strangers misuse code? For builders, the dispute turns liability into existential risk, not another compliance debate.
The insanity of their position is beyond any sense of reason. You develop open source software, you give it to the world, someone else who you've never met does something with it without your knowledge or consent, and then you're forever liable for THEIR ACTIONS.
It's a⦠https://t.co/bN1ehoIPHD
— Charles Hoskinson (@IOHK_Charles) May 13, 2026
Section 604 Becomes a Flashpoint
The pressure came from the National Fraternal Order of Police, whose president Patrick Yoes urged Senators Tim Scott and Elizabeth Warren to reconsider Section 604. The group argued the provision could weaken law enforcementās ability to pursue cryptocurrency crimes by exempting non-controlling developers or providers from money transmitter treatment. Criminal networks, it warned, could exploit decentralized platforms and blockchain tools while prosecutors face narrower targets. Yet law enforcementās loophole argument collides with software neutrality, because infrastructure can be used by people its creators neither know nor control.
Hoskinson rejected that premise in stark terms. Open-source creators, he argues, cannot reasonably become permanently liable for independent actions by third parties who use their tools without knowledge, approval or consent. He compared the logic to blaming authors for crimes inspired by fictional books, an analogy meant to separate creation from misuse. In this reading, developer liability would punish publication itself, especially in financial software, where code can be copied, modified and deployed beyond any authorās perimeter.
The broader concern is what such a rule would incentivize. Hoskinson warned that stricter liability could push developers away from open public infrastructure and toward closed, permissioned systems where every participant is monitored and approved. That could protect control, but at the cost of decentralization. The paradox is obvious: a crackdown meant to fight criminal abuse could weaken open architecture that makes many blockchain networks distinct from conventional intermediaries.
The outcome may shape where crypto infrastructure gets built next. If Washington narrows Section 604 or removes it, developers may relocate innovation outside US jurisdiction or design systems that sacrifice openness to reduce legal exposure. If it survives, critics will still demand stronger tools against illicit finance. Either way, the Clarity Act debate now reaches beyond market structure, testing whether the US wants open-source crypto software treated as neutral infrastructure or as a regulated financial actor by default.






