 Okay. So, I mean, Des has sort of done the intro. I think the only reason I'm here is because it's always good practice to have somebody introducing someone of the first name have the same last name. I think that works very well for this type of role. Actually, I actually, for the first time I've met Casey, but I've been familiar with the company since it was Ares. I was formerly at the Wall Street Journal. And that back then, when we were just discovering this wondrous thing called Bitcoin, and we had our eyes on this thing, the digital currency, and we all thought heavily about that. And some of us started to understand that the blockchain might have more use cases beyond that. These guys sort of came out of nowhere and said, we've built a blockchain without Bitcoin. And it just spun everybody's heads around, and we didn't know what the hell that meant, and dug into it and realized that this is interesting. And what's interesting is that I think whether or not it's that aspect of it, this sort of permissioned blockchain structure, the fact that there was a company that had figured out a use case for companies to focus on the business application of this technology and decided to just run with that and start to develop it was a very interesting development in this space. I think it led the way in a lot of the kind of almost mania that emerged in the business sector after that, the hyperledges and everything else. Changed the name to Monax. Casey himself has a background in law, so he's perfectly well placed for this, done some interesting stuff in Somalia, a very big global legally informed vision. He's going to tell you that smart contracts are not smart. And I think I know where that might be going, and I tend to concur, but they are pretty cool in their own kind of way. So he'll tell us all about that and hopefully give you an enormous amount of food for thought to then take into the workshops and plenary sessions afterwards. Okay, so Casey Coleman. Thanks, Mike. Smart contracts are not smart, and they're not contracts. Smart contracts are the worst name thing in all of tech, if you ask me. As a lawyer, I detest this phrase, but for whatever event, for whatever reason, the community has adopted it. So these things that run on top of blockchains that are essentially scripts, we call them smart contracts. That said, they can be smart and they can be contracts. A little bit about me. So my background is I was, I did my first degree in structural engineering. After that, I decided to blow things up rather than build them. So as an infantry officer in the Marine Corps, after that, I decided to be a rider in a ski bomb for a while. After that, I decided to go to law school rather than doing the big law firm thing. I did the Africa thing, first in West Africa, where I worked at war crimes tribunals and then in East Africa, where I did governance reform work and eventually I ran my own law firm in Somalia. Throughout all this time, I've been a coder, predominantly at the amateur level. And now I do that for a living. Now I do legal tech. My company, as Mike mentioned, is now called MONACS. We were called Eris Industries. We were the first to market with a permissionable blockchain. And this kick started the blockchain for business industry and sector. We were the first to build scalable modular smart contract frameworks, which made it easy and fast for companies to deploy the business logic and applications that leverage the cool things that blockchains can do. We were the first to position this tech as legal tech. And I've always believed, since the very early days of this industry, I believe that at a foundational level, what we're doing is about legal technology. And what we do now is we build a blockchain-based platform for microcontacting. And what at a fundamental level it is, is a runtime for what we would call dual integrated contracts. And most of what I'm going to talk about here is a concept that I call dual integration. But first, a little bit of background. One of the things that I liked about what Christian said this morning was he emphasized that pretty much nothing that we do in blockchains and smart contracts is new. It's essentially a repackaging of old ideas. So that was a lot of, sorry, that was a lot of fast-forwarding. To back up here, the idea is that the computers can run the contracts for us. It's an old idea. There's legal academic literature going back at least to the 70s that says that there are efficiencies and effectiveness to be gained when we get a lot of the humans out of the way and we let the computers run the contracts for us. However, this was completely theoretical for an extremely long time. When we moved into the 70s, electronic transactions and electronic signatures started to become a thing. These helped and electronic transactions can be thought of a little bit as very simplistic contracts. But a lot of the infrastructure on which this technology was built was what we would call today legacy infrastructure that was predicated upon the idea that there is a one-to-one mapping between an application and an operator of an application. In the 90s, dematerialized assets started to become a thing and banks and others within market sectors started to try to move away from using paper as the basis of an asset. Obviously, there's some fungibility in this timeline. But to actually scale smart contracts, no one really until the teens got the packaging right. The packaging is what matters. If you talk to 10 different people in blockchains and you say to them, what is a blockchain and what's the core value proposition of this technology? You will most likely get 10 different answers. As a vendor within the blockchain space, this is incredibly frustrating because we can't even decide what our own value proposition is, not for a specific company, but for an industry overall. We would say at Ad Monax that blockchains are an event log that's kept in sync across computers that are assumed to be operated by different legal entities. And at a foundational level, what this gives us is a data infrastructure that is meant to be ran collaboratively. And this is new. This idea of how it is packaged is new. Really, what blockchains do, as Christian talked about earlier, at their component pieces is not particularly new. But when you package those component pieces and you say this is a technology that can allow us to collaborate across companies that allows us to have a data infrastructure on which we can collectively manage and order events, that becomes very, very interesting for a whole range of problems that I'll talk about a few of. Smart contracts, smart contracts are really should be called dumb scripts. As I mentioned, the idea that these things that we currently call smart contracts are smart is not right, particularly how the rest of tech uses smart. Most smart contracts that exist today or are in development are not have really very little to do with what traditionally in tech we would define as smart. And they're also not contracts. They're scripts. And what they do is when they receive a transaction, they perform some sort of computation based on what their script has been written to do, and then they provide an output. And this is ran across all of the nodes in a particular network. And so what this gives us is a collective processing framework. And in other words, it gives us an ability to know who did what when from a blockchain perspective and who did what how from a smart contracts perspective. And when you put these two things together, you have not only a data infrastructure that is collectively managed and turns on the head the old idea that there's a one to one mapping between a business application and the operator of that application. And now when we when we have both a collective data infrastructure as well as a collective processing infrastructure, we can build applications that are meant to run on an ecosystem level. And this becomes very, very interesting. And it particularly become why does it keep doing this sorry, it becomes particularly interesting for legal. And one of the reasons that we've always been very excited about legal is that from a from a business perspective, if you look across a whole range of large companies and and small companies, frankly, but large companies typically will have are a better proving ground for this. And you look across all the business functions of the large company, you will most likely arrive at the conclusion that of all of the business functions legal is the least optimized. And it's the least digitized of any of the business functions within that organization. Not only is it the least digitized, but it's also the entry point for our relationships. This is the point in the business where we where we make our contracts and our contracts are the entry point to our back office. They determine what is going into our accounting systems. They determine what is going into our HR systems. And all of these other back office systems that we have highly automated and optimized over the course of the 90s teens, 90s odds and into the teens, these rely on the contracts that are built with legal. And so not only is legal the least digitized aspect of a large company, it's also the entry point to the relationships of that. And as I mentioned, smart contracts and blockchains are really about coordination. And this is where I, this is the point in the conversation where we say that this is legal technology. Now one more piece of rant before I move forward. With all deference to Larry Lessig, code is not law and I detest this idea. Code is code. And law is law. And these two things are fundamentally very, very different. And they're very, very different for reasons of human complexity, frankly. Over thousands of years, we've built a whole lot of macros, a whole lot of functions into legal instruments that we use every day. We have integration clauses. We have choice of forum clauses, choice of law clauses. And all of these have been developed because of the complexity of human relationships. And this, in my opinion, cannot very easily be boiled down to code. However, if we can find a way to leverage a collaborative data structure, a collaborative processing structure, and what we have known from the history, thousands of years of history of law, we can build a package that combines the best aspects of law and the best aspects of code into a design parameter. And this design parameter we call, at Monax, we call this dual integration. If you've been in the blockchain technology space for a while, others call these Ricardian contracts. I think that an explanatory label is better than a term of art myself. So that's why we call this dual integration. And the idea of dual integration is that you have a smart contract and you have a legal contract. And we want to combine those into a cohesive package that allows us to have failover to a contractual and dispute resolution system, as well as leverage the coordination ability of what blockchains can give us to to optimize. And so from a very simple processing perspective, how does this actually work? And this is a typical process flow. It's very, very simple here in the real world. It gets a little bit more complex than this. But the basic idea is that we deploy a new smart contract to a particular blockchain. And when you deploy that smart contract, that will give you a unique identifier for that piece of code. And we call that within the blockchain industry, the address of this particular contract. And this is this is unique. So we have an ability to precisely define what is the script in which we are using and regulating this particular contractual relationship. And then what you can do is you can take that address, as well as the unique identifier of the blockchain that you're talking with, then you can build an integration clause and add that into what we would call the pros contract or what the lawyers in the room would just call a contract. And you can add a an integration clause that you know looks something like what I have written up there. And essentially what it says is that the fulfillment events or the events that relate to the fulfillment of the rights and obligations of this particular contract have been logged and or managed and or identified on a particular contract exists at this address on the particular blockchain. And then what you can do, and this is where the dual part of the integration comes in, is you can take the hash of the pros contract. And for those that don't know, a hash is a unique identifier, it's sort of a fingerprint of a digital file. And after the parties have signed the contract, you can take that hash and you can log the hash into the smart contract. At this point, you have a one-to-one mapping between a blockchain based smart contract and a digital form of a traditional contract. So the pros contract itself is not particularly interesting, but the idea is to leverage all the existing heritage that we have gained from years of screw ups and court history and conflict that has resulted in the body of law and templates that we know and use today. This is something that in our opinion shouldn't be thrown away. This should be leveraged. This is a massive asset that just because we have cryptographic hashes and some new fancy technology we aren't going to do away with and we shouldn't do away with. And in general, when we look at companies that are leveraging this technology, one would be very, very short-sighted to say, okay, we have this new technology, so now we don't need contracts anymore. If something goes wrong and something is inevitably going to go wrong, then you have to still have the coverage. Well, it would be short-sighted to not have the coverage. Let me say that a pros or normal contract would give us. And so by leveraging traditional contracting mechanisms and integrating those with smart contract technology, it is a little bit of an iterative step rather than a revolutionary step, but it also allows us to leverage all that has been gained over the years of legal development. Smart contracts side, what do we put in it? What does this look like? I'm going to sit low on time, but I'll talk through a few examples very quickly, shortly. But in general, what you actually put within the smart contract will be very dependent on the use case. At a high level, what we would typically put in there are a set of parameters. These are typically the variables that go within a contract, and I'll give some examples here in a minute. We would put in the workflows around formation of a particular contractual agreement, the workflows around execution, and or a log of events that relate to the fulfillment of a particular contract. When we put this package side of things is we have an evidence dossier as to the state of our contractual rights and obligations. So to summarize what the package looks like is on the one hand, we have a smart contract that tracks our obligations and rights in a cross-company manner. In general, what it manages is what we would call the happy path of this contractual relationship, and it is the code. So it lets the code be the code. Whereas on the pros contract, we leverage the existing dispute and dispute residence systems to manage our failover and exception paths. In other words, when things go wrong and things go wrong in all kinds of complex and weird ways, we probably want to let the courts or arbitration or mediation, whatever dispute resolution for us is appropriate for this particular contractual relationship. We probably want to let that do its thing. And this lets, on this side of the transaction or this side of the ledger, I should say, it lets the law be the law. So what does this look like and feel like here? So just to go quickly through what a typical dual integrated contract might look like, if we had an airline business disruption insurance, and these are very simplified examples, you would have parameters, a formation workflow, an execution workflow, and the parameters would be things like the parties to the contractual agreement, the length of the contractual agreement, the coverage, the premium, et cetera. These are typically the variables that you would have that would be married with a template. The formation workflow for a lot of insurance instruments is relatively straightforward. One party signs, the other party signs. The execution workflow is also relatively straightforward. The insured pays a premium, pays a premium, pays a premium, pays a premium, submits a claim, the claim gets paid, and we repeat. Human needs, this really likes to go forward. If we then move forward to a different type of transaction and what might a dual integrated real estate transaction look like? Well, in this scenario, the parameters might be the parties to the agreement, to purchase the piece of real estate. It might be the price, it might be the location, and then you would have formation workflow. And I've simplified here, but the point of comparing this with the previous one is that in a real estate transaction, the execution workflow is actually relatively straightforward. The execution workflow looks like escrow has released an entire list of transfer. However, the formation workflow is a lot more complex when you're dealing with a real estate transaction. There's a lot more checks that you have to do in terms of has title cleared, is escrow posted, and depending on the jurisdiction, there's a lot more steps and sub steps within each of those formation workflows. And this is why for most systems that are being developed today that are trying to leverage this paradigm of dual integration or Ricardian contracts, they break these two ideas of workflows at the formation level and workflows at the execution level into various different things that are then tracked and logged within the smart contract blockchain. And then as a third example, who here knows what parametric insurance is? A few people. Parametric insurance is a very exciting use of blockchain technology. The basic idea of parametric insurance is that the insurance company and the insured agree upon a particular data, a particular set of data and a trigger for that data. And if that trigger happens, the insured gets paid. A good example of this was a prototype that Accenture built very well earlier this year that they demoed it, they built it on our blockchain application platform. And what they did was they went to a vineyard owner and deployed a bunch of sensors out onto the various corners and sectors of this large vineyard. I think it was in France. And then what happened was that those sensors were programmed to trigger a transaction that would go into a blockchain and trigger then subsequently to a smart contract. And it would be triggered if the temperature had fallen below a certain threshold for a certain number of hours. So if it goes below x degrees for y hours, then the IoT sensors would send a transaction to the blockchain smart contract. And then that blockchain smart contract would essentially manage a payout that would go directly to the insured person. And the idea here is to reduce the user experience and pain of submitting claims on the insured side and to reduce costs significantly on the insurance company side. Because if we have pre-agreed a data trigger, if that data trigger is met, we pay out that that's a win-win from a lot of company scenarios. And so this is also a great use of dual integrated contracts because at the end of the day, while the smart contracts can manage the understanding of the data trigger has been met or has not been met, it still cannot provide the overall coverage that if something goes wrong, let's say the blockchain network went down entirely. Or let's say that the sensors were wrong on the IoT platform or the IoT sensors were wrong. There are going to be all kinds of exception paths that we don't typically want to handle within the blockchain element itself. We still want to leverage legal contracts to do. And so here's what a typical flow chart would look like in such a scenario. Oh, this would be for flight data, but the flight data is essentially the same idea. If your flight is late, you get paid. It is the basic idea of parametric flight insurance. So the user would input their flight data. This would trigger the parametric insurance contract. It would register with a data provider and also send parameters to a set of smart contracts that would manage the pro side of the dual integration. And then over after time, the data provider will say if the flight was delayed or it was not, if it was delayed, then it pays out. If it was not delayed, it does not pay off. So this will be the last slide that I'll show. I'm trying to have a little bit more time than that, but we're behind. Why is dual integration interesting? It's interesting for different reasons, depending on where you sit within a producer or a consumer of legal services. Practitioners of law using these systems have an ability to offer to clients a new and interesting product that typically they cannot provide the all-compliant templates for new contracts and new instruments. And when a change happens that is material, when a change happens within regulation, legislation, or case law, which is material to a new contract, which is material to an existing contract, our legal services provider can then leverage such technology to make a change into a template, upload it to a platform. And then on the consumer side, they can just keep making new contracts and not have to worry about whether my contractual templates are current or not. Practitioners of law also have an ability to reduce fees around what are fundamentally commoditized contracts. And for a whole lot of things that legal services providers do, you're typically doing commoditized work and charging a whole lot of money to do. And then finally, from the practitioner side, you have an ability to open up new revenue streams. Building these systems and leveraging these blockchain-based systems, you can leverage scale and reach new clients. On the consumer of law side, you have, again, an ability to have always compliant templates. And this is on both sides of the transaction here for a reason because it's of great value to both sides of a legal services transaction. And then you also have an ability to force your legal services provider to start separating out what they do in terms of actually providing you strategic legal advice from really pushing paper around and doing things that don't really have anything to do with providing you with strategic legal advice. And then also from the consumer of law side, if you deploy a dual integrated system or platform that leverages these paradigms, you have an ability to glean a massive amount of business intelligence as to where we are within our existing rights and obligations that we have outstanding. And so with that, any questions? Yoantan Lawrence, I don't have a rank, but a roll. I'm in the language processing field. I have a question about the role of blockchain in this strategy, this business strategy. What does blockchain give you that traditional scaled or unscaled transactional databases don't give you, especially considering that distributing smart contracts and building many rules onto the blockchain are expensive operations? Sure. So let me address the latter and then move back to the former. From an expensive point of view, this really depends on the type of blockchain that you're using. There is not much expense in terms of real economic costs if you're an enterprise leveraging an enterprise-grade blockchain. They run very efficiently. They use very, very little resources and there's not an economic cost to do that because when you're in a permission environment, you don't have to worry about the spam guards that are put in place that are then leveraged in the public blockchain space. In the public blockchain space, you're right, but they can be very economically done using specific different parameters. And what blockchain gives you is really about a common data framework that is operated across companies. So historically, if you wanted to build a contract management system and you were an insurance company, let me say, you then would have to enter into an agreement with your counterparties. And if you had a big power differential, in other words, if you were a large insurance company selling consumer automobile policies, then someone that is on the other side of that transaction doesn't have enough economic power to force a conversation about who is running the authoritative copy here that is tracking our critical relationships. However, if you're the same insurance company and you're selling business disruption insurance to a large airline, this is a completely different paradigm. Scenario, you have roughly an equanimity of power between the various parties to the contract. And you also have a whole range of systems that have to get plugged in on both sides of this contractual relationship. And by plugged in, I mean, plugged into whatever system is managing this. And because of how things work today, typically, you'll have a whole range of systems on the airline insurance that plug into some sort of a hub, let me say, for lack of a better label. And the same thing happens on the insurance company's side. And then there has to be a reconciliation between and across these hubs. And this reconciliation causes errors and costs a lot of time. And so this is what the blockchain essentially provides. Okay, if I could summarize for you, to reflect my understanding, and I think the understanding of others, is that you're saying by having a shared ledger, you have accountability, you level the playing field for accountability. That's fair. That's definitely one aspect of what I was saying. You also just reduce errors quite tremendously, which is, in most existing legacy systems, you still have accountability. You mostly know who did what, and you have audit trails around your various state changes to existing legacy databases. This isn't particularly new. In blockchain land, we use cryptographic digital signing algorithms, but the rough idea is not fundamental and new. What's new is that we're all sharing the same golden copy, and we're co-managing what is the golden copy of record as to the history of our relationship. That makes sense. Thank you. I can always repeat. Just a request, since we were a little bit behind, if we could make it a lightning question and a lightning answer. I'm still a lawyer. I can't promise a lightning answer. That's up to you. From a prose writing perspective, the one who writes the prose contract, what particular changes should one anticipate or do or should be doing or should be in the lookout for in the context of integrating it with a blockchain-based script? I would say as little as possible, frankly. This is one of the key things that we try to get across when we're working with clients and talking to clients is that from the blockchain's perspective, unless you're doing something completely divorced and you're trying a completely new line of business and trying to completely re-envision something that hasn't happened before, which we're not at the point within the blockchain industry where that's happening within the traditional enterprise side. When it does start, then more will need to be taken into account, but at this point, very little. I would say stick to what's tried and true, essentially. Thank you, Casey Coleman. Coming up, thank you, Casey. I'm going to take expert so that we put in our next future law, graduate course. That was great. Good having you here in person. Thank you. What's happening next is some breakout sessions. Remember those flash talks you heard before lunch? We've got a few coming up. Thanks. Right now, we're with tables. Chris Mondaline here, our collaborator and one of the local kind of ops team, an incoming chair of Massachusetts Legal Hackers, has been wrangling the tables. I just wanted you to talk people very quickly through what happens next. How do they find a table? How are we organizing it? So everyone, if you wouldn't mind, once we're finished here filing down towards the breakout table area, what we'll be doing is essentially you'll find your relevant table. So the table number corresponds to, you'll see at the end of each category of breakout session, it'll have in parentheses breakout number, right? So you go find your table. If there's overflow, we can handle that. Just come find me if there's any kind of issues with that. But yeah, for the time being, if you guys identify which session you want to be a part of and then find your way over there and we can sort you out. Thanks. So one thing we can do while you're here is let me do a quick show of hands just to get a sense for which ones we might want to double up on. All right. So here's what's happening. So we have Brian of Thompson Reuters Labs and the VAT scenario. Who might be interested in going VAT? So you're just going to get a rough idea. Okay. So what table is worth? Another one we've got coming up is what is this public sector scenario? Who's this that? Oh, okay. All right. So we'll come back to that one. We've got supply chain with Girvinder and that also is kind of provenance. So let's do a quick look that's about, that's like two tables, right? Okay. We have, it's 20, we've got bankruptcy with Bob and it's like, it's like, what actually how many, is that 10? It's like 10. That'll be a good table too. That's a good spread. Okay. So we have, okay. Now isn't there another, who thinks is, who else is going here? Is there anyone else that thinks they're going? Okay. Great. So we'll add you and we have Mr. Jaggers on official records, right? And we'll make you table number five. It'll be table number five that you'll sit down on. Who's interested in official records, diplomas, military discharge, what could be passports, could be your law license, I don't know, for a certificate? Where does it end? Okay. That's like, oh, there you go. So what was that like? That's a solid table and maybe in a bit. All right. So who didn't raise your hand? You didn't really hear someone tickle your fancy just yet? We did. And so thank you. Thank you, Oliver. So we've got a special thing now with the C4 coin gang on a legal entity as an automated piece of software, but otherwise effectively consume and be sued in the United States. And let me check his Harrison here, somewhere. Okay, I just spoke with him. And so we're going to do as an online session, we're going to make it a table and it'll be webcast for people that want to see it. Who's interested in legal entity, automated legal entity, really? Okay. That's good. So that's one, two, three, four. That's great. You guys don't know what you're missing. You'll see later at the report outs. This is very hot stuff. So that's a that's a good table of people with technical legal and technical. Okay. So that good. Now who didn't raise their hand? Anybody not sure what? Yep. Yeah. So is Dan Harpel here yet? Okay. So we have the energy sector happening as that I tried to nudge it up to this session, but I need to change it back to 230. And basically, we've got it. We've got basically two things happening at 230. There's going to be a panel discussion in here. And they're both great. But it's just whatever you choose panel discussion in here on women leaders and blockchain and AI. And we have a kind of a workshop where you'll workshop the issue of like ownership rights and basically like this like a systemic legal framework for these micro grids. And that'll be in the classroom right across the way. So it should be about 50 50 or so. You can self select. Okay. All righty. So does everyone get it? Any other questions about we're going to walk over to the tables and pick your table and facilitators walk faster. So people see you there. Okay. See you after just want to get with you to let you know we've had a little bit of a program change and decided to do the breakouts now, which is why you're not seeing much happening on the main stage. And what's going to happen? Actually, Tom, you might want to know this too. We had to do a program change to basically not have the women leaders panel conflict with the energy breakout. And so we're going to get started again at two 15. I think is that where it is to the next session time. So tell you right now to 30. So at 2 30 p.m. Eastern, we'll get right into the women leaders panel. And then it'll go about 45 minutes. And then we'll go right from there to the energy workshop with Michael Casey, Dan Harpole, and Harrison Pearl. And then go from there to all the report outs to here all the great stuff happening in these in these workshops and in these little breakouts. So I'm just going to take the liberty of closing this broadcast. And then it'll start again here from the media lab with more live programming on the MIT legal forum 2 30 p.m. Till then.