SEC Just Defined 'What Is a Security' in Crypto for First Time—Did They Finally Get It Right?

[startup_steve]

After eight years of “regulation by enforcement” and contradictory guidance that left crypto projects guessing whether they’d get sued, the SEC finally did something remarkable: they issued clear definitions.

On March 17, 2026, the Securities and Exchange Commission released joint interpretive guidance with the CFTC establishing a five-category taxonomy for crypto assets. As a former SEC attorney who spent years navigating the agency’s ambiguous stance on digital assets, I can tell you this is genuinely historic—but the devil’s in the implementation details.

The Five-Category Framework

The guidance defines crypto assets into five distinct categories:

1. Digital Commodities - Crypto assets deriving value from network utility and supply-demand dynamics, not from managerial efforts. Examples: Bitcoin, Ether, Solana, XRP, Dogecoin, and 11 others explicitly named.

2. Digital Collectibles - NFTs and similar assets valued for uniqueness rather than investment expectations.

3. Digital Tools - Tokens providing functional utility within a protocol (governance, fee payments, network access).

4. Stablecoins - Assets pegged to fiat currencies. Treatment “only partially resolved” per the guidance—this category remains messy.

5. Digital Securities - Traditional securities that happen to be tokenized, or tokens meeting the Howey test for investment contracts.

Critical shift: Only digital securities fall under SEC oversight. Digital commodities, collectibles, and tools are NOT securities by themselves.

What Changed?

The old regime: Everything was potentially a security until proven otherwise via expensive litigation or no-action letters. The Howey test applied retroactively, leaving projects vulnerable years after launch.

The new regime: Clear categories with named examples provide upfront classification guidance. 16 major crypto assets explicitly identified as digital commodities means those ecosystems can finally plan without existential regulatory risk.

The guidance also clarifies that airdrops, protocol mining, protocol staking, and wrapping non-security assets generally don’t create securities—huge relief for DeFi protocols.

Where the Tension Lies

Here’s where my lawyer brain starts worrying:

Evolving tokens: What happens when a “digital tool” adds yield-bearing features and starts looking like an investment? Does classification change retroactively?

Edge cases: Composable DeFi means tokens can be multiple things simultaneously. A governance token might be a “tool” for voting but generate value from protocol revenue—is that still just a tool?

Investment contract overlay: The guidance emphasizes that even non-security crypto assets can be “subject to an investment contract” during fundraising. When does that investment contract end? The SEC says when the issuer fulfills representations or fails to deliver—but that’s still subjective.

Stablecoin limbo: The guidance admits stablecoin treatment is “only partially resolved.” For an asset class that’s become core DeFi collateral, this ambiguity is problematic.

My Take (Former SEC Attorney Perspective)

This is progress. Real, meaningful progress.

For the first time, legitimate projects can design tokens with regulatory classification in mind rather than hoping the SEC doesn’t come knocking. The explicit naming of 16 digital commodities removes uncertainty for those ecosystems. The clarification on staking, mining, and airdrops addresses the most common DeFi activities.

But (and this is a big but), regulation isn’t just about the rules written—it’s about how they’re enforced. The real test comes when:

• A project launches as a “digital tool” but users start treating it as an investment
• Protocols add features that blur category boundaries
• The SEC staff applies these definitions to novel token models we haven’t imagined yet

The guidance mentions forthcoming rules on “startup exemptions,” “fundraising exemptions,” and an “investment contract safe harbor.” Those details matter immensely and we’re still waiting.

Questions for the Community

For builders: Do these categories give you enough clarity to design tokens confidently? Or do the edge cases around evolving utility still create too much uncertainty?

For investors/VCs: Does this framework make you more willing to fund crypto projects? What compliance questions remain?

For developers: Are you rethinking token designs to fit clearly into one category? Or does the “investment contract overlay” concern mean you’re still uncertain?

I spent years watching the SEC regulate through Wells notices and enforcement actions. Having a framework—even an imperfect one—beats the previous regime of regulatory ambush. But implementation will reveal whether this truly provides the clarity the industry needs or just creates new edge cases to fight over.

What’s your read? Did the SEC finally get it right, or are we headed for confusion just dressed up in clearer language?

Legal clarity unlocks institutional capital—let’s see if this delivers.

[ethereum_emma]

This is… honestly both exciting and terrifying at the same time?

I’m working on a protocol token right now, and I’ve been staring at this SEC guidance for the past week trying to figure out where we fit. We have a governance token that lets holders vote on protocol parameters, but it also accrues a portion of protocol fees. So is that a “digital tool” because it provides governance utility? Or is it a security because token holders effectively get revenue share?

The more I read the guidance, the more questions I have:

Governance tokens: If a token lets you vote on protocol decisions, that’s clearly a “tool” right? But what if the decisions you’re voting on directly impact revenue distribution? Does the value deriving from “managerial efforts” of the DAO mean it’s now a security?

DeFi protocol tokens: Most DeFi protocols have tokens that do multiple things - governance, fee discounts, revenue sharing, liquidity mining rewards. How do you even classify something that’s intentionally designed to be composable and multi-functional?

Evolution problem: Our token starts as pure governance (tool), but we’re planning to add fee-sharing in v2. Does that mean we need to register as a security later? Or does the fact that we disclosed this roadmap upfront make the whole thing an investment contract from day one?

I really appreciate that the SEC is trying to provide clarity - this is way better than the “every token is a security until we say otherwise” regime. But I’m a developer, not a lawyer, and I’m still not confident I can classify our own token correctly.

Practical question: Is anyone working on a decision tree or flowchart for token classification? Something like “if your token does X, Y, Z then it’s category A”? I learn way better from visual guides than reading 50+ pages of legal interpretation.

Also, the whole “investment contract overlay” thing scares me. It sounds like even if your token is a “digital tool,” you can still get in trouble if you market it wrong during fundraising. So we need both: (1) the right token design AND (2) the right marketing/fundraising approach. That’s a lot of legal surface area for a small team.

Resources I’ve found helpful so far:

• Morgan Lewis analysis - breaks down each category
• Sullivan & Cromwell memo - focuses on investment contract overlay

But I’m still trying to translate “legal guidance” into “smart contract design decisions.” Anyone else in the same boat? What’s your team’s approach to classification?

[solidity_sarah]

@ethereum_emma I’m right there with you on the classification confusion. From an auditor’s perspective, this guidance creates a whole new set of questions for smart contract design and security review.

Classification Affects Code Requirements

Here’s what concerns me: different token classifications likely require different security controls and contract patterns. For example:

Digital Securities need:

• Transfer restrictions (accredited investor checks, compliance rules)
• Pausability for regulatory compliance
• Admin controls for forced transfers (court orders, sanctions)
• More extensive logging and audit trails

Digital Tools might need:

• Different governance patterns (utility-focused vs investment-focused)
• Clear separation between utility functions and value capture
• Documentation proving functional use case

But the SEC guidance doesn’t provide technical specifications for any of this. It’s up to us as developers and auditors to translate legal categories into code requirements.

The Upgradeability Problem

@ethereum_emma your question about tokens evolving hits a major technical concern: proxy contracts and upgradeability.

Most modern protocols use upgradeable proxy patterns to fix bugs and add features. But what happens when an upgrade changes the token’s classification?

Example scenario:

1. Deploy token as “digital tool” with pure governance
2. Pass audit based on that classification
3. DAO votes to add fee-sharing mechanism via upgrade
4. Token might now be a security, but existing contracts weren’t designed with securities requirements in mind

Do we need classification-aware upgrade guards? Should proxy contracts include checks that prevent changes which could shift regulatory status?

Questions for Auditors

When I audit a protocol token now, what am I supposed to verify?

• That the code matches the claimed classification?
• That the contract prevents upgrades which could change classification?
• That marketing materials don’t contradict the technical implementation?

The OWASP Smart Contract Top 10 for 2026 already shows business logic vulnerabilities are now #2 (reentrancy dropped to #8). Token classification adds another layer of business logic risk.

Practical Example

Let’s say you’re building a governance token (digital tool):

// Digital Tool - governance utility
function vote(uint proposalId) external {
    require(balanceOf(msg.sender) > 0, "No voting power");
    // voting logic
}

// But what if DAO adds this via upgrade?
function claimFees() external {
    uint fees = calculateFees(msg.sender);
    // Now it's revenue sharing - is this still a "tool"?
}

Do we need to build classification checks into the contract itself? Should the code enforce that certain functions can’t be added without triggering compliance review?

My Recommendation

Until we get more technical guidance, I’m advising clients to:

1. Document classification intent in contract comments and natspec
2. Separate concerns - keep governance in one contract, any value capture in separate contracts
3. Build with classification in mind - if you might add fee-sharing later, design for securities compliance from day one
4. Audit twice - once at launch, again if major features added

Security first, classification compliance second, but they’re increasingly intertwined.

Anyone else thinking about how to build classification-aware smart contracts?

[blockchain_brian]

The technical implications here go deeper than token design—this affects protocol architecture at the infrastructure level.

Cross-Chain Classification Challenges

One aspect the SEC guidance doesn’t address: what happens when the same token exists on multiple chains with different behaviors?

Real scenario I’m dealing with on a cross-chain project:

• Token on Ethereum = pure governance (digital tool)
• Same token bridged to Arbitrum = governance + fee-sharing (potentially a security?)
• Wrapped version on Polygon = different utility entirely

Does classification follow the token across bridges? Or does each chain version get evaluated separately? The SEC’s jurisdiction is US-based, but blockchain doesn’t respect borders.

L2 and Rollup Token Implications

@solidity_sarah your upgradeability concern extends to L2s. Most Layer 2s have their own governance tokens (ARB, OP, etc.). The SEC explicitly named several L1 tokens as “digital commodities” (ETH, SOL, etc.), but what about L2 tokens?

If an L2 token provides:

• Gas fee discounts (utility = digital tool)
• Sequencer revenue sharing (investment returns = security?)
• Network governance (voting rights = tool)

Which category wins? Or do we need hybrid classification?

The Infrastructure Provider Dilemma

Here’s where it hits home for infrastructure providers like BlockEden and other RPC/node services:

If we provide infrastructure for protocols whose tokens later get classified as securities, do we need to:

• Screen which tokens we support?
• Implement transfer restrictions at the RPC level?
• Add compliance hooks to our API endpoints?

The SEC guidance says staking and protocol mining generally don’t create securities, which is great for infrastructure. But what about:

• Liquid staking derivatives (LSDs)?
• Restaking protocols?
• MEV rewards distribution?

These are infrastructure-layer activities that blur the lines between utility and investment.

Technical Implementation Questions

If a token is classified as a “digital security,” the smart contract likely needs:

// Example compliance hooks
mapping(address => bool) public accreditedInvestors;
mapping(address => bool) public sanctionedAddresses;

function transfer(address to, uint amount) public override {
    require(accreditedInvestors[msg.sender], "Not accredited");
    require(!sanctionedAddresses[to], "Sanctioned address");
    require(!isRestricted(to), "Transfer restricted");
    super.transfer(to, amount);
}

But this breaks composability. How do you use a compliance-heavy token in DeFi protocols that expect standard ERC-20 behavior? Do we need a whole new token standard for “regulated DeFi”?

Cross-Protocol Dependencies

Most concerning: what about protocols built on top of other protocols?

If Aave lists a token that later gets reclassified as a security, does Aave need to delist it? Do LPs who provided liquidity face retroactive liability?

The SEC guidance mentions “investment contract” overlay, but composable DeFi means one protocol’s classification risk cascades to every protocol that integrates with it.

What I’m Watching For

The SEC says more guidance is coming on “startup exemptions” and “safe harbors.” The technical community needs:

1. Reference implementations - sample contracts for each classification category
2. On-chain compliance primitives - standards for accreditation, transfer restrictions, etc.
3. Cross-chain classification framework - how does this work for multichain tokens?
4. Composability standards - how do regulated and unregulated tokens interact?

Until then, we’re all building in a gray area where legal classification and technical implementation don’t quite line up.

Anyone working on compliance-aware token standards or infrastructure? Feels like we need an EIP for this.