This morning, the SEC published the final word on a debate that’s consumed the crypto space since May 2025: whether “wrapped” versus “natively issued” tokenized securities should be treated differently under federal securities law.
The answer, delivered jointly by three SEC divisions in a comprehensive staff statement: No, they don’t.
“The format in which a security is issued or the methods by which holders are recorded (e.g., onchain vs. offchain) does not affect application of the federal securities laws.”
What Happened
After Commissioner Crenshaw posed the definitional question at the May tokenization roundtable — “Does tokenization mean issuing a security directly on a blockchain? Or creating a digital representation of a security on a blockchain?” — the industry evaluated this from the wrong angle. The right answer is that they are both securities and the rules around how they must be treated are exactly the same.
TD Securities published a taxonomy on the distinction. Law firms wrote memos. The terminology proliferated: wrapped structures, native issuance, ADR models, SPV models, synthetic exposure, tokenized entitlements.
Today’s SEC statement provides the most detailed taxonomy yet:
Issuer-Sponsored:
- Blockchain information used to inform the master file
- A read-only representation of the security onchain
Third Party-Sponsored:
- 1:1 backed in a custodial account
- A decomposed version of the security not representing all rights
This is genuinely useful for describing operational differences. But the SEC makes the critical point explicit: none of these structural variations change how securities law applies.
The Legal Foundation
Section 2(a)(1) of the Securities Act defines “security” to include notes, stocks, bonds, and “certificate of interest or participation in” any of those instruments. What’s not specified: anything about record keeping, custody, or where ownership is tracked.
Reves asks whether an instrument functions economically as a security. Howey examines the economic reality of investment contracts. Introducing the blockchain is just an implementation detail that doesn’t fundamentally change the asset.
Whether Apple stock is recorded in DTCC’s database, natively issued on a blockchain, wrapped by a custodian, or represented as a natively issued token onchain — it’s still Apple stock. The economic exposure is identical. The regulatory treatment must be too.
What Actually Requires Attention
Instead of debating wrapped versus native, here’s what matters:
Disclosure — Issuers must explain recordkeeping systems, custody arrangements, rights and obligations, supply mechanisms, technical specifications, and smart contract audit results. The content varies by structure, but the obligation is universal.
Market Structure — If wrapped tokens trade on DEXs outside NBBO while native shares trade on regulated exchanges, you get fragmentation and surveillance gaps. The solution isn’t different legal categories — it’s consistent market structure rules across venues.
Custody and Settlement — Smart contract failures, key management, corporate actions, and operational risk all require careful treatment. These are implementation questions, not questions about whether securities law applies.
Rights and Governance — Voting, dividends, bankruptcy treatment all matter enormously. The framework for analyzing them doesn’t change based on technological format.
The Bottom Line
The industry spent six months building taxonomies for a distinction that creates no meaningful legal difference. Wall Street’s largest players — SIFMA, JPMorgan, Citadel — and the SEC staff have now reached the same conclusion: this distinction is operationally relevant but legally irrelevant.
There has always been a tension between the ideal product and what is actually possible within securities law. The product people push for the best experience. The lawyers try to get it to market. But the securities laws and the blockchain are both static. We can only augment the connectivity layer in the middle.
Economic substance matters. Form doesn’t. Back to work.