Learning [to Understand] Solidity for Attorneys
Attorneys don't necessarily need to learn to code, but learning to understand code can be quite beneficial
Learning some Solidity and solidifying (pun intended) a web3 transactional/DAO practice has been so satisfying that I wanted to follow up my Learning Solidity for Attorneys article[1] for those still hesitant to take the decentralized plunge. This post will introduce benefits of merely understanding the effects and structures of Solidity and their legal significance.[2]
In the first article, I mentioned some parallels between Solidity/web3 and transactional law that can help attorneys put fingertips to keys in Solidity IDEs (integrated development environments); now, I’d like to explain why grasping some particulars of Solidity and the Ethereum Virtual Machine will help in agreement and document drafting where the on-chain must be harmonized or contemplated in the off-chain. Instead of a Solidity coder, maybe a Solidity-to-legalese transpiler?
Attorneys are trained in drafting, analyzing, modifying, negotiating, and interpreting highly consequential writings, like contracts, motions, statutes, pleas, treaties, and other agreements. Solidity carries similarly massive potential ramifications of mistake, with the added wrinkle of functional irrevocability (in exchange for the benefit of uncensorable performance). In web2, technological redundancies and institutional middlemen safeguards exist to backstop developers and agreement outcomes; however, a deployed smart contract without upgradeability/proxy or other control mechanisms has no such backstop. Multiple high-profile DeFi exploits[3] have demonstrated that manipulation of web3 code can be highly lucrative, and thus mistakes can be expensive (and sometimes cataclysmic) with resulting litigation (if any, especially with a pseudonymous exploiter) uncertain and prolonged.
While attorneys might be uniquely receptive to coding Solidity due to their trained care in drafting and close eye for textual traps, they may also appreciate learning the requisite precision in code choices and intent. Not everybody has the desire to get granular in their approach to merging Solidity into the master branch of their professional life. Similarly, not everyone desires to build their own smart contracts or audit others; they may just desire an increased understanding of how the code works in order to hone and broaden their existing professional skills and deliver better results for clients. The notion that attorneys must become full-stack smart contract/dApp developers to complement their skillset in the next generation of contracting may unwittingly deter the otherwise tech-forward.
When would it be most valuable for an attorney to understand some Solidity or other web3-relevant languages? The most obvious would be where there’s some necessary code-to-legalese translation/reflection to be done. This is especially evident in the burgeoning field of DAO legal wrapping (the direct or instructive relationship between a DAO and a legal entity), where a legal wrapper entity’s documentation is best served by precise references to the DAO’s code. Knowledge of unique risk factors within the DAO’s governance contract or its promulgated software better serves the client and educates third parties (whether prospective DAO contributors or interpreting dispute resolvers or judicial bodies). Functions with legal relevance may be cited directly in DAO wrapper organizational documents, in deal agreements, or other legal contracts; for example, the voting procedures set out in the MetaCartel Ventures Grimoire, or the API3 Foundation bylaws conferring beneficiary status of externally owned accounts staking API3 tokens in the DAO governance contract.[4]
For non-web3-native entities that use blockchain technology in their contractual relationships, it may behoove their counsel to understand the nitty gritty process of how and in what method value is transacted to the other party; how it may be trustlessly locked in smart escrow contracts until closing, expiry, or dispute resolution initiation;[5] or other code specifics that may need to be reflected in the off-chain documentation. Explicit reference to Solidity functions, variables, mappings, etc. in legal documents can provide precision in reflection of on-chain processes, express deference to code, as well as intent clarification.[6]
Code comments may evince some intent by the applicable developer (but should not be relied upon). Learning the basics of Solidity’s NatSpec format[7] can help when skimming a verified smart contract on chain, to assist in determining the context of parameters, the relevant returned items, or the foreseen future iterations of the deployed code. A smart contract deployer cannot control third party interfaces, but may attempt some flavor of notice to third parties by commenting.[8] There could certainly be relevant code comments, modifiers, or even variable names that, when read and understood by a Solidity-literate attorney, may contribute to analysis of practical outcome versus coded intent. For example, even an untrained eye to the screenshot below might recognize that the buyer probably shouldn’t change the sellerApproved variable in the ‘else if’ statement (but instead perhaps a buyerApproved variable should be in its stead), whether used as a mere on-chain record, or more consequentially, as a condition to release funds at closing.
If Solidity functions/variables/mappings get cited in legal agreements or organizational documents, it’s imperative to understand the implications of the reference and any future amendments. A quick list of example considerations a Solidity-familiar attorney might consider when looking over a smart contract, depending on the context:
- Who or what can change a variable or mapping, and what are the possible values?
- Does a cited function change state or is it pure/view only? What does it interact with or alter?
- Is the function callable by anyone (including internally), or only by certain whitelisted addresses or otherwise modified?
- What obvious privacy and security implications might need to be considered?
o what information is revealed on-chain?
o What permissions are required?
o Does it rely on pseudo-randomness, imported third party code libraries or contracts, or oracles?
- Is the contract immutable, or does it have upgradeability/proxy?
- If this is a DAO governance contract, are there specific functions, structs, mappings, token balances, or other concepts that can be directly cited in the DAO’s organizational documents?
Code auditing is best left to the professionals. However, a code-literate attorney might ask helpful questions to a developer seeking a certain real-world effect from the code’s outcome possibilities, or avoiding certain pitfalls, when attempting to transpile to legalese. If learning to understand Solidity sounds appealing and useful, join the LexDAO discord[9] – you may enjoy our upcoming LexEd initiative where we seek to educate lawyers on a swath of web3 topics and produce some (gasp) interesting CLE content.
.
[2] I update all of the useful Solidity resources I come across here: https://github.com/ErichDylus/Smart-Contract-Resources/blob/master/Build.md.
[3] See https://cryptosec.info/defi-hacks/ for a staggering timeline and list.
[4] See, e.g. the Section 4.3 Voting Procedures in MetaCartel Ventures’ Grimoire, accessible at https://github.com/metacartel/MCV/blob/master/Legal/Grimoire%20and%20Exhibits/MCV-Grimoire-Final-All-Exhihbits.pdf, and the bylaws of the API3 Foundation, accessible at https://github.com/ErichDylus/API3/blob/main/governance/API3%20Foundation%20-%20Bylaws.pdf.
[5] https://medium.com/api3/redefining-trust-smart-escrow-contracts-975a8ee26703.
[6] For more on intent and limits to code deference, see “Transactional Scripts in Contract Stacks” by Shaanan Cohney and David A. Hoffman (accessible at https://minnesotalawreview.org/article/transactional-scripts-in-contract-stacks/) and “The Limits of Code Deference” by Drew Hinkes (accessible at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3889630).
[7] https://docs.soliditylang.org/en/v0.8.10/natspec-format.html. NatSpec comments are now visible in the Etherscan UI.
[8] For example, see the discussion at
.
[9] https://discord.gg/MxwB96VQ. Thanks to James McCall, Jared Cohen, Decentralawyer, Arvind, and other LexDAO members for their feedback.