CFTC Non-Custodial Developer Safe Harbor 2026: What the Proposed Rulemaking Means for DeFi Builders

For years, US-based DeFi developers have operated under a basic legal uncertainty: does writing code that facilitates commodity trading make you a broker? The CFTC appears ready to answer that question with formal rulemaking. The agency is signaling intent to codify protections for non-custodial software developers — those who build wallets and protocols but never take custody of user funds — exempting them from broker and commodity trading advisor registration under the Commodity Exchange Act (“CEA”), 7 U.S.C. § 1 et seq. This effort builds directly on the precedent set by the agency’s Phantom no-action letter, and if adopted through notice-and-comment rulemaking under the Administrative Procedure Act (“APA”), 5 U.S.C. § 553, it would convert fragile informal guidance into binding regulatory safe harbor.

Key Takeaways

• Formal rules carry the force of law; no-action letters do not. A codified CFTC safe harbor would bind the agency and require full APA rulemaking to modify or repeal — a far stronger legal foundation than the Phantom no-action letter, which represents a staff-level position that can be withdrawn at any time.
• The custody line is the critical distinction. Developers who do not hold user private keys, exercise discretion over trade execution, or act as counterparties to transactions would fall outside CEA broker and CTA registration requirements.
• This responds directly to the Ooki DAO enforcement fallout. CFTC v. Ooki DAO, No. 3:22-cv-05416 (N.D. Cal. 2022), created a chilling effect on US DeFi development by holding a DAO liable as an unincorporated association — raising unresolved questions about individual developer liability.
• A CFTC safe harbor does not address SEC exposure. The Securities and Exchange Commission maintains separate, and potentially conflicting, theories of developer liability under the federal securities laws. This gap is the single biggest limitation of the proposed rulemaking.
• The notice-and-comment period will be pivotal. When the CFTC publishes a Notice of Proposed Rulemaking (“NPRM”), the industry will have a limited window — typically 60 days — to shape definitions that will govern developer liability for years.

What Did the Phantom No-Action Letter Establish?

The Phantom no-action letter established a precedent-setting CFTC staff position: software developers who build genuinely non-custodial tools should not be required to register as introducing brokers under CEA § 4d, 7 U.S.C. § 6d, or as commodity trading advisors under CEA § 4m, 7 U.S.C. § 6m. The core reasoning drew a functional line based on custody and control rather than the nature of the software itself.

This distinction is important. Under the Phantom letter’s framework, the relevant question is not what the software does but what the developer controls. A developer who writes trading software but never holds user keys, never routes funds through developer-controlled wallets, and never exercises discretion over trade execution is functionally different from a traditional broker — and should be regulated accordingly.

However, no-action letters are inherently limited. They represent the position of CFTC staff — not the Commission itself. They do not carry the force of law, cannot be cited as binding precedent in court, and can be revoked without notice or public process. For developers making multi-year investment decisions about where to build, that level of legal fragility is insufficient.

Why Does Formal Rulemaking Change the Calculus?

The APA requires federal agencies to follow specific procedures when adopting binding rules: publish the proposed rule in the Federal Register, solicit and consider public comments, and publish a final rule with a reasoned explanation of the agency’s decisions. 5 U.S.C. §§ 553(b)–(c). Once adopted, a rule carries the force of law. It binds the agency, can only be changed through the same rulemaking process, and provides a concrete legal standard that courts must apply.

For non-custodial developers, the practical difference is significant. A developer sued by the CFTC who can point to a codified safe harbor has a strong affirmative defense. A developer relying on a no-action letter has a useful but non-binding argument about agency consistency. In litigation — or, more importantly, in the risk assessments that determine whether developers build in the US at all — that distinction matters enormously.

How Might the CFTC Define “Non-Custodial”?

The definition of “non-custodial” will be the most consequential — and most contested — element of any proposed rule. Based on the framework established by the Phantom letter, existing CFTC interpretive guidance, and the agency’s regulatory vocabulary, a safe harbor would likely require that the developer:

1. Does not hold, control, or have access to user private keys or funds at any point in the transaction lifecycle;
2. Does not exercise discretion over the execution, timing, pricing, or terms of user trades;
3. Does not act as a counterparty to any user transaction;
4. Does not collect, aggregate, or route orders in a manner constituting introducing broker activity under CFTC Regulation 1.3, 17 C.F.R. § 1.3.

The hard question is smart contracts. A human developer who deploys an immutable smart contract that subsequently routes trades without any ongoing developer involvement presents a novel regulatory problem. Does the act of deployment constitute ongoing “control”? If the developer retains an admin key or upgrade mechanism, does that change the analysis? These boundary questions were not fully resolved by the Phantom letter and will likely generate the most substantive comment during rulemaking. Practitioners should expect the definition to be the primary battleground.

The Ooki DAO Context: Enforcement Risk That Drove This Rulemaking

The CFTC’s move toward a developer safe harbor did not arise in a vacuum. In CFTC v. Ooki DAO, the agency successfully argued that a decentralized autonomous organization could be treated as an unincorporated association and held liable for operating an unregistered trading platform in violation of the CEA. The Northern District of California agreed, entering default judgment against the DAO.

While Ooki DAO targeted the DAO entity and its governance token holders — not individual developers by name — the enforcement theory created obvious downstream risk. If DAO governance participants face liability for protocol operations, the legal exposure of developers who write and deploy the underlying code is, at minimum, an open question. The result was a measurable chilling effect: multiple DeFi projects relocated development operations outside the United States or restructured to minimize US-nexus contact points.

The CFTC’s current posture — including Commissioner Caroline Pham’s digital asset market pilot program and recommendations from the agency’s Technology Advisory Committee — represents an institutional course correction. Formal rulemaking would make that correction durable and enforceable.

How Does This Interact with SEC Developer Liability?

This is the gap that no CFTC safe harbor can close. The SEC maintains parallel theories of liability for software developers under the Securities Act of 1933, 15 U.S.C. § 77a et seq., and the Securities Exchange Act of 1934, 15 U.S.C. § 78a et seq. These theories operate on a different jurisdictional basis — securities rather than commodities — and a developer cleared by the CFTC may still face SEC enforcement if the tokens traded through the protocol are classified as securities under SEC v. W.J. Howey Co., 328 U.S. 293 (1946).

Under SEC enforcement theories, developers may face exposure as:

• Unregistered broker-dealers under § 15(a) of the Exchange Act, 15 U.S.C. § 78o(a), if the protocol facilitates securities transactions;
• Unregistered exchanges under § 5 of the Exchange Act, 15 U.S.C. § 78e, if the protocol matches buy and sell orders in securities;
• Control persons under § 20(a) of the Exchange Act, 15 U.S.C. § 78t(a), if the developer maintains sufficient ongoing control over the protocol.

The SEC Crypto Task Force under Chairman Paul Atkins has signaled a more collaborative posture toward digital asset regulation, but no formal SEC safe harbor for developers has been proposed. Until both agencies align, US developers face a jurisdictional split: potentially compliant with CFTC rules but exposed under SEC theories for the same software.

Where Does Pending Legislation Fit?

The CFTC’s rulemaking does not exist in isolation from Congressional efforts to define the regulatory perimeter for digital assets. The market structure bills working through Congress — including proposals to clarify CFTC versus SEC jurisdiction over digital commodities — could either reinforce or supersede the agency’s rulemaking. If legislation establishes a statutory safe harbor for non-custodial developers, the CFTC’s rule would become complementary rather than primary. If legislation stalls, the CFTC’s rule becomes the most significant source of developer protection at the federal level.

Developers and counsel should track both tracks simultaneously. Agency rulemaking can move faster than legislation, but legislation, once enacted, carries greater legal durability and can resolve the inter-agency jurisdictional questions that the CFTC cannot address unilaterally.

The Code-as-Speech Dimension

Any developer safe harbor rulemaking will inevitably touch on a constitutional question that courts have not fully resolved in the crypto context: whether software code is protected speech under the First Amendment. Federal courts have recognized that source code can constitute expressive conduct. See Bernstein v. U.S. Dep’t of Justice, 176 F.3d 1132 (9th Cir. 1999); Universal City Studios, Inc. v. Corley, 273 F.3d 429 (2d Cir. 2001). If writing and publishing non-custodial software is expressive activity, registration requirements that condition that activity on broker status raise First Amendment concerns.

The CFTC’s safe harbor would sidestep this constitutional question by eliminating the registration trigger for qualifying developers. But the constitutional argument remains relevant as a backstop — particularly if the final rule’s definition of “non-custodial” is drawn too narrowly, or if the SEC pursues parallel enforcement against developers who fall within the CFTC safe harbor but outside its jurisdictional reach.

State-Level Obligations Remain

A federal CFTC safe harbor would not preempt state money transmitter laws. Non-custodial developers must separately evaluate whether their software triggers state licensing requirements. FinCEN guidance has generally held that developers of non-custodial software are not money transmitters under the Bank Secrecy Act, 31 U.S.C. § 5311 et seq. — see FinCEN Guidance FIN-2019-G001 (May 9, 2019) — but state regulators apply their own definitions.

New York’s BitLicense framework under 23 NYCRR Part 200 uses a broad definition of “virtual currency business activity” that could capture certain developer activities even where federal agencies have declined to regulate. Wyoming, by contrast, has enacted specific exemptions for non-custodial developers under Wyo. Stat. § 40-22-104. The state-level landscape is uneven, and a federal safe harbor does not eliminate the need for a 50-state compliance analysis.

What to Do Now

1. Audit your custody architecture. The safe harbor will turn on whether your software is genuinely non-custodial. Document every point in your system’s architecture where private keys, user funds, or trade execution discretion could be argued to rest with the developer. Pay particular attention to admin keys, upgrade mechanisms, and fee-routing contracts — these are the gray areas where the definition will be most contested.
2. Prepare for the comment period. Begin drafting comment letter frameworks now. The most impactful submissions will address the definition of “non-custodial” as applied to smart contracts, immutable protocols, and automated market makers. Industry coalitions should coordinate to present consistent technical definitions.
3. Assess SEC exposure independently. Do not treat CFTC safe harbor eligibility as comprehensive regulatory compliance. If your protocol handles tokens that may be securities under the Howey test, conduct a separate analysis of SEC broker-dealer, exchange, and control-person liability.
4. Map state-level requirements. Conduct a targeted state licensing analysis focusing on states where your user base is concentrated. At minimum, evaluate New York (BitLicense), California (DFPI requirements), and any state where you maintain a physical presence.
5. Monitor the Federal Register. Track the CFTC rulemaking docket at federalregister.gov. When the NPRM is published, the comment deadline — typically 60 days from publication — will be the industry’s window to shape the final rule.

Conclusion

The CFTC’s anticipated move toward a formal non-custodial developer safe harbor is one of the most consequential pro-development regulatory actions in US crypto policy. By elevating the Phantom no-action letter’s principles into binding rules through APA rulemaking, the Commission would provide durable legal clarity for an industry that has spent years building under regulatory ambiguity. But this is a partial solution, not a comprehensive one. The SEC jurisdictional gap, pending Congressional legislation, state licensing obligations, and the unresolved treatment of smart contract protocols all ensure that legal complexity will persist. Developers and counsel should treat this rulemaking as a critical piece of a larger, multi-agency compliance architecture — and engage aggressively in the comment process to ensure the final rule serves its intended purpose.

CryptoLaw.blog will provide detailed analysis of the proposed rule text when the NPRM is published in the Federal Register.

---

This article is for informational and educational purposes only and does not constitute legal advice. Reading this content does not create an attorney-client relationship. Laws and regulations in the cryptocurrency space change rapidly — consult a qualified attorney for advice specific to your situation and jurisdiction. Seth Goettelman is licensed to practice law in Wisconsin and Florida.