Blockchain Association Policy Summit 2025, Washington, DC: Commissioner Hester Peirce of the SEC was interviewed by moderator Marta Belcher of Filecoin. This conversation was framed around a clear break from “regulation by enforcement” toward a more rules‑first, experimentation‑friendly approach to digital assets. Peirce describes the SEC’s new Crypto Task Force as an explicit attempt to “do it right this time,” starting with information gathering, public clarity on jurisdiction, and rulemaking that provides durable guardrails rather than one‑off settlements. From a technologist’s perspective, the through‑line is striking: if the last decade was about the SEC treating crypto as a problem to be managed, this next phase is about treating it as infrastructure that needs a coherent operating manual.

From ad hoc enforcement to rulemaking

One of the clearest themes is Peirce’s insistence that enforcement should follow, not precede, clear rules. She contrasts the prior era, where market participants were told “just come in and register” with no viable path to do so, with the current push to define actual registration frameworks for crypto‑asset securities and related trading activity. That includes using staff statements and no‑action letters to mark off areas outside SEC jurisdiction and to identify fact patterns that will not trigger enforcement. For builders, this is closer to an API contract than a bug‑hunt: the regulator is starting to define expected behaviors up front rather than punishing undefined ones after the fact.

Taxonomy and the “token as part of an offering” problem

Peirce acknowledges that the question “when is a token a security?” has consumed far too much energy, and she confirms that the SEC is now working on a taxonomy meant to sort different types of crypto assets into clearer regulatory buckets. That taxonomy leans into the idea that a token can be part of a securities offering at one point in time, without being a security in perpetuity. Substantively, that means focusing on the promises made around a network’s build‑out, and recognizing that once those promises are fulfilled and the network is functionally decentralized, “if you’re hit by a bus, things still keep operating”, the ongoing token itself may no longer embody an investment contract. For technologists, this is a crucial conceptual shift: it aligns legal status with lifecycle and architecture, not just with the existence of a token.

Building a registration path and market plumbing

On the more mechanical side, Peirce outlines several workstreams: crafting a viable path for registering securities offerings that involve crypto assets, tackling trading and custody challenges, and updating exchange‑traded product and listing standards to cope with a wave of crypto‑linked products. She notes that the SEC has already issued no‑action relief for certain investment adviser custody issues, but emphasizes there are “a lot of other custody questions” still on the table. This is the regulatory equivalent of designing secure wallet infrastructure and market gateways: the task is to let tokens move through institutions without forcing them back into legacy abstractions that break the technology’s guarantees.

Cross‑agency coordination and jurisdictional sprawl

A recurring problem Peirce highlights is the maze of overlapping jurisdictions: tax, banking, state law, SEC, CFTC, and more. Small projects in particular confront an “immense” number of questions about where to even start. Peirce stresses active coordination with the CFTC and encourages projects to engage early rather than guess. The subtext for technologists is that protocol and product design increasingly needs a “regulatory architecture” layer, just as much as it needs security reviews or economic audits. Knowing which activities are properly in securities, commodities, payments, or tax territory will shape everything from token design to user flows.

A narrower view of what should be a security

Peirce contrasts the old stance, “everything is a security”, with her current chair’s view that “very few” crypto assets are actually securities, aside from explicit tokenized versions of traditional instruments. She still objects to the way the Howey test has been stretched into this domain, arguing that crypto represents “a new application” requiring fresh thinking, even if the test itself remains. Importantly, she advocates treating token sales with bundled promises as securities transactions for as long as those promises matter, and allowing the investment relationship to end once the network is live and self‑sustaining. For network designers, this suggests a concrete target: architect your launch and governance so that the project can demonstrably cross a threshold into functional decentralization.

DePIN and non‑financial use cases

Peirce singles out decentralized physical infrastructure networks (DePIN) and non‑financial use cases as particularly exciting and underdeveloped due to regulatory overhang. She notes that with recent no‑action relief in this space, projects should lean into making the non‑financial, participation‑driven purpose of their tokens unmistakable. From a technologist’s angle, this means designing systems where tokens are clearly tied to provisioning resources, bandwidth, storage, compute, sensors, rather than to speculative promises about price appreciation. It also suggests a more intimate collaboration between protocol economics and legal strategy: how you design incentives can either invite or deflect securities classification.

What the SEC is (and isn’t) for

Peirce is explicit that the SEC’s mandate comes from Congress and is not a general “bad things” police. Many forms of fraud and misconduct fall outside its remit, and she warns against trying to “grab jurisdiction from other regulators” or acting as a paternalistic gatekeeper. The agency’s role is to shape disclosures and market structure, not to decide which products are “good for you.” For technologists, this is a reminder that user protection cannot be fully outsourced to Washington. Smart contract transparency, on‑chain auditability, open‑source clients, and protocol‑level risk disclosures are part of the stack of protections, and they can be more precise and verifiable than traditional fine‑print.

Learning through loss, without abandoning protection

Peirce takes a stark but honest position on investor loss: losing money is often the hardest but most effective teacher, and diversification plus careful use of leverage are essential lessons. At the same time, she recognizes the societal failure when people fall prey to outright scams, including impostors pretending to be her on Telegram promising to recover lost crypto. For crypto builders, this underscores a dual responsibility. On one side, design systems and UX that make risks, permissions, and irreversible actions painfully clear. On the other, contribute to community‑driven detection and reporting of fraud, rather than waiting for agencies to identify every bad actor operating at the application edge.

Peer‑to‑peer as a structural answer

The conversation turns philosophical when Belcher and Peirce talk about peer‑to‑peer transactions and financial surveillance. Peirce argues that peer‑to‑peer systems directly address many of the harms seen in intermediated finance: custodians lending out assets, mismanaging risk, or unilaterally cutting off access. Crypto’s capacity to move value directly between users without custodial control is “very often an answer” to these problems, even if not everyone wants to live fully at that frontier. For protocol engineers, this is validation that minimizing trust assumptions, non‑custodial architectures, client‑side key management, and credibly neutral infrastructure, is not just technically elegant, but aligned with the trajectory of thoughtful regulation.

Privacy, the Fourth Amendment, and default assumptions

Belcher and Peirce dive into the tension between AML/KYC regimes and constitutional privacy norms. They criticize the modern “default” assumption that all financial transactions should be surveilled, pointing instead to the Fourth Amendment model: information, including financial data, is private by default and accessed only when there is cause and a warrant. Peirce draws on personal family history to emphasize why privacy matters in societies that can turn repressive. For technologists, this is a clear green light to keep advancing privacy‑preserving tools, zero‑knowledge proofs, shielded transactions, privacy‑preserving analytics, as first‑class infrastructure, not fringe features. The challenge is to design systems where targeted, due‑process‑based access is technically feasible without normalizing universal visibility.

Technology as infrastructure, not scapegoat

The session closes with an important analogy: many of the arguments used against crypto, that it can be used by bad actors, were once used against the internet and could be used against cars or any other general‑purpose technology. Peirce warns against treating public blockchains, protocol developers, or node operators as stand‑ins for every misuse of their systems. From a technologist’s vantage point, this reinforces a core design principle: build general‑purpose infrastructure that is as neutral and composable as possible, while ensuring there are clear layers, applications, interfaces, intermediaries, where human accountability resides. That layering makes it easier for policymakers to target specific abuses without criminalizing the substrate.

Taken together, this conversation is an unusually constructive bridge between builders and regulators. The Crypto Task Force is not a magic fix, but it signals a shift toward explicit categories, lifecycle‑sensitive treatment of tokens, and genuine respect for decentralization and privacy as legitimate design goals. For technologists, the opportunity is to design protocols and products that assume this emerging framework, and then push it further, by making user protection, transparency, and freedom architectural properties rather than afterthoughts.

For more information, please visit the following:

Website: https://www.josephraczynski.com/

Blog: https://JTConsultingMedia.com/

Podcast: https://techsnippetstoday.buzzsprout.com

LinkedIn: https://www.linkedin.com/in/joerazz/

X: https://x.com/joerazz