THE POST-CLARITY REALITY: RETURN TO THE GRAY ZONE

Across the crypto industry in the past few months, there has been significant discussion and push to drive the CLARITY Act to a vote in the Senate and ultimately to become law later this year. We’ve been told that our best chance to turn this landmark legislation into law would be a vote prior to the August recess.

Today is August 7th, and recess is starting with no vote on CLARITY. With the Senate prioritizing a vote on the government spending bill ahead of the August recess, a delay on CLARITY looks all but inevitable, and the current odds on Polymarket for CLARITY to become law in 2026 have dropped to 16%. 

A return to the gray zone is precisely where the crypto industry will reside if the CLARITY Act fails to pass. This article will explore the implications of a 2026 without CLARITY. As builders, we need to get comfortable with it. 

Possible Agency-Led Regulatory Activity

Both the SEC and CFTC have been extremely proactive during this administration with guidance, no-action letters, and rulemaking. The agencies don’t have authority to make law, but they are empowered to interpret existing law and set rules. Blockchain is a new technology, and Clarity was partially designed to address the gaps where current law does not fit or is not applicable. However, the Agencies still have wide latitude to push forward additional guidance and conditional relief regardless of CLARITY. We expect them to continue through the next two years. 

For example, the SEC has been teasing the release of the Innovation Exemption under their Project Crypto. This would likely have a far-ranging impact on how traditional securities trade onchain, among other things. 

A Deeper Dive into Token Projects Without CLARITY.

Without CLARITY, you'll be shipping code under the SEC-CFTC Joint Token Taxonomy until further notice. This framework will be, hands down, the most critical blueprint for token launch teams. 

Under this joint framework, the SEC explicitly acknowledges that tokens are not inherently securities. An underlying token can exist as a non-security digital commodity; however, any token may be legally treated as an investment contract (i.e., as a security) until the asset officially "separates" from the project team’s essential managerial efforts.

In the abstract, most builders of decentralized networks should want their tokens to be treated as digital commodities. This means your tokens can be used and spent freely across networks, traded on standard crypto exchanges like Coinbase or Binance, and don’t require complex or expensive registration processes that often don’t make sense for digital commodities. 

So what is the important takeaway from the taxonomy? For builders, the bottleneck isn't achieving clean, arbitrary network decentralization, it's managing the project team’s own representations. Under the SEC’s taxonomy, an investment contract exists only as long as buyers reasonably rely on specific representations and timelines from the core project team.

Take a hard look at your earliest investor communications and marketing materials: whitepapers, discord roadmaps, and the rest.

• The Separation Trigger: A token legally detaches from its investment contract wrapper (i.e., treatment as a security) only when the core team either fulfills its promised development milestones or formally abandons them, rendering the protocol fully autonomous.
• The Marketing Trap: Vague promises or perpetual dev roadmaps keep the token tethered to federal securities law. If your marketing implies that token holders are betting on your ongoing engineering efforts rather than present, functional code, you freeze the token in investment contract limbo—now you’re dealing with a security until that promise is fulfilled. 
• Complete Functional Delivery: Shipping the exact smart contract code, open-source SDKs, or decentralized governance parameters promised in the original specification. The system runs whether your company exists tomorrow.

Under this framework, the standard for token separation is contractual, not technocratic. That distinction may be the single most important contribution in the entire framework. If your team promises a specific governance transition, smart contract immutability, or feature by v1.0, fulfilling those explicit representations is what legally cuts the cord between the investment contract wrapper (treatment as a security) and the underlying digital commodity.

The Builder’s Playbook Without CLARITY

Without a safe harbor from Congress, the SEC’s taxonomy and Footnote 96 are the best engineering specification available. To launch a token successfully under this administrative reality, teams must shift their go-to-market strategy from hype-driven roadmaps to explicit, deliverable software commitments that have achievable end dates:

1.     Audit Your Public Statements: Comb through every whitepaper, forum post, and tweet. Eradicate open-ended promises of "future value creation" driven by the core team.

2.     Define Clear Milestone Boundaries: State explicitly what functionality constitutes the completed protocol so you can verifiably trigger the "Separation Event."

3.     Ship Before You Distribute: The cleanest path to a non-security digital commodity is delivering fully functional, autonomous code before token distribution, removing reliance on managerial effort from day one.

What This Means for Apps & Front Ends: Why Builders Don't Need Congress to Keep Shipping

 The core promise of CLARITY’s developer safe harbor (Section 15H / Section 604) is simple: writing non-custodial software is not money transmission or broker activity. 

It establishes that the test is control, not labels: if you deploy smart contracts, build frontend interfaces, or publish self-custody tools but never gain the unilateral ability to control, initiate, or move user funds, you aren’t an exchange, a broker, or a bank. This safe-harbor test in CLARITY is focused on control. Control is not just about self-custody. It's about what you can do to user assets. If you retain the keys, the pause switch, or the routing discretion, then you keep the liability that comes with it.

Would it be nice to have statutory preemption from Congress? Sure.

Non-custodial software and smart contract developers don't need CLARITY to pass to keep shipping. 

Here is the reality we are dealing with. CLARITY seeks to codify a legal distinction that is already well-grounded in existing administrative guidance, constitutional doctrine, and statutory authority. The existing framework already existed without CLARITY and continues today:

• SEC-CFTC Joint Interpretive Guidance: Established a joint view that tokens are not inherently securities. Digital commodities, collectibles, utility tools, and payment stablecoins sit firmly outside SEC jurisdiction. SEC oversight of a non-security crypto asset is triggered only when value depends on essential managerial efforts, evaluated primarily through the project’s own representations. The token separates from that security oversight once promised development is complete or abandoned.
• SEC April 13, 2026 Staff Relief: Officially draws the line between running a brokerage and simply hosting software. Under this relief, developers can build user-facing platforms for crypto securities without triggering broker-dealer registration, provided that the interface remains strictly non-custodial, neutral, and user-directed. Read our analysis here.
• The CFTC’s Phantom No-Action Letter: Provides Phantom, a self-custodial software developer, a clear, non-broker pathway to connect users with regulated derivatives venues and share in trading fees. In exchange for registration relief, front-end providers must operate purely passive interfaces, deliver mandatory risk disclosures, and enter joint-liability agreements with their registered exchange partners.
• Double Zero No-Action Letter: SEC staff conditionally accepted that 2Z token flows are not sales of securities but rather automated, "programmatic transfers" hardcoded directly into network logic. Because token distributions serve purely as operational compensation for infrastructure and resource providers, they fail Howey’s managerial prong and avoid triggering federal securities registration.
• FinCEN CVC Guidance: FinCEN explicitly established that software developers who merely create or publish unhosted wallet software, self-custodial multi-signature tools, or decentralized protocol interfaces are not money transmitters under the Bank Secrecy Act (BSA) unless they directly accept and transmit value on behalf of users. 
• First Amendment Protections for Source Code: Publishing code is speech. Two federal appeals courts have said so directly: the Sixth Circuit in Junger v. Daley and the Second Circuit in Universal City Studios v. Corley, reasoning that source code is how programmers exchange ideas, and that being functional doesn't strip that protection. Publishing non-custodial smart contracts without controlling user assets is closer to software publication than to executing regulated financial transactions.

CLARITY would offer a clean, statutory preemption on top of these rules, but the core architecture for non-custodial software publishing is already soundly positioned today under the current regulatory framework. 

What's Still Coming

Beyond what's already on the books, several items are in the pipeline:

Investment-contract safe harbor (token → non-security): Sets clear off-ramps for when a token stops being treated as a security (once founders step back from central management), bundled with a mid-scale $75M fundraising tier. Currently sitting in draft form, not yet published for public comment.

On-chain tokenized-securities trading exemption: It was targeted for May 2026, did not materialize, and was shelved for further internal review after pushback from Nasdaq, NYSE, and others over investor protection and competitive concerns. The last statement from SEC Chairman Paul Atkins came in July 2026 (via the SEC's 2026 Regulatory Agenda) and confirmed that a key item of the regulatory agenda is to provide clarity as to how market participants can custody and facilitate trading of tokenized securities on-chain.

A Future Note - Permissioned Pools, NMS Securities, and RWAs

CLARITY was written and designed to address the many gaps in our existing laws around a novel asset class, it is not a rewrite of longstanding securities or commodities rules for standard securities. At the same time, blockchain technology is actively disrupting the securities industry. Some of the most exciting developments in the blockchain industry currently revolve around tokenization and RWAs. The SEC and CFTC already have the authority to design new rules, and many industry participants are eagerly anticipating new guidance for onchain transactions of traditional securities. We are firmly in speculative territory now. We don’t know how or when the SEC may act, but it is widely expected that they are ready to engage.

As of today, RWAs largely don’t trade within DeFi, and to the extent that they do, they largely exclude U.S. participants. Most trading of RWAs occurs on foreign-domiciled spot exchanges with foreign-issued wrapper securities that exclude the U.S. There are a multitude of different reasons for this, but largely this can be attributed to regulatory certainty (unlike crypto commodities). Traditional securities have longstanding rules on how, by whom, and where they can be traded or offered. Some of those rules already work fine with blockchain technology, and some of those rules are hard or impossible to comply with. With regulatory certainty, the various market actors (exchanges, market makers, DeFi protocols, etc.) have largely decided to stand away. You have a clear path to a fine if you don’t follow the rules - even if those rules aren’t currently technically possible to follow using this new technology.

Permissioned Pools are an interesting example of this phenomenon. Last week, Uniswap introduced v4 pools with hooks to check onchain allowlists published by Transfer Agents like Superstate or Securitize. Permissioned Pools on v4 offer gated, compliant liquidity for regulated and tokenized assets.KYC’d, whitelisted, or accredited-only pools gate participation at the door, ring-fencing the KYC/AML and investor-eligibility questions that decide whether regulated capital can enter a market at all.

This is important because institutions carry their own AML obligations no matter what Congress does, so rather than wait for a bright-line rule, permissioned venues draw the line themselves. 

However, this doesn’t mean we will actually have trading of permissioned assets in the near term without further guidance from the SEC. Trade reporting, NBBO (national best bid, best offer rules for NMS securities), pricing data, etc. are all requirements in traditional trading infrastructure, and it’s not clear who is responsible for implementation or enforcement of these rules in a truly decentralized system. Moreover, it’s not clear who bears the ultimate liability. Because base-layer software carries no statutory shield, that risk cascades straight down to the smart-contract layer, and open, permissionless AMMs start to read as legal hazard zones for the developers and liquidity providers exposed to them. 

As a result, we likely won’t see any meaningful trading of these permissioned assets in permissioned pools until the SEC takes some further action. But once it does, which the SEC has hinted at, we are in a position to see meaningful expansion of true trading onchain. 

Clarity on CLARITY, in either direction, is likely to accelerate the SEC. They likely don’t want to interject themselves into the middle of legislative conversation, but if CLARITY does pass, then they can interpret the bill and implement these rules. Or conversely, if CLARITY doesn’t look likely to pass, they can move forward with the status quo. 

We won’t know the exact rules of the road, but builders should be preparing themselves for a future when permissioned assets have some type of sandbox or safe harbor to trade onchain, which is an extremely exciting development.

CoinList does not provide legal, banking or tax services. Nothing in this blog post shall constitute or be construed as an offering of securities or as investment advice, tax advice or investment recommendations.