Untangling the Uniswap Case

We dissect the landmark Uniswap ruling by diving into Uniswap's architecture. We also share our structuring recommendations for projects from our reading of Uniswap.

Introduction

The SDNY ruling in Risley v Universal Navigation Inc. (the “Uniswap Ruling”) is positive for DeFi devs and protocols because it shows how a “tech-informed” approach can result in sensible yet strange legal outcomes. [1]

While it has limited value as precedent, the Uniswap Ruling:

1. Helps us understand how courts might approach litigation involving decentralized protocols.

2. Demonstrates how on-chain intermediary-less products are square pegs when it comes to the round holes of 20^th century TradFi laws. 

One of the core issues was whether the Uniswap platform is a rogue securities exchange or broker-dealer (“BD”) operating without a license. The judge (Katherine Failla - she is now deciding Coinbase v SEC, and a celebrity in the cryptolaw world) craftily handed a big W to Uniswap Labs and the DeFi space at large - but without making a decision about this core issue. 

Because of the legal gymnastics used to reach this result, the Uniswap Ruling is a confusing read - let’s try to untangle it.

Facts & TL;DR

A group of shitcoin issuers (the “Shitcoin Issuers”) created their own shitcoin and used Uniswap to create a liquidity pool for their shitcoin on Uniswap v2 (“Uniswap”). 

Retail investors (the “Tradoors”) bought these shitcoins from this liquidity pool, and they subsequently got rugged (i.e. the Shitcoin Issuers pulled ETH liquidity out from the liquidity pool driving the price of the shitcoin to zero, leaving the Tradoors with worthless tokens while profiting themselves). [2]

Because the blockchain itself is pseudo-anonymous, and because Uniswap’s underlying protocol has permissionless access and does not KYC users for creating liquidity pools or trading, the identities of the Shitcoin Issuers were unknown and unknowable. This made it virtually impossible for the Tradoors to identify a defendant for their claims. 

The Tradoors went after Universal Navigation Inc. (“Uniswap Labs”), Uniswap Foundation, Hayden Adams (founder of Uniswap Labs) and VCs that backed Uniswap Labs (together, the “Uniswap Defendants”), for creating and marketing the Uniswap platform which caused them harm. 

The punchline summary of the Uniswap Ruling is: the court decided that the Tradoors were harmed by the Shitcoin Issuers who used the Uniswap smart contracts to carry out their rugpull. Just because the Uniswap Defendants created the protocol which the Shitcoin Issuers used to carry out their scheme, the Uniswap Defendants could not be liable for the fraud and resulting harm, specifically under US securities laws. 

Claims & Reactions

The Tradoors asked for their trades to be reversed using two legal arguments – mapped below to the court’s reactions.

Whose Smart Contract Is It Anyway?

The second argument and reaction are interesting. Let’s unpack the architecture of Uniswap’s smart contract system (the “Protocol”). The Protocol is an automated liquidity protocol powered by a constant product formula and implemented in a system of non-upgradeable smart contracts. [4]

1. There are  “Core” contracts, which compose trades & liquidity for users via the singleton “Factory” and the many “Pair” contracts, to create and index liquidity pools made up of reserves of ERC-20 tokens and facilitate trading between the pair.  The Factory contract holds the bytecode responsible for creating token pairs and its logic includes creating one and only one smart contract per unique token pair. The Pair contracts have two primary purposes: (a) serving as automated market makers to facilitate trading of the pair; and (b) keeping track of token balances in a certain pair’s liquidity pool.

2. There are “Periphery” contracts, comprising the “Router” and “Library” contracts. The Periphery is a group of smart contracts that help with specific interactions with the Core contracts. The more important Router contract uses the Library contracts to support all the basic requirements of a front-end offering trading and liquidity management functionality. Notably, the Router contract also offers the redemption mechanism to the liquidity pool token holders (in this case the Shitcoin Issuers who hold title to their share of the tokens in the pool), allowing them to remove their share of liquidity (and accrued fees) from the pool at their discretion.

How is this foundational layer used in practice?

1. The Shitcoin Issuers created the shitcoin and used the Factory and Pair smart contracts to whip up their shitcoin’s liquidity pool comprising their shitcoin & ETH. They provided liquidity to this pool by depositing equal value of each token in the pair (since the shitcoins are worthless at the time of issuance, they can effectively set the market price). In exchange, they receive special liquidity pool tokens (“LP Tokens”) in ERC-20 format (these represent their share of the liquidity pool's total token reserves), which they can exchange back for the original assets anytime. 

2. When a Tradoor wants to do a trade in the shitcoin’s liquidity pool, he would interact with the  Core contract, which makes a call to the Pair contract of the shitcoin’s liquidity pool (which is in turn responsible for holding & trading the shitcoin-ETH pair). The previous trading activity sets the relative prices of the assets in the liquidity  pool, establishing a new market rate based on the x*y = k constant formula. To facilitate this trade, the Router contract is used to compute the amount to be paid/deposited by the Tradoor and to manage the transfer of tokens accordingly.

3. When a trade is executed, the Tradoors will approve the asset they wish to trade via the Core contract before calling the Swap() function in the Router contract, which will swap their token for the other token in the liquidity pool of the respective Pair contract, based on the above formula. As more traders buy the shitcoin, the relative supply of ETH in the liquidity pool increases and the shitcoin decreases, driving the price of the shitcoin up.

4. A 0.3% fee is charged on all trades of the liquidity pool and this fee is distributed to liquidity providers (here the Shitcoin Issuers), as their reward for providing liquidity to the pool. Liquidity providers (here the Shitcoin Issuers) can collect their share of the fees by 'burning' their LP Tokens using the Router contract’s redemption feature for the LP tokens, i.e. the removeLiquidity()function, which removes liquidity from an ERC-20⇄ERC-20 pool, returning the LP Tokens to the pool to withdraw their share of the accumulated reserves and fees, thereby rugging the pool of all liquidity and leaving the Tradoors with worthless shitcoins. Note that the Shitcoin Issuers have the option to collect only their fees without removing liquidity from the entire pool (but their objective was to do a rugpull).

In this architecture, the functional distinction between Uniswap Defendants’ role and the Shitcoin Issuers’ roles are:

1. The Protocol’s  smart contracts are created by the Uniswap team, and they provide the basic functions used by all issuers, liquidity providers and traders who interact with the Protocol, whereas the shitcoin’s Token Smart Contracts are developed by third party token issuers (such as the Shitcoin Issuers); the Shitcoin Issuers also created a liquidity pool for the shitcoin using the Protocol’s smart contracts which primarily acted as a liquidity pool vending machine.

2. The Core contracts are immutable (i.e., they are non-upgradeable), whereas the Token Smart Contract specific to the shitcoin is mutable (i.e. can be modified by the Shitcoin Issuers at their discretion - including setting parameters such as a sell tax, restricting transfers etc.) 

3. Calling the removeLiquidity() function is at the discretion of the Shitcoin Issuer (since they deployed the liquidity pool & seeded it with the assets), not the Uniswap Defendants. Per the logic of the Factory contract, each liquidity pool is unique to a specific pair of tokens, meaning no two pools can have the same pair. Naturally, the Shitcoin Issuers are responsible for rugging liquidity from the shitcoin’s liquidity pool since they (and not the Uniswap Defendants) virtually controlled all or most of the LP Tokens in the shitcoin’s liquidity pool.

As a result, the Uniswap Defendants are only responsible for creating the Protocol (and in our view, cannot be treated as intermediaries to the trade), whereas the Shitcoin Issuers are responsible for:

1. Creating theshitcoin’s Token Smart Contract.

2. Utilizing the Factory and Pair contracts to create the shitcoin’s liquidity pool. 

3. Utilizing the Router contract and calling the removeLiquidity() function to remove liquidity at the time of the rugpull. 

Uniswap also has a third significant component: the front-end interface (the “Interface”) which is owned and operated by Uniswap Labs, and is the primary  avenue for interacting with the Protocol to trade and manage liquidity pools (albeit the open-source, accessible nature of the Protocol means that there are countless UX access-points and front-ends to access the Protocol’s functionality, including, wallets, DEX aggregators, block explorers, and other tools built by the DeFi community). The operation of the Interface is a source of major regulatory discussions around the future of DeFi (a topic for another day).

We can now step back and see Uniswap’s layered architecture:  

1. The Protocol is a foundational, immutable layer created by the Uniswap developers. It enables a multitude of mutable, user-created token marketplaces and front-end interfaces, including Uniswap by Uniswap Labs. 

2. The Protocol exists independently on the Ethereum blockchain. It is a self-contained system that doesn't change, signifying its permanence and autonomy. The Interface is a means for users to interact with the Protocol. It merely functions as a gateway, allowing users to access and use the Protocol. 

3. While Uniswap Labs, the entity managing the Interface, has the ability to restrict a user's access to a particular token through the Interface, this control is limited. If a user's access to a token is restricted on the Interface, the user can still find alternative ways to access and trade that token using the Protocol.

Peeling the Onion

The court made some important findings based on Uniswap’s layered architecture.

1. The court essentially recognized that developers have the freedom to create software intended for legal use, without facing liability for the small number of users who might misuse it for illegal activities. It analogized the Tradoors’ claim to “attempting to hold…Venmo or Zelle liable for a drug deal that used the platform to facilitate a fund transfer”, and felt the Tradoors were  trying to hold a developer of self-driving cars liable for a third party’s use of the car to commit a traffic violation, or to rob a bank. 

2. The court correctly saw the Core and Periphery smart contracts as an overarching user agreement for accessing a P2P trading platform, based on the fixed formula and immutable contracts permitting trading of user-issued coins on the Protocol.

3. The court then hardened the analogy into a legal conclusion – it stated: “it defies logic that a drafter of computer code underlying a particular software platform could be liable under relevant US securities law allowing contract reversal, for a third-party’s misuse of that platform”. 

4. The court felt that the Uniswap Defendants only designed a facilitative platform which could be used by third parties for “perfectly legal things like buying commodities like $ETH (bullish!)”, as well as illegal things like trading in unregistered securities or shitcoins and other presumably fraudulent activities such as rugging liquidity. 

Accordingly, the court concluded the Shitcoin Issuers were responsible for the alleged unlicensed securities issuance, enabling trading and subsequent rugging - not the Uniswap Defendants. 

Characterizing Uniswap

The court effectively characterized the Uniswap Defendants as providers of a software that enabled P2P token trading (as opposed to themselves conducting trades). This highlights the court’s understanding of the “decentralized” nature of the Protocol, where control and usage isn't centralized, and users have multiple avenues to engage with the Protocol at their discretion.

The court should have also concluded that because of this very attribute (#decentralization), the Protocol itself was not subject to licensing as a securities exchange/BD - see table below.

Because the court did not take this final step, we are left with a strange outcome.

Let’s consider that the Protocol is possibly an exchange/BD and should be licensed. Even if it were licensed, applying Judge Failla’s logic, retail has no remedy against the Uniswap Defendants. Retail only has remedies against the Shitcoin Issuers. In addition, even if there was a reversal order,  transactions conducted on Uniswap cannot comply with securities laws since they are not reversible, due to the design of the blockchain. 

Retail’s remedies are therefore toothless. This makes a mockery of the laws that put unlicensed securities exchange operators or BDs (who act as intermediaries), on the hook for harm caused to retail. It demonstrates how existing TradFi laws are largely unfit to deal with decentralized & intermediary-less protocols - the policy chants of “same activity, same risk, same regulations” squarely does not apply. 

Uniswap Labs is aware of this, and seems to be treading carefully. 

1. It delisted some tokens from the Interface (but not from the Protocol itself – this would have been impossible since the protocol is immutable) due to regulatory concerns in 2021, and it’s possible that the Interface will increasingly apply such filters to steer clear of liability (it is after all the most visible target). 

2. It has also started a fund to educate regulators, run policy efforts and defend itself from claims like the one made by the Tradoors [5]. 

3. It has articulated a strong case that Uniswap is not an unlicensed exchange or BD [6].

It is telling that the SEC (which is not known for shying away from an ill-advised brawl) has not yet unveiled any enforcement actions against Uniswap Labs, though the SEC’s exact litigation strategy in this regard is unclear to practitioners.[7] 

Recommendations

How should the Uniswap Ruling influence the design of governance frameworks for other DeFi protocols?

1. If the protocol is upgradeable, the control of deployment/upgrade keys by a set of developers could reflect a level of centralization, possibly impacting the legal analysis of the protocol's disintermediated nature. Future protocols should consider distributed control mechanisms or token-based voting mechanisms to upgrade the code-base to mitigate centralization risks associated with key management and protocol upgradeability.

2. If certain offchain tech components of DeFi are served via offchain or centralized services or   providers which require certain trust assumptions, it could also reflect a level of centralization, influencing both the perception and legal standing of its underlying protocol. Protocols should explore decentralized alternatives or clarify and add disclaimers to the extent and implications of centralized components within their systems (e.g. front-end management, wallet/key management, order routers, execution clients, off-chain computation etc.).

3. The judgment highlights the legal risks associated with the sale of tokens on decentralized platforms, especially when they are alleged to be shitcoins. It could prompt developers and governance entities to be more cautious and proactive in managing legal risks, possibly by implementing mechanisms to prevent or mitigate the sale of shitcoins on their protocols or from their protocol’s front-end - including warnings & disclosures, especially when end-users trade on newly created liquidity pools.

4. Taking a cue from Uniswap’s model, DeFi protocols should try to ensure that they don’t take custody of user funds & tokens and act in the capacity of intermediaries (i.e. don’t be a DINO), and that they can defensibly argue that they are merely facilitative software.

5. The difficulties faced by the court in identifying responsible parties due to the decentralized nature of Uniswap encourages DeFi protocols to clarify their governance structures. This could include clear delineation of roles, responsibilities, and decision-making processes within the protocol, making it easier to determine accountability in the event of legal disputes and to provide clear information to users and regulators. If protocol governance is dominated by a limited set of affiliated whales, it could potentially skew decision-making and contradict claims of decentralization. DeFi protocols should consider implementing mechanisms to ensure broader community participation and prevent undue influence by a select few (or through their proxies). This can also have a positive legal effect on the ‘decentralization’ test - although this question was not addressed in the Uniswap Ruling. 

6. The case might stimulate the development and adoption of on-chain governance mechanisms that enable community-driven decision-making and reduce centralized control. On-chain governance can provide a transparent and auditable trail of decisions and actions taken within the protocol, which could be beneficial in the legal and regulatory context.

Epilogue

We also found the Uniswap Ruling interesting because:

1. This case was not really about decentralization per se (i.e., it only analyzed decentralization from a technological standpoint). We don’t think there would have been a huge difference to the outcome if Uniswap Labs, Uniswap Foundation, and $UNI holders were extremely centralized. The case did not turn on whether the smart contracts could be upgraded (see ‘Uniswap Fee Switch’ discussion to learn more), who held the majority of $UNI and Uniswap equity, how protocol vs. community vs. corporate governance works, etc. This case was more about Uniswap’s architecture as a permissionless and P2P self-serve platform which could be used by pretty much anyone to build a disintermediated trading function.  

2. The court did not give decentralized projects a blanket cover for illegal activities carried out by third parties. The ruling was actually very specific to the words of the relevant US security law which allows contracts to be “reversed” in favour of retail who get harmed when trading on/with unlicensed players. The court gave Uniswap a version of the “platform level” protection Youtube or X enjoys whenever a user posts third-party IP infringing content (under intermediary liability safe harbour laws like the DMCA), but only in the context of some securities laws claims. 

Reflecting on the Uniswap Ruling, several thoughts emerge:

1. We must recognize decentralization as a continuum rather than a binary state (centralized or decentralized). This means examining the degree of decentralization, assessing aspects like control over code modifications, decision-making processes, and the distribution of tokens or assets. The ruling would have been stronger if it undertook a deeper exploration of where on the decentralization continuum Uniswap and similar protocols fall.

2. Even in the absence of a clear concentration of power, analyzing governance structures and the powers to alter code could unveil potential areas of liability or responsibility. This calls for a deep dive into who has the authority to make changes within the protocol, how these changes are proposed and approved, and the implications of these governance mechanisms on users and other stakeholders.

3. There are substantial gaps in the current legal framework governing DeFi and the broader crypto space. Industry players have long been aware of these legal shortcomings. To effectively address these gaps requires legislative (not enforcement-driven) action from a law-maker, as these issues are beyond the scope of what existing laws can comprehend, let alone conclude on. Denying or overlooking this need for legislative action is intellectually dishonest.

The Uniswap Ruling is a big win for DeFi - particularly the recognition of its technology stack as credibly neutral if the protocol design & logic optimize against centralization vectors. 

That said, the Uniswap Ruling is tightly written and narrow. It does not signal similar legal outcomes for other DeFi projects in other arenas, unless other judges decide to follow Judge Failla’s approach to publishers of “facilitative” software and emulate her careful parsing of the underlying tech.

The SEC has attacked CEXs (see: the SEC’s litigations against Binance and Coinbase), and the CTFC has been attacking DEXs [8]. In this fog of war, the Uniswap Ruling shows how unsuited and ill-equipped existing TradFi laws are for dealing with DeFi.  

It’s an encouraging sign that US courts are making principled and sensible decisions based on a restrained reading of US laws, not simply trying to expand the regulatory net. Judge Failla also showed a sophisticated and “tech-informed” approach by first understanding how Uniswap works and then trying to figure whether operative parts of TradFi laws applied or not. 

We hope US judges continue to follow this approach, and that US regulators take their cue from such US judges.

---

Notes:

[1] https://law.justia.com/cases/federal/district-courts/new-york/nysdce/1:2022cv02780/577791/90/ 

[2] https://koinly.io/blog/crypto-rug-pulls-guide/

[3] https://twitter.com/Orlando_btc/status/1696900805285093402?s=20 

[4] https://docs.uniswap.org/contracts/v2/concepts/protocol-overview/smart-contracts 

[5] https://gov.uniswap.org/t/governance-proposal-005-defi-education-fund/12963

[6] https://www.sec.gov/comments/s7-02-22/s70222-204699-411503.pdf

[7]https://x.com/milesjennings/status/1749899452058665276?s=20; https://twitter.com/RSSH273/status/1749919709792022538

[8] https://hashedhodl.substack.com/p/what-awaits-defi-peering-through