From coincenter by Peter Van Valkenburgh

It has become a quadrennial holiday tradition in crypto policy for the outgoing administration to release a civil-liberties-damaging rulemaking at the last possible moment, the midnight period before a new President of the opposite party takes office. This time around it is the IRS announcing a final rule on non-custodial “brokers” and their obligations for third-party tax reporting.

This final rule addresses one half of the notice of proposed rulemaking (NPRM) we fought two years ago. As a quick reminder, Coin Center does not object to trusted and custodial crypto intermediaries being made to report the capital gains of their users. That’s an obligation that non-crypto financial institutions have had for decades and we do not think trusted institutions in crypto should get special treatment. Alongside our champions in Congress, we have been pushing the IRS to offer clarity on third party reporting since 2017. Unfortunately, when the IRS finally got around to issuing a rulemaking in 2023, they proposed imposing those reporting obligations not only on intermediary institutions but also on non-custodial software developers, so-called “unhosted wallet providers.” As we wrote in our comment letter at the time:

We object to the imposition of reporting obligations on any software or communications intermediaries who do not have any agency or agency-like relationship with the users of their published tools and websites, and who are in no position to know or collect personal information about those users. Indeed, we find that the extension of reporting obligations to these persons, among other legal defects, runs counter to the underlying statutory authority, the legislative history, and—most importantly—would violate the First Amendment rights of cryptocurrency software, data, and website publishers and the Fourth Amendment rights of both the publishers and the users of said software, data, and websites.

Last July we thought we might have caught a break in this broker saga; the IRS released a partial final rule covering only trusted intermediaries. Ideally, that would have been the end of it, but—like the Terminator—this Christmas the non-custodial rulemaking is back!

What’s changed in the final rule?

Like the NPRM from last year, today’s final rule could still obligate mere developers and infrastructure providers to surveil and report on the users of their tools. The new language in this final rule is often even more verbose and difficult to parse than the original proposed language. We’re going to spend a lot of time over the next few weeks deeply analyzing it all. However, on first read, it looks like the end result is largely the same as the NPRM: the rule creates a complicated and vague multi-prong test for whether a developer’s activities obligate them to write software that collects information on the users of that software for purposes of warrantless surveillance.

Here’s but one example of how these complicated changes to the final rule do little to address any of our concerns. The original rule had the following hierarchy of nested definitions to determine whether someone is a broker: Brokers included “digital asset middleman,” which included providers of a “facilitative service” if those providers “ordinarily would know or be in a position to know the identity of the party that makes the sale and the nature of the transaction potentially giving rise to gross proceeds from the sale.” Further, according to the original rule, someone would “ordinarily know or be in a position to know” the identities of the users of their software if they “have the ability to set or change the terms under which its services are provided to request that the party making the sale provide that party’s name, address, and taxpayer identification number upon request.”

What was fascinating and infuriating about this nested structure in the NPRM was that it basically boiled down to: broker = person who provides facilitative services and has the ability to request people’s identity. Given that providing “facilitative services” included providing software that users use to make cryptocurrency transactions, the rule basically said that you are a broker if you provide trading software and could, as a condition to providing that software to users, ask them for identification. When you simplify the convoluted nested structure it becomes a clear prohibition on distributing software to anyone you’ve not KYC’d.

The final rule makes some mostly cosmetic changes to that nested structure. Rather than defining a “facilitative service” the rule defines an “effectuating service.” We objected to “facilitative” given that the statutory authority is limited to those who actually effectuate transactions on behalf of users rather than those who merely facilitate the transactions of others. However, the final rule merely switches out “facilitative” for “effectuating” in the definition of the service but does not ask the important question: whether the provider of the service themselves actually effectuates the transaction or merely helps someone else do it themselves. In most relevant cases outside of custodial exchange (which are already obligated as brokers), it is the blockchain network and the users themselves that effectuate a trade, not the software that helps the user to write and sign the requisite transaction data and broadcast it to the blockchain network. If I merely write wallet or front-end software that allows users to interact with smart contracts, then I don’t effectuate those trades. More plainly, If I build you a safe and you put gold in it, I don’t “effectuate” your gold storage and it’s unreasonable to ask me to report to the IRS on the value of your gold.

Now it is true that the provider of this “effectuating service” is still only obligated as a broker if he “ordinarily would know or be in a position to know the identity of the persons using his service.” And you might think that this exempts the metaphorical safe manufacturer (or the non-metaphorical wallet developer) from having to report on the capital gains of the gold stored by purchasers of his safes. That would be true if the IRS had not made it effectively illegal to build safes that do not have a camera inside of them that allows the safe manufacturer to see what’s in the safe. Remember that the definition of “position to know” is, itself, almost 400 words long and boils down to whether you could ask for the information. The safe manufacturer could put cameras in all of his safes. In fact, the final rule also includes a prohibition on building your software services such that it would be impossible to change the software going forward to ask for the information (i.e. making the trading tools immutable smart contracts):

Except as provided by the Secretary, a contractual or other restriction … that limits the ability of the person providing trading frontend services to amend, update, or otherwise substantively affect the terms under which the services are provided (including the manner in which any fees are collected) or the manner in which the order is processed will be disregarded for purposes of this paragraph [the paragraph that determines whether you are “in a position to know”].

So if you add immutable encryption-based restrictions to your software that protect the privacy of your software users and also prevent you from being in a position to know their transactions, you will still be obligated as a broker to learn the identity of the users of your software and report the details of their trades. This is, in effect, a prohibition on building software tools that empower and protect users. It’s basically a policy choice that says,

That policy choice is the opposite of what Congress decided after much debate during the passage of the Infrastructure Act. Indeed, six Senators who were key to narrowing the original language on the floor wrote a letter that underscored the need to avoid such an overbroad interpretation: “[t]he purpose of this provision is not to impose new reporting requirements on people who do not meet the definition of brokers.”

The final rule also makes cosmetic changes to the sub-categories of effectuating services (formerly facilitative services). A new term is introduced, “trading front-end service.” That new definition stands in for some of the various services in the “such as” section of the original “facilitative services” definition from the NPRM. Here’s the definition in the final rule:

A trading front-end service means a service that, with respect to a sale of digital assets, receives a person’s order to sell and processes that order for execution by providing user interface services, including graphic and voice user interface services, that are designed to:

(i) Enable such person to input order details with respect to a transaction to be carried out or settled on a cryptographically secured distributed ledger (or any similar technology); and

(ii) Transmit those order details so that the transaction can be carried out or settled on a cryptographically secured distributed ledger (or any similar technology), including by transmitting the order details to the person’s wallet in such form that, if authorized by the person, causes the order details to be transmitted to a distributed ledger network for interaction with a digital asset trading protocol as defined in paragraph (a)(21)(iii)(D) of this section.

As with the previous terms in the NPRM’s facilitative services definition, this definition could just as easily describe a piece of wallet or blockchain software that operates autonomously with no input or involvement from the original developer as it could describe a service that’s fully controlled by an operator. Coin Center does not object to broker obligations for trusted operators, but this definition does nothing to delineate the line between a trusted operator and a mere developer of trading software. As before, the only limiting factor in the rule is whether the provider of that “trading front-end service” is “in a position to know” details about the service user, and “in a position to know” is defined as, in effect, “being able to ask.”

In our comment letter last year we proposed a much simpler approach to defining who should be a broker. That proposal was in line with the statutory authority granted by Congress and followed a centuries-old approach to regulating trusted middlemen: simply limit the definition of broker to people who are or act as agents of their customers. That agency-based standard is in the statute, has a common law basis in agency law to allow for sensible legal reasoning about the breadth and depth of the category, and would be far less likely to jeopardize the speech and privacy rights of developers and users of this technology. Unfortunately the IRS refused to adopt our approach and chose instead to further convolute its already overbroad approach with new terms and nested definitions.

What happens now?

As a final rule, there’s no further opportunity to comment and help the agency understand where it has gone awry. There are, however, two important ways we need to fight back now.

First, the incoming Congress should use the Congressional Review Act (CRA) to rescind the rule. Congress has the power to rescind federal agency rules through the CRA by passing a joint resolution of disapproval, and it should do so in this case.

Our champions in Congress have repeatedly warned the IRS about overstepping their statutory bounds and unconstitutionally regulating any infrastructure or software developers as “unhosted wallet providers.” We will be working with those allies and new members to move the ball forward on a CRA recision of this non-custodial broker rule.

Second, to prepare for the possibility that the CRA process stalls or fails, there should be lawsuits brought right now arguing that the rule is unconstitutional. Many parties have standing to challenge this law because they build wallet software, and ideal challengers should step forward. We wrote our comment to the original NPRM as a warning to the IRS but also as a guide to how the rule lies outside of the statutory authority granted to the IRS by Congress in the Infrastructure Investment and Jobs Act and how the rule could be argued to be unconstitutional under both the First and Fourth Amendments.

Our full comment letter offers a detailed account of how to craft these arguments. In brief they are as follows.

The rule is beyond the statutory authority.

The Infrastructure Investment and Jobs Act amended the definition of broker to include[], emphases added, “any person who (for consideration) is responsible for regularly providing any service effectuating transfers of digital assets on behalf of another person.”

Congress chose to use the same verb, “effectuating,” as the existing agency-focused regulatory definition, “effect,” and emphasized the same principal-agent relationship with the plain language “on behalf of another person.”

The plain meaning of the amendment, therefore, directs the Treasury Department to maintain the existing scope of the definition with respect to types of activities that trigger reporting obligations. Those activities should continue to be understood as being an agent for a customer and effecting sales on that customer’s behalf or being a principal in a sale to a customer. The amendment merely expands and clarifies the broker definition with respect to the new objects of those otherwise similar activities: from agency in sales of traditional securities and commodities to cover also agency in transfers of digital assets. The plain text does not support an expansion of the definition to a new range of activities beyond the existing customer-agent or principal standard. It does not support expansion of the broker definition to persons who are mere communications intermediaries, software developers, or other persons who merely facilitate the activities of persons buying or selling digital assets but do not act as the person’s agent in a transaction or as a principal in a sale to that person.

The rule is a violation of our speech rights.

The proposed rule directs brokers to make disclosures to the IRS and the taxpayer. Mandatory reporting and disclosure provisions of any kind compel speech. Any law that compels speech faces, at least, exacting scrutiny from the courts. Exacting scrutiny requires that the rule be narrowly tailored to address a compelling government interest. The proposed rule creates disclosure obligations for persons who do not in the ordinary course of their business have any reason to collect and report the requested information. The rule is therefore not narrowly tailored; it would subject far more persons to an onerous disclosure regime than is appropriate to promote tax compliance.

And the rule is a warrantless search and seizure.

The extension of reporting obligations is inappropriate even under the permissive standards of the original third party doctrine. Both the Fourth Amendment interest of the obligated entity, the broker, and then the interest of the users of the broker’s tools are implicated. In both cases we find that existing case law does not support the constitutionality of the proposal. Carpenter v. United States and other recent case law suggests an even steeper uphill climb for the government to justify the warrantless collection of data from persons who are not brokers in the traditional sense, i.e., are not customer agents or principals in sales.

This holiday season we don’t get the gift of an opportunity to write a last-minute comment letter as we have in the past, but we will be marshaling our efforts to stop this attack on our civil liberties. As John Conner said, “There’s no fate but what we make for ourselves.” A joyful New Year to you all.