Examining SEC v. Consensys

On June 28th, the SEC filed suit against Consensys, the developer of the non-custodial wallet application MetaMask, bringing charges related to two different products: (1) MetaMask Swaps and (2) MetaMask Staking. For MetaMask Swaps, the SEC’s core allegation is that Consensys acted as an unregistered broker by “effect[ing] the exchange of one crypto asset for another on the investor’s behalf”. For MetaMask Staking, the SEC alleged Consensys both acted as an unregistered broker “by effecting transactions in the Lido and Rocket Pool investment contracts for the account of others” and engaged in the unregistered “offers and sales of the Lido and Rocket Pool staking program investment contracts”.

These charges echo those in SEC v. Coinbase, where the SEC alleged that Coinbase acted as a broker through its non-custodial wallet product, Coinbase Wallet, and engaged in the unregistered offers and sales of securities through its staking program. At the time, I was in private practice and a lead attorney working with the amazing DeFi Education Fund (DEF) team on their amicus brief in Coinbase, which went into technical detail as to why the SEC's charges regarding Coinbase Wallet and Coinbase's staking program could not stand. The court granted Coinbase's motion for judgment on the pleadings as to Coinbase Wallet but allowed the staking program claims to move forward.

Here’s a simple chart summarizing the claims on wallets and staking in these two cases, and you’ll note there is significant overlap:

In this post, I compare the wallet/swaps allegations in Coinbase and Consensys and drill down on some of the specific claims the SEC is making. My overall impression is that the SEC has done a better job in Consensys than in Coinbase of mapping its allegations to the actual elements of what it means to be a broker, but, in some instances, it exaggerates or gets key elements of how the technology functions wrong in its attempt to aggrandize Consensys’s role in users’ swaps.

First, let's define a broker. Like many things in securities laws, the definition of a broker is squishy. It's defined in the Exchange Act as “any person engaged in the business of effecting transactions in securities for the account of others”. The next reasonable question is what on Earth that means. There are a number of factors courts consider, but I'll pull the nine Coinbase cited in its motion for judgment on the pleadings:

Courts look to a number of factors to determine whether an entity is acting as a broker, including whether it “(1) actively solicits investors; (2) receives transaction-based compensation; (3) handles securities or funds of others in connection with securities transactions; (4) processes documents related to the sale of securities; (5) participates in the order-taking or order-routing process; (6) sells, or previously sold, securities of other issuers; (7) is an employee of the issuer; (8) is involved in negotiations between the issuer and the investor; and/or (9) makes valuations as to the merits of the investment or gives advice.” SEC v. GEL Direct Tr., 2023 WL 3166421, at *2 (S.D.N.Y. Apr. 28, 2023)

There is no minimum number of these factors that must be met to qualify as a broker, but the more that are met, the more likely the court will hold the entity in question is a broker. So the SEC's job in writing these complaints is to plausibly allege as many of these factors as it can to survive a motion to dismiss.

Starting with Coinbase, the core reasons the SEC did not prevail on the broker charge for Coinbase Wallet was because (1) the SEC did not allege enough of the broker factors and (2) for the factors it did allege, it did not adequately explain how Coinbase was carrying out those activities.

As explained by the court:

As an initial matter, the SEC’s allegations do not implicate many of the factors courts use in identifying a “broker.” Notably, the SEC does not allege that the Wallet application negotiates terms for the transaction, makes investment recommendations, arranges financing, holds customer funds, processes trade documentation, or conducts independent asset valuations. (SEC Opp. 25-27). Rather, the Complaint alleges that Coinbase: charged a 1% commission for Wallet’s brokerage services (Compl. ¶ 101); actively solicits investors (on its website, blog, and social media) to use Wallet (id. ¶ 75); compares prices across different third-party trading platforms (id. ¶ 82); and “routes customer orders” in crypto-asset securities to those platforms (id. ¶ 64). Upon closer examination, these allegations, alone or in combination, are insufficient to establish “brokerage activities.”

As alleged, Coinbase’s participation in the order-routing process is minimal. While Wallet “provide[s] access to or link[s] to third-party services, such as DEXs” (User Agreement App’x 4 § 8.1.2), the SEC does not allege that Coinbase performs any key trading functions on behalf of its users in connection with those activities. As the Complaint acknowledges, Coinbase has no control over a user’s crypto-assets or transactions via Wallet, which product simply provides the technical infrastructure for users to arrange transactions on other DEXs in the market. (Compl. ¶ 64). Only a user has control over her own assets, and the user is the sole decision-maker when it comes to transactions.

What is more, while Wallet helps users discover pricing on decentralized exchanges, providing pricing comparisons does not rise to the level of routing or making investment recommendations. . . . Similarly, the fact that Coinbase has, at times, received a commission does not, on its own, turn Coinbase into a broker.

As discussed above, because of these deficiencies, the court granted Coinbase’s motion for judgment on the pleadings on this charge.

After taking the "L" in Coinbase on a similar product, how did the SEC approach the broker allegations for MetaMask Swaps in Consensys? As one would expect, I think they tried to address each of the core deficiencies the court delineated in Coinbase by alleging more of the broker factors and painting a picture of Consensys and the software Consensys has built as active in the process of a user making a swap. 

For example, look at how the agency describes MetaMask Swaps in the Consensys complaint at a high-level:

MetaMask Swaps functions as follows. An investor enters the name and amount of the crypto asset that they wish to sell, as well as the name of the crypto asset that they wish to buy in return. MetaMask Swaps then pulls available rates for the requested exchange from a Consensys-curated group of execution venues and other third-party liquidity providers (referred to herein as “third-party liquidity providers”) and displays those rates to the investor, highlighting the option that Consensys deems “best.” With one additional click by the investor, MetaMask Swaps performs the functions necessary to effect the trade, on the investor’s behalf, with the third-party liquidity provider. As described in further detail below, Consensys’s software routes the investor’s order by transferring their asset and trading instructions through Consensys’s own smart contracts on the blockchain, which interface with third-party liquidity providers on the investor’s behalf. As is typically the case in traditional securities markets, the investor here never interacts directly with the third party; all investor interactions are directly with Consensys’s platform. And Consensys collects a fee on most transactions. [emphasis added]

You’ll notice that the SEC uses many of the key words from the broker test (or their synonyms), like “highlighting”, “curated”, “best”, “effect”, “routes”, “trading instructions”, “on the investor’s behalf”, “fee”, etc., and I've underlined all the active roles the SEC is alleging Consensys takes. It is night and day from the SEC’s allegations regarding Coinbase Wallet in terms of what the agency describes as the software provider’s role in making the swap.

For the remainder of this post, I drill down into some of the specific allegations the SEC is making and compare it to how the technology actually functions. I find that the SEC repeatedly aggrandizes Consensys’s role in users’ swaps, at odds with how the technology functions.

Smart Contracts

From the complaint:

MetaMask Swaps will . . . interface with a third-party liquidity provider that executes the investor’s order, thereby selling Crypto Asset A and acquiring Crypto Asset B on behalf of the investor . . . .

Accordingly, the Consensys software transfers Crypto Asset A to Consensys’s Spender.sol smart contract’s blockchain address. 

Consensys’s Spender.sol smart contract address temporarily holds the investor’s Crypto Asset A. . . . Consensys’s Spender.sol smart contract will interact with a number of Consensys-developed “Adapter” smart contracts.

Specifically, through the Adapter smart contract, the third-party liquidity provider will take Crypto Asset A from the Spender.sol smart contract address and place Crypto Asset B into the Spender.sol smart contract address. 

Consensys . . . facilitat[es] trading in crypto asset securities by . . . handling customer crypto asset securities through Consensys-operated smart contract addresses . . . .

As I detail below, my best guess for what the SEC is describing here is a user performing an atomic swap through smart contracts Consensys wrote, which, if true, would entail significantly less control of the swapping process by Consensys than the SEC is implying.

But before diving into that, a general comment:  I was struck by some of the slippery language the SEC uses here that glosses over how blockchains function, particularly “Consensys-operated smart contract” and “Consensys software transfers”. It is not clear what the SEC means by a “Consensys-operated smart contract”. While there is some admin functionality on the smart contract for a multi-sig that Consensys may control, there is no evidence to suggest the company actively operates the smart contract’s code. In fact, the whole point of smart contracts is that the code is run by a dispersed network that no one controls. And it is not “the Consensys software” that “transfers Crypto Asset A to Consensys’s Spender.sol smart contract[]”— it is the user who signs the transaction to authorize the transfer, not Consensys, and it is the blockchain protocol outside of the hands of Consensys that updates the state.

Okay, let’s return to the point on atomic swaps. To see what’s really going on, let’s look at the code of the MetaMask Swap Router smart contract. The key function is _swap() on MetaSwap.sol, which calls swap() on Spender.sol:

// MetaSwap.sol
    function _swap(
        string calldata aggregatorId,
        IERC20 tokenFrom,
        uint256 amount,
        bytes calldata data
    ) internal {
        Adapter storage adapter = adapters[aggregatorId];

        if (address(tokenFrom) != Constants.ETH) {
            tokenFrom.safeTransferFrom(msg.sender, address(spender), amount);
        }

        spender.swap{value: msg.value}(
            adapter.addr,
            abi.encodePacked(
                adapter.selector,
                abi.encode(msg.sender),
                adapter.data,
                data
            )
        );

        emit Swap(aggregatorId, msg.sender);
    }

// Spender.sol
	function swap(address adapter, bytes calldata data) external payable {
        require(msg.sender == metaswap, "FORBIDDEN");
        require(adapter != address(0), "ADAPTER_NOT_PROVIDED");
        _delegate(adapter, data, "ADAPTER_DELEGATECALL_FAILED");
    }

It is not the case that MetaMask Swaps performs a swap “on behalf of the investor”. The user must sign all transactions controlling her tokens, which Consensys cannot do on behalf of a user because it does not have access to the private key stored on the user’s device. And looking at the code, the swap() function is atomic—its job is to send tokens out and return tokens to the user in a single transaction. Even the flow of a user granting approval to Spender.sol prior to the swap and later calling swap() does not change this fact, because (1) the only function that transfers tokens is _swap() and (2) that function’s implementation ensures that the sender must be the owner of the tokens (tokenFrom.safeTransferFrom(msg.sender, address(spender), amount)). Assuming the adapters are not malicious (which would be another issue entirely), their job is to enable a user to perform an atomic swap—in a single transaction take token A and exchange it for token B. This would mean that transactions are "all or nothing"—either the tokens are swapped or they are not, they cannot end up in possession of the Spender.sol contract or Consensys as could be implied from phrases the SEC uses like the “Spender.sol smart contract address temporarily holds the investor’s” tokens, and tokens are “place[d] . . . into the Spender.sol smart contract address”, and “Consensys . . . handl[es] [tokens] through Consensys-operated smart contract addresses”. 

Slippage

From the complaint:

(Setting a slippage tolerance effectively creates a “limit order,” which is an extremely common type of order offered by traditional brokers.) 

Slippage is not “effectively” the same thing as a traditional limit order, and conflating these things implies more active management for Consensys over users’ orders than occurs in reality. 

Here's the key difference: in a traditional limit order, one party tells another party a condition of when a transaction should be executed in the first instance, whereas slippage involves a smart contract running a check when a transaction is executed. This leads to a very different result from a control standpoint because the traditional limit order generally involves trusting another party to watch markets and only submit an order when the condition is met. Slippage, on the other hand, does not involve active management by any third party. Instead, with slippage, the user sets a minimum amount of the token she wants to receive and executes the transaction, with the smart contract (running autonomously) checking that the minimum back is in fact received, else the transaction will fail. 

Put simply, slippage is an emergency break the user sets to protect herself while a traditional limit order is an instruction for when another party should execute an order on behalf of the user. The latter has the intermediation associated with broker activity, while the former does not.

Private Key Storage and Retrieval

From the complaint:

[T]he Consensys software reads the investor’s private key from the MetaMask Wallet. This is the digital password that cryptographically unlocks Crypto Asset A so that it can be transferred out of the investor’s MetaMask Wallet.

To place an order through MetaMask Swaps, the investor does not need to know or enter their private key (the cryptographic “passcode” that is necessary to transfer Crypto Asset A out of their wallet).

First, it’s not clear what the SEC means when it says that the “Consensys software reads the investor’s private key from MetaMask Wallet”. What is the “Consensys software” here?  I would have thought it was the MetaMask Wallet, which the SEC defines as “a Consensys-developed software application for storing investors’ crypto assets”, but read that way, the sentence does not make sense. If the SEC is trying to say that other Consensys software besides the wallet application ever touches the private key, then that is plainly wrong. To be crystal clear, “MetaMask generates passwords and keys on your device”, not in the software application itself, so even saying the private key is read “from MetaMask Wallet” is not really accurate. Rather, MetaMask Wallet requests the private key from storage on the device. 

But the real thing I want to focus on here is the insinuation that the retrieval of private keys via a wallet application somehow implicates brokerage activity. It does not. Everyday we interact on the internet and, to make it usable, we utilize software to abstract away cumbersome technical points. Think about all of the things Chrome does behind the scenes to make your experience usable. Chrome stores your passwords locally so you don’t have to enter them every single time you visit a site, engages in the TLS protocol behind the scenes to ensure private transfer of data over the wire, etc. Does this mean Google, via Chrome, acts as a broker when the user utilizes these features to trade on Fidelity.com?  Of course not. The same consideration applies here with wallet software developers.

The fact that the SEC is citing software abstracting away the nitty-gritty of interacting on the internet as evidence of control is a scary insinuation that goes far beyond crypto.

RPC Nodes

From the complaint:

[T]he Consensys software submits a blockchain transaction to a Consensys-operated and controlled remote procedure call or “RPC” node. The RPC node stores the blockchain transaction in a mempool (a collection of proposed transactions that are in a queue) until it is included in a block and executed, as per the steps below. More specifically, the Consensys software creates, signs (using the investor’s private key), and submits this blockchain transaction to Consensys’s RPC node, which when executed will transfer the specified amount of Crypto Asset A from the investor’s wallet address to a Consensys-developed smart contract called “Spender.sol.”

Consensys . . . facilitat[ed] order execution by submitting blockchain transactions to a Consensys node . . . .

Here, the SEC is describing what I presume is a vanilla RPC Ethereum node but by labeling it "Consensys-operated and controlled", it could be read to suggest that Consensys is doing something special beyond simply participating in the Ethereum blockchain protocol. It has no bearing that Consensys submits transactions to a node it runs—Consensys could submit them to any RPC node it wants and get the same result.

Wallet Account "Creation"

From the complaint:

Consensys . . . facilitat[ed] trading in crypto asset securities by creating customer wallets (i.e., “accounts”) . . . .

This allegation is a repeat of one the SEC made in Coinbase, and as debunked in the DEF brief, this is not faithful to what it means to establish a wallet:

A blockchain has no notion of “open” versus “closed” “accounts,” or which private keys have been selected for use. A simple way to see why this is true is that it is perfectly valid to transfer crypto assets on a blockchain to a public key that no one has ever attempted to derive from a private key; the assets would simply be unobtainable until and unless someone randomly selects the private key associated with that public key. All wallets on a blockchain already exist, and users choose which one is theirs by selecting a random number (a private key). No one, including the developer of any wallet application, authorizes or manages this process; it depends entirely on the fact that, for all practical purposes, no two users will ever pick the same number. There is no checking or approval process, no “approved” versus “not approved” “accounts” or “list” being checked to make sure the user has registered. After a user selects a random number (a private key), she can immediately begin transacting on a blockchain using digital signatures. Therefore, there is nothing Coinbase or Wallet actively does to “open” an “account” because there is no “account” in the way the SEC alleges.

I’m surprised the SEC repeated this allegation with effectively no change from Coinbase, given how detached from the technical reality it is.

From a pleading standpoint, the SEC’s complaint in Consensys does a better job of trying to incorporate the broker test factors, which I think makes it a stronger complaint than Coinbase. However, careful attention to these allegations is still needed to ensure that they are precise about the role Consensys has over users’ swaps. Upon close inspection, the SEC either exaggerates or gets key elements of how the technology functions wrong. This puts into serious question the strength of their charge that Consensys, through MetaMask, acts as a broker.

This post is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. Thus, this post should not be construed as legal advice for any particular facts or circumstances and is not meant to replace competent counsel. It is strongly advised for you to contact reputable legal counsel in your jurisdiction for any questions or concerns. None of the opinions or positions provided in this post are intended to be treated as legal advice or to create an attorney-client relationship. No reader, user, or browser of this site should act or refrain from acting on the basis of information on this site. This analysis might not reflect all current updates to applicable laws or interpretive guidance, and the author disclaims any obligation to update this post. All liability with respect to actions taken or not taken based on the contents of this site are hereby expressly disclaimed. The content on this posting is provided "as is;" no representations are made that the content is error-free.