Lifting the Cryptographic Veil: The SEC’s BarnBridge Enforcement

We analyze the SEC's enforcement against the BarnBridge DAO and its founders, and discuss the regulatory risks for on-chain lending protocols.

The SEC’s settlement with BarnBridge and its founders highlights the US regulatory risk for on-chain lending protocols.

The SEC’s position on BarnBridge (though poorly articulated) can have serious ramifications since on-chain lending is a significant part of the crypto economy. 

[Note: I am saying “lending”, but the (ostensibly) regulated activity here is not lending by a protocol, it is lending into a protocol by users (i.e., liquidity providers or LPs), and the protocol’s management of the LPs’ funds. The protocol is not “borrowing” in the TradFi sense.]

To be clear, the SEC has attacked CeFi lending plays before - for example, it strangled Coinbase’s Lend program in its cradle, and it has attacked BlockFi and Gemini Earn (and arguably won against both). The BarnBridge enforcement is interesting because the SEC has inched closer to “true” DeFi lending (think Compound).

Let’s begin by describing the BarnBridge protocol: LPs can get a fixed rate of interest when they deposit funds into the protocol, but the LPs’ funds are interestingly collateralized. 

1. LPs deposit funds into a liquidity pool. The protocol’s smart contracts then invest the funds into Aave, Compound, Curve etc. LPs receive LP tokens in exchange. Through these LP tokens, LPs receive principal and a fixed interest. 

2. By seeding the first liquidity pool themselves, and timing the raising of the second liquidity pool in a way that the yield from the first liquidity pool is available for distribution, BarnBridge ensured that every successive liquidity pool was almost fully de-risked for LPs. So for example, funds to repay the principal and fixed interest of the third liquidity pool were available at the time the third liquidity pool was being seeded because by that time, the second liquidity pool had matured.

[Note: LPs could also get a variable interest rate on their deposits, but to keep it simple we will only consider BarnBridge’s “fixed income” product.]

The SEC looked at this structure and made two allegations. 

1. The LP tokens looked like “notes” (i.e., debt securities) which cannot be sold in the US without registration etc., and

2. The liquidity pools were “investment companies” (investment companies are “any issuer which is engaged or proposes to engage in the business of investing, reinvesting, owning, holding or trading in securities, and owns or proposes to acquire investment securities having a value exceeding 40 per centum of the value of such issuer’s total assets…”; for context, this is the same regulatory bucket that US-based mutual funds fall into). Running “investment companies” is subject to SEC licensing, regulation etc.

The SEC’s position seems to be: if it sees a TradFi investment vehicle clothed in smart contracts, it will “lift the cryptographic veil” and characterize the vehicle using TradFi investment regulation - regardless of how trustless the protocol is - and enforcements will follow accordingly. 

BarnBridge was likely a low-hanging fruit for the SEC: the protocol’s DAO was basically controlled by the founders; the founders hired coders on the DAO’s behalf to create, audit, and maintain the protocol; the protocol was not immutable; BarnBridge did not KYC or geo-block US users; its LP tokens were marketed to retail in a way that suggested a TradFi investment product; and USD 509M of users funds were deployed in BarnBridge - a substantial sum by any account. 

In the absence of an adequately reasoned SEC order, there is little guidance for the industry. To plug this gap, I attempt to flag situations in which the SEC’s stance (that LP tokens are “notes” and that liquidity pools are “investment companies”) is incorrect.

The Howey analogue for securities with debt features is Reves. An article by Latham & Watkins suggests that Reves is inapplicable when there is no “seller” of the notes in the traditional sense (since LP tokens are issued by a protocol, not a company, trust etc.). A paper by Carol Goforth also suggests the same argument. Why so? They argue: Reves characterizes a debt obligation as a “note” in order to protect buyers in buyer-seller relationships which involve credit risk, principal-agent risk and information asymmetry risk. It follows that if there is no buyer-seller relationship when a protocol issues LP tokens, the attendant risks don’t exist, and then treating LP tokens as “notes” is wrong. 

Building out the above arguments: these risks are (largely) absent when an LP deposits crypto-assets for lending into a liquidity pool (especially overcollateralized ones). How so? Let’s assume the protocol is largely immutable (i.e., the protocol’s smart contracts cannot be changed to alter economic outcomes of participants). If this were the case, the outcome for LPs is deterministic i.e., it is guaranteed by cryptographic promises which cannot be broken even if the counterparty wanted to break the promise - as opposed to promises of human or corporate conduct that actually can be broken by counterparties and thus need to be enforced through courts. 

To illustrate how this is different from TradFi note issuances: when you buy notes issued by a company, you assume credit risk. What if the company goes bankrupt; or the cycle turns against the company, business slows down, and it starts seeking extensions? Lenders must go to court to enforce their security interest and/or recover the debt. However, when you deposit crypto-assets into a liquidity pool, by doing due diligence on the protocol’s smart contracts, you are assured that the promised outcome will happen, and thus there is no need to go to a court to enforce your rights. Similarly, to help buyers understand the one-time and ongoing credit risk, an issuer of notes is typically required to make one-time and ongoing disclosures to the buyers. In contrast, for on-chain lending protocols, there is nothing substantial to disclose beyond the code (which is fully disclosed anyway). 

Of course, viewed from a broader policy lens, I have oversimplified the risks for LPs in liquidity pools. For example, there is risk that the liquidation engine will not work correctly if it is based on off-chain oracles; there is hacking risk; and there is credit risk stemming from the underlying debt represented by the LP tokens. If you work backwards from IOSCO’s recommendation that liability in DeFi arrangements should be pinned on “those exercising control or sufficient influence” over the protocol, then since developers/founders often exercise such control/influence, a principal-agent risk exists for LPs as well. 

Nonetheless, the key legal argument here is that absent TradFi-esque credit risk, principal-agent risk and information asymmetry risk, it is inappropriate to use Reves to characterize LP tokens issued by on-chain lending protocols as notes. 

An open question is: since Reves is a “live” attack vector, how will courts interpret Reves when applied to LP tokens issued by on-chain lending protocols with a more DeFi flavor? I argue such LP tokens are not notes under the Reves test since at least two of the four “factors” outlined in Reves do not exist.

1. Reves itself says that: “If some factor reduces the risk of investment, like an alternative regulatory scheme or underlying collateral, such that application of the securities laws is unnecessary, the instrument may not be a [note]”, which is exactly what is happening in some on-chain lending protocols (see above on how immutable smart contracts reduce risk for lenders). 

2. Similarly, Reves requires the issuer to have issued the notes for financing the issuer’s business. But this is not how on-chain lending protocols work - the LP token is issued by the protocol (and not the borrower who will use the borrowed funds). Take the example of a liquidity pool in Compound: there is no direct relationship between the lender and the borrower (whether contractual or otherwise). It is similar to the relationship between a nurse who deposits her salary in her bank account, and an SPV that owns a power plant and has raised project finance from the same bank - in other words, no relationship at all, even though the bank may have extended the project finance loan by tapping into its deposit base (money is fungible etc).

The corollary - that where a protocol’s design exhibits credit risk, principal-agent risk and information asymmetry risk, Reves should apply - has been clearly signaled by the SEC. The SEC has successfully used the Reves attack vector against CeFi lending plays. Their fact patterns yield (pun intended) valuable insights on what to avoid when designing on-chain lending protocols. 

1. Gemini Earn. Gemini borrowed crypto-assets from users, and its revenue came from the spread between the interest paid to users for their crypto-asset deposits and the interest at which it lent out these crypto-assets on a discretionary basis (i.e., investors were investing in a “blind pool”). The interest rate was variable and Gemini’s lenders could recall their loans at any time. Gemini’s sins were: marketing to retail as an investment product; running a classic CeFi operation (thus exposing investors to the entire gamut of TradFi risks); raising a huge sum of money through these loan agreements; and lastly, going bust. In a preliminary ruling, a court found that Gemini Earn’s LP token was a “security” under the Reves test. The fact that Gemini earned revenue from the lending activity was highlighted. This seemed like a slam dunk for the SEC. 

2. BlockFi. BlockFi’s offering was not materially different from Gemini Earn. The SEC alleged that BlockFi had issued notes which qualify as “securities” under the Reves test and that BlockFi was an investment company. BlockFi settled with the SEC and is paying a hefty fine. 

3. Coinbase Lend. There are less details available, but in essence it was again not too different from the Gemini Earn structure (the major difference being that the interest rate was fixed and not variable). When Coinbase began testing this program, the SEC sent them a legal notice (warning them that the Reves test would be applied to the scheme). Coinbase canceled the launch. Experts believed that it would not have been a difficult case for the SEC to win. 

   
   To be sure, Coinbase has been extremely litigious against the SEC on other issues so the fact that they backed down on this product may signal a lack of conviction in their own Reves analysis. In fairness, it also could have been a business call to avoid getting embroiled with the SEC on another front at that time (and providing debt-like yield is not “core” for Coinbase in the way that being an exchange is).

The market seems to believe that there is a spectrum where CeFi lending carries higher regulatory risk, but more DeFi-esque lending seems to have less regulatory risk. 

Somewhere in the middle of the spectrum, where the developers/founders have discretion to manage the assets in liquidity pools, there is a spike in regulatory risk since the activity becomes similar to running a mutual fund that invests in corporate bonds. There is an added dimension of credit risk for LPs if the liquidity pool invests into products which themselves carry credit risk.

What if the protocol’s discretion to manage funds in the liquidity pool is minimized by using smart contracts? This now brings us to the class of on-chain lending protocols where LPs deposit crypto-assets into a liquidity pool, and the liquidity pool programmatically uses these crypto-assets and DeFi’s “money legos” to invest in other sources of on-chain yield (which seemed to be the case in BarnBridge). Regulatory risk for these projects is amplified post the SEC’s BarnBridge settlement. 

But is it justified to characterize such liquidity pools as “investment companies”?

1. Conceptually, a liquidity pool is very unlike a pooled investment vehicle which issues securities to collect monies and invest in other securities. In ideal cases, a liquidity pool is “user generated”, i.e., it does not come into existence until users interact with the code published by the developer. When users begin interacting by depositing crypto-assets (the LP side), the liquidity pool becomes “live” and operates as per the rules baked into its code (with no discretion left to the developer on what the pool should invest in). 

   This opens up a space to argue that developers should not be liable for activities of liquidity pools launched and operated by users. Regulation of “investment companies” exists to mitigate the principal-agent risk and information asymmetry risk that arises when money managers raise funds in “blind pool” vehicles. If the project’s developers do not have any discretion to manage the crypto-assets in the liquidity pool, these risks are (largely) non-existent. Due to the absence of these risks, there is a stronger case to be made that “investment companies” regulation shouldn’t apply. 

   This structuring lends itself to an argument that there are no “responsible persons” for a DeFi arrangement, and thus using the IOSCO’s own yardstick, the developers are not liable to regulators.

   
   For an example, of a “no discretion” pool, see here and here for Index Coop’s icETH pool (LPs deposit ETH, which is programmatically used to deposit stETH as collateral in Aave to borrow more ETH and repeat the cycle until a certain level of leverage is received; LPs receive staking yields). For an example on the other end of the spectrum, see here for Laser Digital’s regulated offering to institutional investors for staking & liquid staking yields from the Polygon L2’s $MATIC token.

2. There is also an argument that an “investment company” must be an “issuer” (technically speaking from a reading of the law), and that the “issuer” must be a person, and since a smart contract is not a person in the legal sense, it cannot be an “issuer”. 

   An article by K&L Gates noted, while SEC has recognized atypically structured actors as “investment companies” in the past, “individual [liquidity] pools in DeFi protocols (which themselves are generally mere software code) are not typically viewed as entities by the industry, much less as statutory investment companies”. As the DeFi Education Fund noted, the BarnBridge settlement was the first time the SEC had called a smart contract an “issuer”. Again, there is space to argue that the law never intended to brand an immutable protocol with low/zero trust assumptions as an “issuer”. 

My take is that being a bad faith actor, the SEC will first want to pin the liability for the smart contract’s activity on the project team, and aggressively look to “lift the cryptographic veil”. Force fitting economic realities into legal definitions to achieve this outcome will happen later on, and possibly only at settlement negotiations when developers/founders have little leverage to push back.

Let’s take a quick sample of how other on-chain lending protocols function. 

Some well-known projects are purely tech providers, offering permissioning capabilities to borrowers, and thus implicitly encouraging borrowers to use the permissioning functionality to mitigate US securities law risk. 

For example, Maple Finance provides tech for setting up “managed” liquidity pools where the user leg of the lending is done on-chain and the funds are increasingly invested off-chain (i.e., into real world assets). These products are offered under the Regulation S exemption to US securities laws (meaning that US residents cannot lend to these liquidity pools - see an example here). When offered to US investors, Maple Finance is careful to ensure that the “pool manager” uses an exemption from US registration requirements (see here). 

TrueFi follows a similar model (but seems to be less permissioned and bills itself as “infrastructure for on-chain credit”). Similarly, Morpho provides a neutral protocol on top of which liquidity pools can be built permissionlessly. Euler Finance is also in the same category. 

In the above cases, regulatory risk is shifted to the manager of the liquidity pool. 

On the other hand, Compound, Notional Finance, Curve and Pendle are permissionless (and therefore borrowers and lenders can be US persons) but the developers/founders do not (nor do any professional managers) manage the funds in liquidity pools, with the economics of the liquidity pools being dictated by automated market makers (i.e., code). The protocol’s DAO has a limited role (in the asset management sense) in these protocols.

The SEC’s BarnBridge settlement is a clear signal to product counsel and deal teams: pay close attention to how an on-chain lending project is structured since Reves and “investment company” regulation are now in play. 

While the obvious answer for projects seeking to mitigate US regulatory risk is to geo-block US users, this is not always commercially feasible. For projects with the risk appetite to find a middle path (if such a middle path even exists), structuring carefully (based on the blurry “do’s and don’ts” emerging from SEC settlements) might provide some comfort. 

Projects should ideally be able to demonstrate credible immutability of the protocol they have developed (and thus a credible separation between themselves and the borrowing/lending activity). To “borrow” a phrase from corporate doctrine (pun intended), regulators should not be able to make the case that the labs entity is sitting behind the liquidity pool as the liquidity pool’s “alter ego”.