 And we're live. Hi, I'm Taza Greenwood coming to you from Cambridge, Massachusetts. And this is the big week when we teach the MIT Computational Law Workshop course. This is the fourth annual offering of the course and the second year when we've been so very privileged to have a friend and colleague, Michelle Git, let's join us. And Michelle's a partner and the co-chair of the Blockchain and Digital Currencies Working Group at Blank Rome. And frankly, one of the few genuine experts in the area of smart contracts and the law. And I want to thank you for taking time to provide this flipped classroom lecture that people can see in advance of your live session on Thursday when we'll get into some nice discussion during the breakout group stay. So welcome, Michelle. And where are you checking in from today? It looks very nice. Thank you so much. I'm actually in the middle of the Red Rock Mountains in Sedona, Arizona. Fantastic. OK, well. The power of technology. And where do you ordinarily practice from? You're an East Coaster, I think. Yes, I practice out of New York City, although I travel extensively and I'm very fortunate that my clients are all over the country and all over the world. Here, here. OK, great. So I guess without further ado, I'd like to hand the baton virtually over to you to learn us something about smart contracts and the law. Thank you. Thank you. So I'm going to screen share now so that you can see my materials. I'd like to welcome everybody. And thank you so much for including me. I co-chair the blockchain and digital currencies working group at Blank Room, where I help clients bring blockchain applications to market, including applications that involve smart contracts. Today, we're going to speak about the legal paradigm surrounding smart contracts. And I understand a lot of you are also interested in music and smart contracts. So we'll touch a little bit on that as well. So thank you so much for having me. My contact information is on the first slide. And please do not hesitate to reach out to me talking about blockchain and cryptocurrencies. And smart contracts is my favorite thing to do aside from hanging out with my kids. So please don't hesitate. Excellent. OK, are we screen sharing? Yep, we've got some screen sharing. It looks like a split screen. Oh, here we go. Yep, it looks great. Great. So we'll just take a few minutes to go over the agenda. We're going to talk a little bit about what is blockchain, what is a smart contract, the use of smart contracts, the enforceability of smart contracts, and what we're seeing is the future of smart contracts. Just by way of level setting, blockchain is a form of distributed ledger technology, DLT. Blockchain is not Bitcoin. It is a shared list of transactions that everybody who is participating in the blockchain ecosystem can see. Every new transaction is a timestamp block. And every block is linked to a previous transaction creating a chain of transactions. Blockchain is a software that is on the internet. It is connected by a network of computers. And all of the entries on the blockchain are cryptographically sealed, and they are immutable. And we'll talk about why that's important and why it may be somewhat of a detriment in connection with smart contracts. So just some benefits of blockchain, which can also undoubtedly be benefits of using blockchain technology for smart contracts is we have greater transparency, enhanced security, and improved ability to trace transactions, greater efficiency, speedier transactions, and hopefully we're reducing costs. Blockchain is what I'd like to call a technological revolution. Business today you can see on the left. And everybody who participates in a business transaction, each has their own computer with their own version of the truth of the transaction. It requires all these people to interface, all these constituents in the transaction to interface, and to reconcile what's happened with one another, which is time consuming. But when you have blockchain, all of those constituents are plugged into the same blockchain transaction. And they're all connected. And they're all nodes on the blockchain. And they can see the same ledger that's being updated so that the only reason why an entry is actually on the blockchain is because all the people who participated in the transaction agreed that that transaction did happen and happens in the manner in which it's reported on the blockchain. So lots of people ask whether blockchains are secure. We know on a public blockchain that anyone can read the ledger. And we know in a permissioned blockchain, data can be made private. Cryptography is used to keep the data safe. And we believe that smart contracts and contracts in general would be more secure because they would be recorded on the blockchain. In real life, contracts can be lost. They can be amended inappropriately. And we think that on blockchain, we could solve some of these inefficiencies. On slide 7, I give you some basic definitions just for level setting. I'm not going to go over them today. But they're there for your use. And let's just get into the need of it. So what really is a smart contract? It's a digital representation of an agreement and a mutual agreement, meaning all the parties to the contract agree on the terms in the same way as a traditional contract is agreed to. But that contract is coded and it's stored on a distributive ledger instead of being recorded on paper or on a computer in an electronic form. This smart contract is basically an unstoppable computer program, meaning it can't be modified without everybody's permission to modify it. And I like to say that a smart contract is somewhat like an if-then statement. If a condition is met, then the contract self-executes. And there's no reason for there to be an intermediary who's monitoring the contract and its terms because the computer is doing that. So how do smart contracts really work? Just like traditional contracts, the parties identify the terms and conditions. The different parties agree as to what the desired outcome would be. And for example, you can have a real estate contract that's coded on a blockchain. And we know what the price of the house is. The parties have to agree what the property is, when the closing will occur, how the funds will be transferred. And then once all those inputs are placed into the ledger, into the smart contract, the contract will self-execute once all the requirements are met. Some smart contracts require access to data sources outside of the blockchain. And we're going to talk about this with oracles a little bit. But the smart contract can have a feed of data from another location, meaning the rate of LIBOR can be fed into the mortgagery for the smart contract or the price of what gold is trading at could be fed into a contract if the parties are exchanging gold. The price of a stock, for example, could be fed in. And so even though that's a separate and distinct data point, that data point can be fed into the technology. So in essence, though, we always need the computer program and we need the code to be input onto the blockchain. And one thing that we're seeing in actual practice is we're having developers and coders who are taking our contracts and they have to translate them into the code. And the average lawyer is in a coder. So we have a little bit of tension arising because how does the lawyer who's not a coder ensure that the coder or developer is inputting the right code? And those are some issues that we deal with. But I think the future that we're going to see eventually is that more lawyers are going to become facile with coding. And again, there's self-execution. So once the defined terms and conditions are met, the computer program self-executes. So and the outcome is recorded on blockchain. So smart contracts, a basic example. This is what you see on slide 10. And again, I'm not going to go over the buying and selling in the house example again, but you can see how we map it out here. We match the buyer and the seller. There's an exchange of assets, the house for the currency. There's the ownership of the house has to be undisputed. And we can digitize the land deed so that eventually, and hopefully, we're not going to need things like title insurance because we're going to know that there's a truthful source and verified source of title that's recorded on blockchain. And so there would be no need for something like title insurance. I mentioned earlier that there's the possibility of having a third data point come from the outside and feed into the blockchain and the smart contracts. And we talk about that as incorporating oracles. So an oracle is a trusted third party source. It could be an individual or a program. And it transmits data from the outside world into the blockchain, allowing the smart contract to react to external events. Again, as I mentioned, it could be a data feed conveying LIBOR. It could be a data feed conveying a stock price, where the price of an asset such as gold or silver. And the oracle is the party that is faithfully providing that element of information that the contract needs to self-execute. So if you need to understand what a mortgage payment would be if it's a floating rate, then you need the data feed if that mortgage rate is based on LIBOR. And so if a mortgage agreement was input on blockchain as a smart contract, you'd always need that oracle of LIBOR to feed in to be able to calculate what a monthly cost would be for that mortgage. Another example of the use of an oracle would be with a sports bet. If John and Amy are betting on a game, John could, for example, bet $50. That Toronto is going to win a certain basketball game or baseball game. Amy could bet $50, but instead Philadelphia is going to win that game. And the winner would receive the $100, the collected $50 from John and $50 from Amy. But how do we get the results fed into the blockchain into the smart contract so that we know who the winner is and how the $100 should be automatically transmitted to the winner? Well, we have something called a game feed that would put the scores into the blockchain or the smart contract. So for example, maybe ESPN is monitoring the game. And there is ESPN acts as the oracle and feeds the results into the smart contract. And we know that if the Toronto Maple Leafs win that game, the feed will pull from ESPN. It will pull from that oracle into the code. And it will automatically transmit that John, who bet on Toronto, actually won the bet. And the smart contract will then execute $100 to John as the winner. We can also think about the case of using an oracle for flight insurance. So for example, if you're worried about your flight being lead or delayed, you could buy insurance that would protect you against any loss that you might receive if you didn't make your connection or if you didn't make your meeting. There has to be some feed into the smart contract for the flight insurance that you purchased and the contract that was coded on the blockchain so that the smart contract knows whether or not your flight was delayed. So the contract's coded on the blockchain, you have the smart contract and then the smart contract consults with the oracle, the flight information that's tied to public flight records and then you would be automatically compensated for the delay. And you can see that information on slide 13. I'm not gonna go into detail about slide 14, but we know that you can also do complex financial transactions using oracles. And so for example, if party A and party B are dealing with a futures contract based on the price of gold, we can use an oracle, the London gold fix for example to feed into and report the price of gold so that the smart contract can self-execute. Now, I happen to have a client who's using smart contracts to pay royalties and to audit royalties in the music industry. And the reason why this is important is because generally when auditors audit license agreements and music contracts, there are so many of them for any particular company that they can only really do a sampling to figure out if the right amount of royalties are paid. However, in using smart contracts and artificial intelligence, they would be able to actually audit 100% of the transactions that occurred because they would be able to better verify and more quickly verify because those contracts were executed on the blockchain. So that's actually a real world example of how industry in particular auditors are using our auditing smart contracts that pay the licensing amounts to the artists or authors or other constituents who license their intellectual property. On slide 15, we have sort of models for smart contracts and I call this a spectrum. External is the code is not the agreement but it automates the performance of contract terms. So the code on the blockchain isn't the actual agreement but it effectuates the terms of the contract. You also have a hybrid smart contract where the code could form an integral part of a legally binding contract but not the entire contract and it would supersede other clauses that are written in a paper contract. And then you have an internal smart contract where the code is the agreement and it supersedes any clauses that are written outside of the blockchain. I think I am hopefully coming off somewhat clear that I'm very bullish on smart contracts and I think that they can create a lot of efficiencies but there are some pain points. A smart contract once it is recorded on blockchain, we know that blockchain is immutable. So you can't change that contract which could be difficult because a lot of contracts have amendments. Now are there ways to get around this? Of course we could execute a new smart contract on the blockchain but fundamentally it is unchangeable and that old contract will always be recorded on the blockchain. Another concept is that the execution of smart contracts on blockchain is not purely automated. It doesn't entirely remove the need for trust amongst the parties. It just merely automates a narrow set of payment obligations. And of course there could be some security vulnerabilities. There could be loopholes that are unintended like security bugs that would invalidate the contract or the smart contract could operate unexpectedly and perhaps a digital currency that's stored within the contract gets transferred to the wrong place. But again, these are also things that can happen with regular contracts. We know that unanticipated consequences occur when banks transfer money and they're not supposed to or escrow agents transfer money when they're not supposed to. So it's not that the drawbacks and limitations are necessarily things that we don't see without smart contracts but they aren't quite a perfect solution. So some people ask me is a smart contract really a legal contract? Well, a smart contract is only legally enforceable if it has the required elements of a contract meaning there's an offer. The quote on the ledger allows the participants to interact with each other and give one another an offer. There has to be acceptance meaning the offeree signs the transaction with their private key effectuating the legal acceptance and then there needs to be consideration. Both parties agree to the exchange of something of value which is the legal consideration. What about the statute of frauds in the uniform commercial code? They require that certain contracts be remoralized and signed in writings. Smart contracts will likely satisfy the statute of frauds and the UCC if the contract coded on the blockchain outlines the material terms of the arrangement and if it's signed using the private key. However, there's exceptions depending on the specific facts and circumstances and we know that there are states here in the US that are more receptive to the smart contracts than other states. And again, this is oftentimes a pain point because some states like New York and Delaware recognize from an evidentiary standpoint that blockchain is sufficient for evidence purposes and other states just simply haven't recognized it. So whether those other states will recognize a smart contract is somewhat up in the air. We have something called the UETA and ESIGN which requires certain elements from electronic signature. And we think that under these circumstances an electronic record could be validated as a legitimate contract. So there is an argument that even in states where blockchain records aren't sufficiently recognized for evidentiary purposes, perhaps the UETA or the ESIGN legislation could help us with enforceability of those smart contracts. Again, just a few pain points and hurdles with the UETA and ESIGN. There may be a need for an express agreement showing the parties intent to be bound by the smart contract. The smart contract system may also be required to present consumer rights and receive consumer consent to those rights. And lastly, there are three states who do not use the UETA and there may be additional issues in those states for using smart contracts. Also, there may be issues in enforcing smart contracts. For example, jurisdiction, whenever you sue a company or an individual or a party, there has to be personal jurisdiction over that entity or individual. And with smart contracts, figuring out where that personal jurisdiction would be could be complicated. Is it the place where the person signed the smart contract? Is it the place where the person lives? Is it the place where the person actually transacted business? There's also questions of choice of law and international issues requiring a determination of whether U.S. and a particular state's law govern or whether international law governs. Immutability, courts cannot reverse a transaction or stop the smart contract from executing. So can you actually get a temporary restraining order that tells the parties that they can't actually effectuate the terms of the contract? Probably not. So what's the remedy? The remedy may be having to actually reverse the transaction after it effectuates, which causes a whole slew of issues if you're not actually able to undo the metrics that occurred from the smart contracts effectuation. And also finally, obtaining damages. Is there an ability to obtain funds awarded without the other party's private key? Some additional issues, enforcing smart contracts. We talked about that a little bit, whether a particular state or international jurisdiction is going to recognize the enforceability of the contract ambiguity. Smart contracts can't, they can't always account for what happens in real life and whether something is vague. For example, sometimes there are terms in a smart contract or terms sorry in a regular contract to use best efforts. Well, how does a blockchain that's self executing a smart contract really judge or how do you define and code what best efforts are? And again, there's always amendments and renegotiation in real life. Contracts do provide for amendments. So we have to really struggle and figure out how to do that on blockchain. What's the future of smart contracts? I think that you're gonna see a lot of them. Again, in the music royalty arena and supply chain in prediction markets where smart contracts can be coded so that events that happen in the future like sports betting that we talked about and the transference of digital currency of a certain result occurs will cause the contract to automatically pay a person the winning. And we know the jam says launch to smart contracts practice to train arbitrators in the area and to develop special rules that govern these disputes. In some, I think that there's a lot of desire in the market to see if we can use smart contracts to create efficiencies and to help contracts more efficiently and effectively be administered. I think there's probably some pain points again about the enforcement of smart contracts using our current legal system, which is obviously federal on one portion of it, but also state specific, particularly with contract law and that different states may take different positions with respect to these new types of contracts. And also the issue that not every lawyer really understands what smart contracts are and how they're coded and making sure that the terms that the parties agree upon are actually the terms that get coded into the blockchain. So I really appreciate our time together today. And I hope that I can visit with you again in the future. And I appreciate your time. You're here. Thank you, Michelle. We appreciate you and your time very much. That was exactly what the doctor ordered when we were asking you to provide an overview of smart contracts and the law. And you kind of, that was a good survey and I think it really scratched the itch. A couple of things that we were sort of back-channeling about as you were talking, we think that the two slides you had when you started to identify some of the key issues is like slide 20 and 21 in there, 21 and 22. When the time comes on Thursday for the breakout group of the students and others who would want to engage in this topic with you, I guess we nominate some of the issues on that slide as a good jumping off point. There's probably, I don't know, 18 months worth of discussion on the end of the bullets. And then one other little thing was, are there any, I guess I'd say, are there any questions or, I guess, questions or ideas that you would encourage students as they're prepping for your session once they've seen the slides to be thinking about in order to be able to jump in and kind of hit the ground running when they meet with you on Thursday? I think a good thing to either look into or think about are just this idea of the Oracle, the trusted third party source, how that's really gonna manifest itself. And I think the second thing to think about is amendment of the contract and how that really jives with this immutability concept and what will that really look like in the future and how will parties, we know that simple smart contracts can be effectuated on blockchain, but how do more complex contracts involving multiple entities and multiple, if this happens, then that happens. And the idea of the ambiguity, the best efforts, the acting and good faith, I think it would be really interesting to have a discussion on what people think that will look like from a legal enforcement standpoint. Yes, okay, very good. I know that was one of the things I was wondering about when you got to the Oracles is, some of the smart contracts I've seen so far in practice include Oracles as mundane as the notifications and alerts that you would get from FedEx or another delivery service Amazon to know like did a package come and at that point is maybe like the risk of loss shifted or are you now like a qualified buyer or does it signify that something's occurred? You're now on notice maybe and then there's our legal ramifications to that. Some of these services I think like the LIBOR and others like the New York Stock Exchange, they understand their tickers and their APIs have meaning and that people will rely upon them potentially to their detriment and that they fear some responsibility for the consequences of what they're putting out there. In other cases, information sources that could be logical for an Oracle may not be up to the task or they may think it's or they may even have disclaimers that say this is advisory only and we reserve the right to change it later or they may not be putting that much effort into making it correct and the consequences of relying on those types of services as an Oracle could be significant if you can't easily unwind or be flexible in the contractual mechanism to adjust for those kinds of things. And so there's a whole question of what would be the information security and I guess reliability and availability of service kind of sorts of requirements that would be proportional for an Oracle for a given contract is a new range of questions that we'd have when we work. When we want that external source of data to be integral to and well, quite literally integrated with in terms of integration clauses and being within the scope of the four corners of the contract, it becomes very much an element of the contract and so I think there's a whole rich discussion there about what it means to lawyer in that environment and to be a business person and the kinds of questions we're due diligence to ask and how to structure the transaction from a business legal and technology perspective. So that Oracle one's quite good. And then on the second point that you mentioned in terms of amendments, I was thinking during your talk a lot about the difficulty with the way blockchains operate for the purpose of having finality and immutability and making it having a single source of truth. That's not a great fit for let's go back and fiddle with it later and send an email but it may be an opportunity to use other tools in the legal toolbox such as having clauses that indicate in the event of the need for a charge back or reversal or an adjustment, the process is we don't change this thing but we now activate another thing to even a balance or to do a partial refund. So you're getting maybe sequences or linked or connected contract legal instruments that can take care of the overall life cycle of a relationship between parties or there may be other ways but basically we're talking about how to be a good lawyer to clients that are using technology and to make sure the right tools are orchestrated in a way so it supports and reflects the deal and you're protecting the interests of your clients and now we've got a new playing field with this technology so everyone has to become familiar with it and then do our jobs and practice law but do so in a way with your eyes open and being intelligent and informed about the set of capabilities that the technology provides but I think the question is about amendments. We're very poignant. It reminded me in the 90s we had a bunch of clients that were doing EDI, electronic interchange for procurements and similar to the supply chain scenario you were saying and there was definitely finality with, like you did the purchase order, you sent the goods, they sent the money. We wouldn't go back and change those things in the systems that we used but we would when we had parties that had longer term relationships that were like multi-transaction there were opportunities to then go and trigger other things like charge backs and adjustments and reconciliation and settlement so that the incomplete, we very much wanted to keep a complete record of what happened so that we could justify to our auditors and other people why we paid this sum of money. Oh, it's because transaction 173B6 on this date was an overcharge by this amount due to some error so being able to have immutability is not bad but it does raise the need to think about flexible ways to make adjustments in the future. So I thought that was a very rich point there as well. All your points were terrific, Frank. Thank you. I think you raised a lot of interesting issues and I also think that we're still, it's still so early on that we haven't solved all the potential issues. You know, 20 years ago we wouldn't have thought that you could amend a contract just over email, right? And sometimes those amendments don't always make it into the paper contract. They don't even always make it into the file but they're enforceable. So I think what you're talking about with chargebacks is really interesting and doesn't mean that a smart contract can't be used effectively. It just means that there may be some, we could even for lack of a better word, say off chain transactions that occur that supplement what's on chain. Just so and just, I mean, as you announced I think quite properly you're at an advocate of smart contracts. So just putting our like smart contracts happen for a moment and going further there can also be additional smart contracts. Like why can't we have a smart contract that does a thing called refund? And why can't we have another smart contract that does a thing called chargeback? And why can't we have another smart contract that does a thing called we're version two of the contract at this address on the chain? So I think as you say, and actually just one last thing I don't wanna keep gushing about your slides but we're kind of back-channeling about your spectrum slide on kind of the basically on the relationship between traditional legal contracts and these smart contracts and when they're totally separate and when they're somewhat hybridized and so forth. I think it very much raises the question of how to structure the legal understanding such that it can reference a number of different smart contract mechanisms based on the different transactional needs of maybe multiple services and multiple states in a life cycle of a relationship between transacting parties. So I think the idea of understanding where the legal contracts and the smart contracts fit within how you're structuring transactions and relationships for clients is tantamount to the practice of law and the digital age and just feel like again we could just land on that slide for days and not run out of important new things to say. For sure. Well, thank you so much for having me. Thank you, Michelle. And we look forward to following up with everybody on Thursday with you. So until then, enjoy the West. Thank you.