Senate Banking Nears Vote on Digital Asset Market Structure

The Senate Banking Committee is finally nearing a committee vote on market structure legislation. Coin Center’s priorities throughout have been twofold: first, to pass the Blockchain Regulatory Certainty Act (BRCA) alongside market structure, thereby removing the single greatest threat to crypto developers—abusive unlicensed money transmission prosecutions—and second, to ensure that developers of genuinely decentralized protocols are not swept into new regulatory categories at the Securities and Exchange Commission (SEC), Commodity Futures Trading Commission (CFTC), or Department of Treasury.

While a small number of issues remain, discussed below, we are very encouraged by the tremendous progress made by Senate Banking. The BRCA is attached and unmodified, and the jurisdiction of the Treasury and SEC with respect to software developers is generally well-restricted.

Below is a title-by-title overview of the Senate Banking Committee’s market structure proposal, intended to highlight the major components of the bill at a high level. This summary is followed by more detailed discussion of specific sections that are core to Coin Center’s mission, including areas where we strongly support the bill’s approach, as well as provisions where we believe additional clarity or changes may be needed to ensure the legislation functions as intended.

Title-By-Title Overview

Title I – Responsible Securities Innovation

Title I amends the securities laws to clarify that digital assets are not securities by default, separating the asset itself from fundraising or promotional activity that might constitute an investment contract. It creates a limited disclosure regime for “ancillary assets” sold in reliance on an issuer’s ongoing efforts, while recognizing that “network tokens” are not securities simply because they are used or traded on a decentralized network. One important provision to watch is Section 104, which requires the SEC to define “common control”—a term used throughout the bill to help distinguish centralized intermediaries from decentralized network participants.

Title II – Protecting Against Illicit Finance

Title II attempts to strengthen existing anti-money laundering laws as they are applied to the crypto ecosystem. In particular, this Title updates the Bank Secrecy Act (BSA) to account for new categories of digital commodity intermediaries regulated by the CFTC under proposed parallel market structure legislation.

Title III – Responsible Innovation in Decentralized Finance

Title III largely addresses the extent to which existing financial regulations apply to on-chain activity, particularly in the context of decentralized finance applications. As discussed in detail below, Section 301 introduces a framework distinguishing “decentralized” and “non-decentralized” protocols based on whether any person or group has authority to control, modify, or restrict use of a protocol, with regulatory obligations attaching only where such control exists. The Title also includes provisions related to sanctions compliance and other regulatory considerations for certain application-layer activity.

Title IV – Responsible Banking Innovation

Title IV focuses on integrating digital assets into the traditional banking system by allowing banking institutions to engage in digital asset activities otherwise permissible under law and directs regulators to update capital and risk rules accordingly.

Title V – Responsible Regulatory Innovation

Title V directs agencies to study emerging financial technologies, including tokenization, and to coordinate on pilot programs and reports to Congress. It does not impose new regulatory requirements.

Title VI – Protecting Software Developers and Software Innovation

Title VI provides explicit statutory protections for software developers and individual users—core interests of Coin Center—by addressing long-standing uncertainty about how financial regulations apply to non-custodial and software-based activity. It includes provisions clarifying the treatment of software development under securities laws, codifying protections for non-custodial blockchain developers under federal money transmission laws, and safeguarding the ability of individuals to hold and transact with digital assets without mandatory reliance on intermediaries.

Due to their importance, we dive deeper into these sections below and note areas we believe changes are necessary to ensure that the protections promised by its inclusion are fully realized.

Title VII – Protecting Customer Property

Title VII amends the Bankruptcy Code to clarify that certain digital assets held by intermediaries are treated as “customer property” in the event of insolvency, rather than as part of the intermediary’s general estate. The goal is to improve customers’ ability to recover their assets if a regulated digital asset intermediary enters bankruptcy.

Title VIII – Customer Protection

Title VIII adds a set of consumer-protection and disclosure requirements for digital asset intermediaries, including educational materials, risk disclosures, and agency studies on financial literacy in the digital asset ecosystem. It also preserves existing authority for the Federal Trade Commission (FTC) and Consumer Financial Protection Bureau (CFPB) to protect consumers.

Title IX – Other Matters

Title IX focuses on implementation and coordination, directing the SEC and CFTC to work together on rulemaking and information-sharing and providing additional funding for the Financial Crimes Enforcement Network’s (FinCEN) digital asset work. It also sets timelines for agencies to complete required rules and reports under the Act.

Relevant Sections

Section 201

Section 201 expands the definition of “financial institution” in the BSA to include new categories of digital commodity brokers, dealers, and exchanges that are expected to be regulated by the CFTC under parallel market structure legislation currently working through the Senate Agriculture Committee. As a result, these entities would be subject to BSA requirements promulgated by Treasury designed for those new types of financial institutions.

This approach is consistent with Coin Center’s view that the BSA should not create new, bespoke categories of regulated activity, but should instead apply only to centralized businesses that are already clearly defined and regulated under existing or newly created SEC or CFTC regulatory frameworks.

Section 301

Section 301 distinguishes between “decentralized” and “non-decentralized” protocols based on whether a person, or group of persons under common control, has authority to materially alter protocol functionality or to restrict or censor its use. Under this framework, only “non-decentralized” protocols may give rise to regulatory obligations under the existing securities laws or the Bank Secrecy Act. Even then, designation as “non-decentralized” is not itself dispositive. The SEC or Treasury must still determine whether the relevant actors fit within an existing regulated category, such as money transmitter or broker-dealer.

While this section can appear technology-specific and imposing at first glance, a careful reading shows that it primarily formalizes a process the agencies have already pursued informally: ensuring that traditional, centralized businesses that engage in decentralization theater cannot avoid established regulatory obligations. Importantly, Section 301 also—when read alongside the BRCA and the other protections in Title VI—creates a strong presumption that agencies may not attempt to force developers of genuinely decentralized tools and services into regulated categories that were never designed to apply to them.

Coin Center generally supports this decentralized versus centralized framework as a clear and principled way to distinguish regulated intermediary activity from protected software publication and network participation, but we have concerns that the statute may leave the door open to regulatory interpretations that may risk extending beyond that intended distinction.

To that end, Section 301 is largely well calibrated to avoid application of the BSA or securities laws to genuinely decentralized protocols and their developers. However, there is a backdoor risk. Section 104(b) authorizes the SEC to define “control” and “common control” by rule, and those definitions feed directly into the threshold determinations in Section 301. Through rulemaking, a hostile future Commission could define common control broadly enough to encompass coordinated or interdependent activity among multiple actors, even where there is no formal agreement, agency relationship, or shared intent to act as a unit.

Using such a definition, developers or maintainers of a protocol could be treated collectively as a group acting in concert, notwithstanding the absence of good-faith common control. Once aggregated, the SEC could attribute to the group “control of the operation” of a protocol based on cumulative effects rather than individual authority. That attribution could support a finding that the protocol is non-decentralized under Section 301(a)(2), even though no individual actor has unilateral power to alter functionality, restrict use, or override predetermined rules.

With that finding in place, Section 301(b) would permit SEC rulemaking to determine whether the aggregated group must register under the Exchange Act, based on how the SEC characterizes the functions performed. If registration were required, downstream consequences could follow through existing law. Certain securities intermediary classifications already carry BSA obligations, and those obligations could attach indirectly through securities law status rather than through money transmission. This path does not rely on treating software development as money transmission and is not foreclosed by section 604 (i.e., BRCA), which is limited to money service business-like regimes. The result is that coordinated but non-authoritative software activity could be transformed into regulatory exposure through definitional breadth and constructive aggregation. This is a real threat, however we are working with the drafters to find an amenable solution.

Section 302

Section 302 requires the Treasury Department to issue guidance clarifying how “distributed ledger application layers” must comply with existing U.S. sanctions laws. As defined, this term refers to web-hosted software interfaces that allow users to submit instructions to a protocol, and it explicitly excludes wallets, protocols, validators, nodes, and other underlying infrastructure. Importantly, the provision does not create new sanctions obligations. It instead directs Treasury to explain how existing sanctions laws apply to this narrow category of front-end software.

The section’s breadth and prescriptive tone nonetheless raise some questions. Congress specifies a number of elements that Treasury should address in its guidance, including the use of blockchain analytics tools and the implementation of risk-based controls. That level of technical specificity is not ideal, particularly given the wide variation among front-end implementations. Still, because the provision does not amend any underlying sanctions statutes or grant Treasury new enforcement authority, and when read in the context of the bill as a whole, we do not view Section 302 as warranting substantial advocacy attention at this stage.

Section 302 also contemplates guidance addressing anti-money laundering obligations and special measures under Section 311 of the USA PATRIOT Act. At first glance, this is concerning, as many front-ends are non-custodial and have no role in collecting or maintaining user information. The statute, however, limits such guidance to what is “applicable” and explicitly reiterates that nothing in the section expands the scope of the BSA or Section 311 authority. Both regimes operate through entities that are already financial institutions under existing law. Taken together with the developer protections in Title VI and the BRCA’s clear limitation on treating software developers as money transmitters or as engaged in money transmitting, Section 302 cannot be used to impose anti-money laundering or Section 311 obligations on non-custodial developers or front-end maintainers who are not otherwise regulated financial institutions.

Section 601

Section 601(b) establishes a statutory exclusion from the securities laws for software development and related infrastructure activity when a person is being regulated solely on that basis. The exclusion expressly covers developing, publishing, or constituting distributed ledger systems and software that enables users to custody their own assets; it does not distinguish between stages of development and does not treat dissemination of software as an intermediary function.

Section 601(d) directs the SEC to engage in notice-and-comment rulemaking to clarify the circumstances under which a person is not subject to the Act by reason of engaging solely in certain activities. The activities listed in subsection (d)(1) include “administering, maintaining, or otherwise distributing” systems and software, along with other operational components. These activities are framed as subjects of clarification rather than as statutory exclusions in their own right.

The structural problem arises from Section 601(c). Although labeled a rule of construction, subsection (c) states that the statutory exclusion from securities laws does not extend to any activity covered in subsection (d)(1). In other words, because subsection (d)(1) includes “otherwise distributing” software, the carve-out in subsection (c) can be read to remove ordinary software dissemination from the statutory exclusion and place it into the rulemaking domain.

Distribution is inherent to software development. Sharing source code, transmitting compiled software, publishing updates, or providing copies to collaborators are all forms of distribution. By placing “otherwise distributing” software within the set of activities governed by subsection (d)(1), subsection (c) enables an interpretation under which software development remains nominally protected, but software dissemination is treated as an activity whose permissibility depends on the SEC’s clarification. That interpretation does not require the SEC to assert new jurisdiction; it follows from the interaction between the exclusion in subsection (b)(3), the carve-out in subsection (c), and the scope of subsection (d)(1).

This type of interpretive move has occurred before. For example, under Chair Gary Gensler’s tenure, the SEC moved to treat software distribution, specifically “making available a communications protocol” as part of the definition of “exchange.”

The inclusion of “administering” in subsection (d)(1) does not create the same problem. Read plainly, administration refers to the operation of systems rather than the dissemination of expressive material. The overbreadth risk instead arises from coupling the rule of construction in subsection (c) with a rulemaking list that includes distribution of software itself, allowing the statutory exclusion to be narrowed by interpretation rather than amendment.

The reference to “including” in subsection (c) may have been intended to limit the rule of construction to activities performed after deployment. That approach is insufficient for two reasons. First, under established canons of statutory construction, “including” introduces a non-exhaustive list of examples rather than a limitation. As a result, activities described in subsection (d)(1) may be treated as excluded from the statutory safe harbor regardless of whether they occur before or after deployment. Second, post-deployment activity should remain categorically excluded where it consists solely of software distribution, such as publishing source code or transmitting software after it has been deployed on-chain. While it may be sensible to cabin administering and maintaining activities in the rulemaking to the post-deployment context, subsection (c) as drafted does not accomplish that result.

Finally, while subsection (d)(3) states that the clarification rulemaking does not expand the jurisdiction of the Commission, the scope of that jurisdiction is itself contested, as reflected in the SEC’s recent Exchange Act rulemaking. By expressly directing the SEC to clarify the circumstances under which software-related activities fall within or outside the Act, this section may be cited to support the view that Congress intended the SEC to resolve ambiguities in this area. That express delegation could weaken future arguments that an aggressive interpretation exceeds the SEC’s authority under the Major Questions Doctrine, even where the underlying jurisdictional question remains disputed.

Section 604

Section 604 incorporates the Blockchain Regulatory Certainty Act (BRCA), legislation Coin Center has long championed to codify Treasury guidance and prevent unjust prosecutions of non-custodial software developers who do not take control of user funds. As a reminder, the BRCA explicitly makes it so a “non-controlling developer or provider shall not be treated as a money transmitting business, as defined in 5330 of title 31” or as “engaged in money transmitting, as defined in 1960 of title 18” solely on the basis of publishing software, providing software or hardware tools for others to use, or providing infrastructure support.

Section 605

Section 605 incorporates the Keep Your Coins Act by prohibiting the federal government from prohibiting, restricting, or otherwise impairing the right of individuals to hold and transact with digital assets without being forced into the use of intermediaries or subject to restrictions on lawful self-custody.

What’s Next?

We’re optimistic that things are on track and hopeful for reasonable fixes for the issues we described in 301 and 601. The bill will still need to be married with the Senate Agriculture Committee’s work and then sent back to the House, and there remain a handful of technical issues that deserve careful attention. But the overall trajectory is encouraging.

If enacted, the inclusion of the Blockchain Regulatory Certainty Act would represent a significant step forward in protecting developers from abusive unlicensed money transmission prosecutions, while the market structure framework would provide long-needed federal clarity for genuinely centralized actors operating in the digital asset space. Coin Center has been advocating for both outcomes for nearly a decade. With continued attention to the remaining details, these goals are now realistically within reach.