On the Eve of the CLARITY Vote: A Blockchain Builder's Case for Clear Boundaries

On Tuesday, the U.S. Senate is scheduled to decide whether to advance consideration of the CLARITY Act. It is a procedural vote, not final passage. Still, it is a moment worth pausing for.^[1]

I support CLARITY because the blockchain industry needs something harder than less regulation. We need to know what can be built, what crosses a red line, and who is responsible for what. Those boundaries should be clear enough that a serious builder can begin following them while writing the first line of code. We need more than one crypto-friendly administration. We need rules of the road that can survive a change of government.

Last month, I wrote “CLARITY Is Not Token Legalization: Why the Industry Still Needs It”. That article asked what a token actually represents. I will not repeat that argument here. This time, I want to ask a builder's question: once we make rights, control, and responsibility explicit in a product, can the law give us a boundary we can rely on for the long term?

This is not legal advice or a prediction about the vote. It is a record of what I hope this process will deliver.

We are waiting for more than a friendly administration

When we began designing ArcBlock in 2017, U.S. digital-asset law was not a blank page. The SEC published the DAO Report that year. Securities, anti-fraud, anti-money-laundering, and sanctions laws already applied.^[2] What builders lacked was a complete map they could execute against. Too many practical questions had to be inferred from scattered statements, enforcement cases, and legal opinions.

Many of us believed that a government interested in innovation, combined with industry self-regulation and goodwill, would gradually fill in that map. We worked on that assumption. Avoid the known minefields, build real technology, explain what a token does, and wait for the law to catch up.

We waited for years. During the Biden administration, the industry experienced an enforcement-first environment. My complaint is not that regulators enforced the law. Fraud, theft of customer assets, money laundering, and sanctions evasion should be prosecuted. The problem was that when the boundaries among custody, software, protocols, exchanges, and ordinary services could only be discovered one case at a time, the people most determined to follow the rules became the most hesitant to move.

For me, this was not an abstract Washington debate.

In 2019, ArcBlock joined the Cascadia Blockchain Council as a steering committee member. Bittrex was a founding member. Dragonchain worked with us on Washington State policy efforts.^[3] RChain was another familiar name in Seattle's blockchain community. These were not companies I knew from headlines. They were in the neighborhood.

Over time, the room became quieter.

Bittrex left the U.S. market in 2023 and later entered bankruptcy and wind-down proceedings. It cited U.S. regulatory uncertainty as one reason, while also facing SEC registration claims and an earlier OFAC enforcement action.^[4] That story cannot honestly be reduced to “regulation killed a company.” RChain dissolved amid documented governance, financial, and operational problems.^[5] Dragonchain did not shut down, but it spent years defending an SEC case filed in 2022. The case was dismissed with prejudice in 2025, and the SEC expressly said the dismissal reflected a change in regulatory approach rather than a judgment on the merits of its allegations.^[6]

I am not grouping these stories together to decide who was right. Clear law does not guarantee that a company will succeed. It means that when a company succeeds or fails, the result can depend more on its technology, product, governance, and market, and less on whether it correctly guessed how an agency would interpret its work years later.

FTX made the point from the other direction. It cultivated a strong compliance image and close government relationships. None of that substituted for segregation of customer assets, internal controls, or basic anti-fraud enforcement.^[7] When good builders cannot locate the boundary while bad actors care only about the odds of being caught, ambiguity does not produce caution. It causes the cautious people to stop first.

Boundaries should follow control and conduct

The parts of the final text that matter most to me are not the labels applied to particular tokens. They are practical boundaries.

One comes from the Blockchain Regulatory Certainty Act.^[1] It seeks to distinguish writing software and providing infrastructure from controlling user assets. If a developer or provider lacks the unilateral ability to initiate, alter, or complete transactions involving a user's assets, publishing and maintaining software, supporting customer self-custody, or operating ledger infrastructure should not by itself make that party a money transmitter or financial institution.

This may sound like legal drafting, but it describes product architecture. Can a wallet developer move assets without the user? Can a protocol maintainer complete a transaction for the user? Does a service take custody? Those are control boundaries that can be inspected in a system. They are not marketing labels.

The final text also protects room for self-hosted wallets and lawful self-custody while preserving enforcement of anti-money-laundering, counter-terrorist-financing, sanctions, fraud, and theft laws.^[1] Both sides matter. Protecting a developer who does not control user assets cannot protect someone who uses code as a cover to control or take them. Protecting self-custody cannot immunize illegal conduct.

That is what clarity should do. It should give good-faith experimentation a defined space, allow repairable mistakes inside that space, and make the red lines visible. Freedom does not mean having no boundary. It means being able to see the boundary and trust that its meaning will not be rewritten years later.

For an application blockchain, the distinction is concrete

ArcBlock has always treated blockchain as application infrastructure, not just a trading market. That makes us skeptical whenever very different mechanisms are compressed into the phrase “a token.”

ABT is the native token of ArcBlock Chain. It can be used for network fees, application payments, and Stake for Gas. Stake for X is a different mechanism: a user locks tokens for a defined purpose, period, and set of rules, with release or disposition governed by those conditions. It is not another word for yield. Application Credit Tokens can represent service credits. Curve Tokens apply protocol rules to issuance, destruction, and conversion against a reserve token. NFTs, verifiable credentials, and DIDs can carry ownership, credentials, access, and verifiable claims.

All of these mechanisms may involve tokens, but the user's rights, the issuer's obligations, the locus of control, transferability, and redemption can be completely different. If law looks only at a name, it misses the substance. If a product relies only on a name, it is avoiding the work of explaining that substance.

I do not want legislation to declare the answer for ABT or any ArcBlock token. I want it to ask questions clear enough that we can build the answers into the system.

That is why the final text's distinctions among a network token, an investment contract, and actual financial rights matter.^[1] A digital object may not itself be a security while an offer or sale involving it may still form an investment contract. A project cannot complete its own classification by writing “utility” on a website. The analysis still has to follow facts, rights, and conduct. That is not effortless, but it is more honest than passing through a gate with a label.

Clarity must survive elections

The SEC and CFTC are already doing useful work.^[8] They have provided clearer interpretations involving taxonomy, protocol staking, airdrops, wrapping, and agency coordination. The SEC has also proposed exemptions and safe harbors shaped for crypto assets. These changes matter to anyone building now.

But SEC Chairman Paul Atkins made the deeper point in an August statement: legislation remains indispensable because rules must be durable enough that a future regulator cannot simply unwind them. I agree.

If the industry's operating conditions swing with each administration, “friendly” means temporary relief. Administrative policy can serve as a bridge, but it cannot be the only bridge we are allowed to cross. Builders make products intended to last for years, sometimes decades. We cannot re-guess the meaning of wallet, protocol, token, and software after every election.

I do not know what form this text may ultimately take as law, and I do not assume every provision is perfect. The real test is whether it can place innovation and enforcement on the same map: let developers who do not control user assets write software, let users exercise lawful self-custody, judge useful digital objects by their rights and conduct, and leave no hiding place for fraud, misappropriation, or bad actors disguised as innovators.

That is what I hope for on the eve of the CLARITY vote. We do not need regulators to look away from innovation. We need a boundary that is clear enough to follow and durable enough to trust. Whatever happens in Tuesday's procedural vote, that is still the question U.S. digital-asset policy must eventually answer.

References