If you are a student in blockchain and want to come to @MBC_Conference dm me asap! We can support you with a $200 subsidy regardless of the university.
10 days out.
The plainly worded TLDR of "Transaction Execution on Ethereum Decentralized Exchanges (DEX) From a Legal Perspective" by @0xMikolaj and @NatashaVasan (May 2024):
(forgive the typos)
In tradfi, we know how transactions work and the legal construct of contracts, statutes, common law duties, regs and self-regulation is all built for that mechanism. We don't have that for #DeFi and probably need it, but it requires us first to have some common understanding of "how transactions work". We should speak the same language. DeFi works differently, and "only the trader is responsible for what happens" is both bad as a matter of policy and a complete non-starter with regulators.
So who is a trader's counterparty when they use a DEX? Is it the liquidity providers? Is it the validator node (or proposer, or builder) that includes the transaction in a block? Is there no counterparty and it's just a trader using public code on a public network?
A common understanding of the legal nature of the DEX trade lifecycle - the instruction of the trader, the execution of the trade, etc. - will be positive for DeFi maturation. Participants want clarity as to whether the law holds someone accountable for the trader’s instruction, or its execution, and they want to know what harms does the law seek to mitigate, and what the law allows them to reasonably expect when using a DEX. Without this, how do sophisticated actors or a majority of the public ever use these computer protocols to transact?And what is a "transaction"? Could it not be one of two things conceptually? On one hand, it could be a technical instruction to a computer network to change its data state (often times having nothing of substance to do with anything financial in nature). On the other, at least sometimes, it could be something that has economic or legal substance, like exchanging ownership of one asset for another.
With respect to trades on a DEX, what the user signs and transmits can be analogized to a trader’s instructions to a tradfi intermediary, but there are unquestionable differences. In tradfi, the intermediary acts as the trader’s agent, and the law places obligations on and repercussions for these intermediaries so traders can reasonably expect the outcome of their instruction. In DeFi, to whom is the instruction submitted? In one sense, it is to the blockchain network itself. But the network isn’t fully atomated but is an environment of network participants who may impact how the instructions are executed or who may be in a privileged position with respect to the transaction.
For DeFi, the entities that “receive” transactions and have the ability to influence their execution are the entities involved in block creation and gossip of trader instructions across the network. Relays and block producers (both validator-proposers and block builders) may be in a position to affect pending orders. Unlike telecommunications operators, these actors no only have the ability but also the profit motive to intentionally affect trader orders. But that doesn’t mean it follows that they should be assigned tradfi-like regulatory obligations.
(Also important is the concept of when the instruction occurs. It seems sensible that we all agree it is the moment the trader signs the transaction message and submits it to at least one public node.)
With respect to execution, DEX trades will involve a smart contract. The use of that smart contract which defines the change to the data state of the network (as defined in the Ethereum Yellow paper) and is also the substance of the economic change the trader intended. And in this context we see how different execution in the DEX environment is from the tradfi environment. Smart contracts are deterministic and self-executing - they don’t require the involvement of other parties with the trade at hand to ensure its executed. A liquidity provider never directly interacts with a trader, as the DEX code replaces the tradfi intermediary.
However, you could look at it another way, that being from what computers connected to the network are doing what. From this view, smart contracts aren’t self-executing and autonomous because the network of computers must run the reuqired code and communicate with other computers on the network. From that view, you could ask whether the people running those computers should have some legally significant responsiblities.
When considering these questions, its important to agree on the legal character of a DEX trade. Is it a contract that could be legally enforced? At base, the law serves to protect user expectations when engaging in a trade. Treating these transactions would require us to know who is at the other end of the bargain. But who would that be?
Three options: (i) the validator-proposer who picks up and orders a trade in a block; (ii) the liquidity providers; and (iii) the DEX smart contract itself.
But before we get into the “who” we should examine the “why.” Tradfi uses contract because it allows the trader to justifably expect an outcome. Is contract required to ensure justifiable expectation/reliance in DeFi?
No. Whereas, in tradfi, performance is essentially discretionary on the part of intermediaries, there is nothing disretionary about the deterministic, self-executing code of DeFi. The code determines the outcome, and the pre-funded liquidity pools eliminate credit risk, so treatment as a contract seems unnecessary.
To the extent that a smart contract does not operate as expected, this is risk of nature that is different than one contract law is designed to address. Rather, the cause of a smart contract failure is generally (i) the trader herself; (ii) the contract developer; or (iii) a hacker.
Rather than contract, the goal of serving the trader’s reasonable expectations would be better served by tort than contract law. The law’s focus should be on whether the DEX user was sufficiently informed about the smart contract’s functioning, whether the developer coded or published negligently, or whether a hacker acted intentionally and wrongfully. This approach for DeFi would better serve the traders than the tradfi-contractual approach. Concepts such as recission or restitution might also help remedy injury.
But at the crux of all of this is how the law conceptualizes what is a “reasonable” or “justifiable” expectation on the part of the trader. If the trader can reasonably expect execution of the economic substance of their intention and not just the deterministic outcome of the code, then the avenues of recourse against anyone and everyone, including smart contrat devs, should open wide. If it is only reasonable to expect whatever outcome the code delivers, whether or not it is consistent with the trader’s economic intentions, then most avenues to recourse should remain closed to the trader.
But, if we assume a smart contract should be treated like a legal contract, against whom could a trader assert her contractual rights? For the sake of argument, you could say those that run the automated software that facilitates trades are in a position of responsibility and should be regulated as such. Those would be the network of validators, given their role in choosing and ordering transactions (which can affect execution terms). You could also point to the fact that validators collect fees from traders for their facilitation efforts, and they may outsource certain functions (like block building) to third parties. So, tradfi intermediaries running automated trading software could be analagous to validator proposers executing transactions using smart contract logic. Validators agree to abide by the rules of the protocol, and this could be contorted into some sort of contractual relationship with protocol users, like traders, who could have claims of restitution if their justifiable expectations (privacy, execution terms, ordering, etc.) aren’t met. If validator-proposers are actually “running” DEXs in this sense, then contractual obligations are clearly not whether the legal duties stop.
But such a regime wouldn’t make practical sense and wouldn’t serve the justifiable expectation interests of traders. First, validators aren’t like tradfi intermediaries because they don’t write the code or run blackbox applications, but instead the application is not the validators and is otherwise open and viewable to everyone. Second, while validators do impact execution order, justifiable expectations are better ensured by better education rather than direct regulation, with the possible exception of certain MEV strategies. More research on trade execution negative externalities based on validator/proposer/builder/searcher conduct is required. Third, the pratical legal problems with treating users and validator-proposers as counterparties would create an unadministeriable regime creating sub-optimal outcomes across the board.
What if we, instead, treated these transactions as contracts between traders and liquidity providers? This has intuitive appeal because it seems most analogous to tradfi. However, the economic mechanism for trade execution renders this unworkable. DEXs do not match traders with liquidity providers. The composition of liquidity providers changes often. How a court of law could enforce a trader’s claims agianst a pseudo-partnership of liquidity providers is seriously in doubt, in no small part because it is difficult to identify the LPs. And if “partnership” was the legal implication of liquidity providing, it would chill participation by anyone who isn’t the largest, most professional of LPs, meaning that DEX liquidity would be centralized.
A third option would be to recognize the legal personhood of a smart contact itself. This would require some new law giving such contracts some sort of quasi-corporate form to insulate validators, liquidity providers, and governance DAO members. This approach could be beneficial to the extent it encourages the creation and standardization of decentralized exchange rules prescribing terms of use and conduct standards.
In conclusion, one can see quickly the importance of fundamental questions such as “what is the role of validators in DEX trades?” and “what are trader’s justifiably expecting when they enter a trade?”. One can also see that the operational differences between a DeFi and a tradfi system compel us to look at the law differently. Some suggestions:
a) the alterantives to direct ex ante regulation of DeFi market infrastructure providers should be considered first, given that the deterministic mechanism and ex poste liabilty regimes like fraud, market manipulation, and tort could be sufficient to serve the public interest (setting aside all the ways the global nature of the system works against the effectiveness of any one jurisdiction’s ex ante rules).
b) The less sophisticated the user base (which is likely to happen as adoption grows) the reasonable expectations of the user will place more burden and risk on infrastructure providers, while those sophisticated users who can engage the system directly can be presumed to have a much narrower set of expectations.
c) DEXs through their governing bodies could create explicit contractual relationships with their users, which would help educate and ensure quality and reliability.
d) development of tort law standards for technical risks to critical software (smart contracts, client software, etc.) may be advised as well. This would ensure more precautions are taken and that code is properly assessed before deployed, lest the developers be held as responsible for any negligance should there be a loss.
WELL THEN. if you are still here, what do you think?
Excited to share @Mlawdala's upcoming event with Prof. Jeffery Zhang!
We’ll cover:
- Diverse forms of money in our economy and their significance
- Advantages and potential pitfalls associated with stablecoins and CBDCs
- Proactive measures financial regulators are considering
1/ 📚 Introducing the Digital Asset Law Association (@Mlawdala) - the University of Michigan's premier student organization diving deep into the legal & policy realms of digital assets & blockchain
Let’s dive into the @Mlawdala story! 🧵
@collegedao_hub Also check out:
DoJ Indictment against TCash Developers: Is Tornado Cash a service provider or a set of smart contracts?
Voyager Bankruptcy Opinion: Critique of the SEC's approach to crypto
Sarcuni v bZx DAO: Suggesting potential joint liabilities for DAO token holders.
@collegedao_hub For those keen on diving deeper into crypto litigation and regulation, here are some pivotal cases:
SEC v Ripple: Scrutinizing XRP's nature as a security. Read More
SEC v Coinbase: Questions on Coinbase's operations and its delegated staking service
ICYMI- this Monday, 1L @zmansoubi led Crypto Chat #3. His discussion regarding the intersection of productivity, inflation, and the wealth gap gave rise to a vibrant debate about the pros / cons of monetary policy-induced inflation in our financial system. Yay DALA!!!
Our president @NatashaVasan presented at the Michigan Block Chain Summt hosted by @collegedao_hub and @MichiganRoss! All the speakers were amazing but we obviously had our favorite!
The #Michigan Blokchchain Summit is the first of its kind.
- 8 Diverse and innovative #web3 companies 📈
- 6 Rapidly expanding #blockchain, #Entrepreneurship and #VentureCapital communities
- over 130 @UMich students 👩🎓
all under one roof 😎
Tap in for more info 👇
Business+Tech @MichiganRoss and College DAO are thrilled to announce the Michigan Blockchain Summit
A first-of-its-kind event dedicated to exploring the #blockchain and #web3 space from its innovations, business implications, and to its laws and regulations
More info below 👇
Recent regulatory actions raise legal questions about the ways in which PoS network users can participate in the validation of transactions through staking. Today @TeamPOSA released two white papers that advocate for a sensible legal framework for liquid staking. /1
New drop !! Couldn’t have had better coauthors to write my first Article with :) Wandering down the (v deep) rabbit hole of MEV, we find and unpack the legal and ethical questions which strike at the core of a novel crypto-based financial system.
To Haber and Stornetta’s groundbreaking hash-based document timestamping, distributed ledgers have been a work in progress for much of human history. Our takeaway: crypto, as the most recent evolution of DLT, is simply a new way of solving an age-old problem. 3/3
We went over the evolution of humanities’ attempts to log data in a tamper-resistant and lasting manner. From fu tally sticks in ancient China, to chirographs and indentures in medieval Europe , 2/3
Chris hopes to continue his professional journey at a large firm in New York, working alongside financial institutions to navigate novel economic and technological environments.
In his free time, Chris enjoys playing chess, video games, and watching terrible reality tv
Chris is the VP of Professional Development of DALA. A New Jersey native, he attended Rutgers University. He first became interested in crypto being a college student during the crypto peak and seeing friends make large financial gains through these new technologies.