Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Claire Warren & Scott Farrell: DnA Contracts – Bringing Human Discretion to Smart Contracts

Episode Date: August 1, 2016

Blockchain smart contracts are self-executing contracts composed of computer code. These programs, which are executed by the entirety of the network, enforce the rules described within the code. Effectively, in this realm, code is law. And as we’ve seen recently, altering the outcome of that code after it has been deloyed, should we later realize that it was flawed or did not produce an intended result, can be messy. In addition, there are instances where human intervention can be necessary or even desirable. Take a mortgage agreement for example. Should a smart contract be entrusted with the responsibility of making a decision when the borrower can no longer make his payments? In cases such as this, subjective human intervention is be necessary. Scot Farrell and Claire Warren, lawyers at the global law firm King & Wood Mallesons, think that humans should not be automated out of every process. While code is logical and predictable, it cannot act reasonably or take into account certain unforeseen events. They have proposed DnA contracts (Digital and Analog), where automation can occur when absolute automation is possible, but where humans may intervene at the edges and provide input when needed. Topics covered in this episode: What issues DnA contracts are trying to address The basic concepts behind DnA contrats The scenarios where DnA contracts may be valuable Examples of DnA contracts applied to interest rate swaps and mortgages How DnA contracts could be integrated with blockchain technologies The impact of DnA contracts on legal services Episode links: How to use humans to make “smart contracts” truly smart DnA Contracts proposal on GitHub This episode is hosted by Meher Roy and Sébastien Couture. Show notes and listening options: epicenter.tv/142

This is Epicenter Bitcoin, episode 142 with guests Claire Warren and Scott Farrell. This episode of Epicenter Bitcoin is brought to by Jax. Jacks is the user-friendly wallet that works across all your devices and handles both Bitcoin and ether. Go to JAAWX.io and embrace the future of cryptocurrency wallets. And by Hi.combe, protect yourself against hackers and safeguard your identity online with a first-class VPN. Go to High.Me slash Epicenter and sign up for a free account today. Hi, welcome to Epicenter Bitcoin, the show it talks about the technologies, projects, and startups driving decentralization and the global blockchain revolution. My name is Sebastian Kutjur.

And I'm Meher Roy. Today we are joined by Scott and Claire from the law firm KWM in Australia. This is a global law firm. And Scott is partner at this particular law firm, King and Wood Melson. He has been practicing in financial markets and financial systems for 20 years, including the creation of new financial market infrastructure. Claire is a senior associate at KWM specializing in capital markets, derivatives, structured products, clearing and derivatives regulation. They have together come up with an idea called DNA contracts that mixes digital and analog terms in order to form a new kind of let's say smart contract. So we'll be walking about what these DNA contracts are and what they can enable. But before we start, let's have a bit of background about

about KWM and our interviews. Scott, if you could give a bit of background. Sure, thank you. King of Wood Mallisons is a global law firm which has a very strong presence in Asia. We have more than 150 partners in China, for example, and as well we have more than 150 in Australia. We have a similar amount in Europe as well.

We work for both global companies in all sorts of fields, as well as startups in FinTech and other startups. We don't have a particular focus in only working in particular sectors or industries. We follow our clients, and in some cases, we hope to lead our clients into new areas. And from our perspective, Claire and I are not technology lawyers.

We create financial markets and financial systems and help people deal with the risks in those systems. We come at this from the perspective of our startup clients and our financial services clients are heading in this direction. And really our work is about making it easier for those people to understand your world rather than trying to be experts in the technology world, trying to understand finance. So I'm a senior associate that works with Scott in primarily the background is in a derivatives and financial market space.

I've had experience in London before moving to Australia and helped a lot of clients throughout the global financial crisis in 2008 onwards. So I have seen a lot of contracts when they don't go quite so well and the turmoil that comes from that. And from helping our clients in this space is how I've really got into more of the smart contractor and fintech area as well. So can you tell us a brief history of how your team got interested in smart contracts and how you ended up doing the work on DNA contracts? Yes, we can. And it requires, unfortunately, you to just listen to us for a moment to explain what we do in our day jobs. What we do in our day jobs in working in financial markets is we work in a legal code already. We already work in legal documents that don't have verbs.

They just have series of words and then numbers listed down the page. The reason for that, the reason that the international derivatives market works in that way is it already must be globally standard. The risks are simply too big to have lawyers getting in the way by using their own words in many circumstances. So we already have trained ourselves over many years to work in what legally can be a relatively automated environment. Once you move to the idea that this analog legal code that we have been immersed in can

have some of its best elements done by something far more efficient, you can then see how we get involved in smart contracts. We do not think that smart contracts need to be left to simple things. We can see the role that they have in a much bigger marketplace because we can see a direct analogy to what smart contracts can do with computation and what, you know, for the last 20 or 30 years, we have been doing with words in the financial marketplace. Once you have that transition, you can see why we need to help be part of the future. And that led us into what would we do if we had this technology and applied it to our world?

What do you mean exactly, like you'll have to excuse my ignorance of legalities, but what do you mean exactly when you say that the contracts that you write don't have verbs? I literally mean that. And so, for example, the idea behind derivatives contracts is that you don't need lawyers. And so the verbs are all standardized and contained in separate documents which are never touched. And what you really play with is turning switches on and off and then adding particular words which trigger other functions which are written in these separate books, which are standard right around the world. And so the actual, if you and I were to do a derivative, we wouldn't have an argument

about whether something was reasonable or payable or all of those terrible lawyer words. We would have an argument about whether it starts on this date, whether the interest rate is payable on this basis and whether these are the right numbers to be used. And that is a piece of paper we would exchange with each other. Everything else is already agreed internationally on the base of what effectively we would call a code. And it's kept in code books. They're legalese code books, but they're standards so that you don't need to use lots of

words for each transaction. Okay. So if I could make the analogy then into sort of into the development work, world and we have all sorts of open source libraries and open source applications that we use. And so some of these are standard and just sort of standard functions. And then a lot of times configuration is in a separate file. So what you're saying is that derivatives contracts, for instance, are standard all across the world, the way that they operate and the way that things sort of happen within the terms of those contracts are standardized.

And all the parameters of those contracts are then written in separate documents that reference the initial contracts. So as you mentioned, you may have, you know, dates, amounts, interest rates, that sort of, the parties involved and that sort of thing. Is that sort of a good analogy? That's a very good analogy. That's exactly kind of as it is. So, yeah, so we would, in our traditional derivatives world, we would import those definitional. booklets into our particular contract, just like you would in your kind of open source world, so they're all standardized.

So we would just import the ones we need in. We don't even have to write them out. We just include them by reference. So it's just like importing a library into some code. That's really fascinating. I had no idea that that's how actually it worked. Okay. I have a whole new view of like the legal system now.

And lawyers. So tell us, one of the core issues that, with smart contracts that you're trying to address? Probably the core issue is that if you use smart contracts in a broader context into amounts and relationships which really count in the non-technology world, you're playing with other people's money and other people's futures, then there is always a need to consider the context of the society you're in. You're going to have to deal with the framework that we as people deal with each other.

And what I mean by that is if Claire and I were to do a derivative together, our relationship is not limited to that derivative. And if some things happen, which we can't predict, and our history in dealing with the financial crisis and other crises before that, tells us there is always some things that can happen that you can't predict. Then human judgment and human discretion is invaluable to get the right way out of it. I can say that from a perspective of real experience, prior to the financial crisis, we worked on lots of derivative products which were very heavily mathematical.

Some of them, the algorithms that were part of the legal contract were 80 pages long, and that was just algorithms behind it. But those algorithms, however complex they are, they couldn't respond to the most simplest of problems. For example, if Claire became bankrupt, then we would have to have the outside world imposing its own rules on what our relationship was, and whatever we had agreed would happen

wasn't as important to the rest of society for the rules of that society. In other words, smart contracts, if they're going to be used to a real size in a real society, do need to have some respect for the laws of that society and potentially get the support of those laws to be really effective. So what you're saying is that in this particular case, so if you gave the example of a deliberative of this contract

between you and Clara, if Clara were to be bankrupt, then it's the rules of what needs to happen, what needs to happen in that particular scenario is no longer a part of the standard contracts that you mentioned earlier, we have to come back to sort of national laws or perhaps some sort of arbitration that is not defined by law, but perhaps it's defined, is rooted in negotiation between two of you. Is that about right? Yeah, I think there's two parts to it, really. There's an element. of derivative contracts that do already talk about what happens if something so bad happens.

But a lot of the time it's left to the discretion of the parties as to whether they want to trigger that result within the contract itself. And that level of discretion is extremely important and extremely desired by a lot of people in the financial markets, whether they wish to trigger that event or not. The second thing is, yes, there are now. bankruptcy provisions in many jurisdictions probably pretty much all that quite often will come over the top of a particular contract and say no this is not the way it's going to happen it's going to happen in another particular manner so there's kind of two elements to that I think really so our audience mostly is people from the

software industry code etc so can we walk through an example of one standardized derivative contract in which under certain circumstances human discretion becomes important and we cannot engineer human description discretion out due to whatever reason one example sure why don't we why don't we use the complex example of actual default clear we'll step through that so say Claire and I have an interest rate swap which is just an agreement that Claire will regularly pay me money based on one interest rate and I will regularly pay her money based on another interest rate.

The idea behind that derivative is that as time moves on, it actually has real value. One of us gets to win and lose, depending on how the real world interest rates have moved, different to what we have originally agreed. And that means that we're one of us to fail to not be able to perform. It could be that one of us has lost a contract, which we're. was worth real money to them. And so what happens in the derivatives marketplace, what is agreed between most of the participants around the world, is that, say, I was the one who failed to pay because I was bankrupt,

and there's no way of making me pay when I'm bankrupt because a legal system will make any payment from me at that point void, regardless of what we had agreed because we can't contract out of that under our legal system, is Claire would have the right because I was bankrupt, to finish it all now, to close it all off, and to say, actually, what has to happen is I should just pay Claire the value of the transaction which it had at that time. But the important thing about that is if you only had the information of that contract, and if you only had the information on the interest rate derivative market, you would not have the right basis to make the decision for Claire as to whether she should actually pull the trigger on me.

That is dependent on whether I've actually, in addition, loan Claire's money. It would depend on what the rest of the book that Claire has, the other derivatives that she has, actually are doing at that time. It would depend on how Claire herself saw the interest rates in the future. And if the contract itself terminated automatically, Claire would be deprived of something of real value because the marketplace truly values the ability to choose. That's called optionality and it's worth a lot of money. And so that is an example where an unpredictable event has occurred because Claire obviously didn't think I was going to go bankrupt or she would never have done the transaction with me.

But the idea that you could predict and then presumably encode all the possible inputs into Claire's decision to continue or to terminate our relationship seems from our history and our perspective of dealing with people who make these decisions to be a bit beyond what is possible in the information set that most people have. Claire, would you like to add something? I mean, I think that's exactly right.

It gets back to the point about discretion and the optionality that is really valued with the clients that we see and the financial markets more generally. That option, whether to try, trigger that consequence to trigger, okay, yeah, I want to shut down this whole relationship or not is really, really key. And it's valued possibly beyond all else in some of these contracts that we deal in on a day-to-day basis. There's probably one other thing that we should

add here, which is a clear demonstration of perhaps a difference in thinking between the analog marketplace and perhaps a digital marketplace, in our world, you can choose not to perform a contract. There are consequences to that. You will have to pay damages, but it doesn't mean you get sent to jail or anything. And there are really good circumstances where you may choose to not perform a contract because it suits your life to do that. And you understand the consequences and you're happy to pay them. That is an important right that real people have to adjust their legal rights to the real world situation they're in. If everything were automated, then real people should ask, well, how am I being compensated for the loss of that right to choose between

continuing performance and paying damages? And that's not something as lawyers that we can take away from our clients unless they have agreed to give that up. And that's the way we see issues around complete automation of contracts is to be aware of what you are giving up by doing that, not just be aware of what you might be gaining. Let's take a short break to talk about Jacks. Jacks is a cryptocurrency wallet created by the people at the Central. Now, there are two cryptocurrencies that matter at the moment. One is Bitcoin and one is Ether.

But using them can be tricky, what wallet you use. How do you secure them? Where did I leave my umbrella? It's all a big mess. And that's where Jax comes in. Jax is a unified wallet. It works across all your devices. It works for their Android phone, Apple, iPhone.

It works for your desktop computer. And they have browser extensions for Chrome and Firefox. And it works for both currencies at the same time. It works for Bitcoin and it works for Ether. One of the things that makes Jax as delightful as walking through the 5th,000 in HONJSMO of Paris on a Sunday morning and getting a whiff of fresh pastries is how they leverage HD wallets. So they use a 12-word single backup seed for all three currencies and make it super easy to sync your wallets across all your devices.

So if you're using the Chrome extension or the desktop app, you just can whip out your phone, scan the QR code, and boom, your wallets are synced. And plus, the people at Jax take your security very seriously. It's open source, so anybody can look at the code. And plus, they never hold any customer funds. All the keys are stored locally on the client side. So go to jacks.io, that's j-a-a-double-x.io, download the jacks wallet right now and understand what it's like to use the next generation wallet. We'd like to thank jacks for those supportive epicenter. I would actually like to take a different example and

and maybe if that's a wrong way of thinking about it, then you could correct me and that would help us. So the example I thought of when I read your paragraph on human discretion being important for the performance of multiple contracts. I thought of a typical home loan agreement. So let's say Scott you're the bank and I come to you as a customer, right? And I want a one million Australian dollars right for a home loan and I agree to pay let's say 4500 Australian dollars per month over the next 30 years. We do the contract. Everything goes fine. two years later I lose my job I'm unable to pay the 4500 Australian dollars a month now as per the contract itself as per the loan agreement itself you have the right to come and

foreclose my home but that might not be the optimal move for you because maybe you see in my situation that I'm going to get another job in three months and I'm going to be able to repay you back then or it might be the case that like interest rates have reduced and you want to renegotiate with me a different contract that stipulates a lower monthly payment so that I can end up paying it so even though you have the power to foreclose you would want the option of being able to foreclose or not foreclose and this is the human discretion that we need in the performance of this contract. Is that a good example? It is an excellent example. And it is a true example. The amount of times that lenders choose not to immediately exercise

all of their rights far outweighs the amount of times that lenders would immediately exercise all of their rights. It's a business decision of the lender as to which path will allow them to, one, recover their money and two, potentially continue to have you as a client in the future. That's the decision that they have to make at that time. And exactly as you have mentioned, you and I can't predict now. We can't predict what those circumstances are. Even less could we predict all the possible reasons why it would be a good idea to not foreclose on you because there's effectively a limitless number of possible things that could happen in your life, which would mean it would be a very good decision to give you a bit more time,

to refinance and to not immediately exercise the rights. That's right. I mean, and essentially, a person who's lending you money doesn't really want to own a house. They just want to be repaid their loan. Owning a house is not really that useful for them. Yes, they may sell it again, but it's a lot of time and it's a lot of effort for them. So there's always that part of the decision as well that is taken into account. Like, yes, that is a consequence that can happen, but it's to be taken in light of all the other factors that are out there in the world.

In this particular scenario, the decision to not foreclose, could be a, I mean, it could be a business decision. So it could be based purely on, on sort of, you know, rational principles, you know, like I want to continue to bring in revenue from this loan. Or it could be empathetical, right? It could be, well, you know, this person is in a difficult situation. So we will be lenient in accepting perhaps like an agreement in which they can pay in a few months. It seems like the rational business decisions could be automated in some way, but that the sort of empathetical, the ones that are based in empathy or maybe it's not even empathy. Maybe it's, as you mentioned, like, I want this person to be a client in the future,

which always comes down to being a business decision. What sort of, where's the threshold, I guess, where these things can be automated? Where does it cross the line into like this can no longer be automated? This has to be a human decision. Where do we establish, you know, in the DNA contract, you know, the human intervention switch has to be turned on? Just to add to that, there also could be a range of inputs beyond our relationship, because one example of what will lead to a decision to either foreclose or not foreclose is what does the rest of your portfolio of loans look like to completely different people. And what does the

economy of the country that you are currently exposed to look like? So what we saw as being an and I should say this is part of the fundamental value that we think we are contributing is just to point out that there are decisions which we can't see can be simply computed. And so the point that we get to is where is the efficiency frontier, where to collect all of the possible inputs that would go into a computed decision on this point, would be inefficient because of either the computing power or the simple, huge number of data inputs that you'd have to collect and trust makes it far better to move it to a more efficient computer being the one inside someone's head rather than try to mimic the decision tree that someone

is going. The decision tree is just bringing in so many complex inputs, some of which would not have even existed at the time the original contract was drafted. Yeah, that's right. I mean, the way we look at using computer technology to kind of improve or change how we currently see contracts in the kind of traditional space is through, okay, how can they be improved, whether that be through efficiency, through speed or through reducing error?

So it comes to a trade-off between those things. are we not doing that anymore? When is it actually not any of more efficient? And it will be different in every different type of contract. You'd have completely different considerations for, for instance, in our world a derivative than you would in, say, a home loan. Like it would just be, it would really depend on the type of product that it is. But it's the same kind of decision to be made is, okay, well, what is not efficient anymore? And what is actually not leading to a good outcome? Okay. And I think one other interesting trade-offs is,

that it's important to mention here, specifically in the context of smart contracts as we imagine them in something like Ethereum or blockchain is an ininibity. That is one of the sort of, I guess, objectives of smart contracts, of Ethereum smart contracts, is that you can interact with participants in a completely anonymous way if you wish. That's what what blockchains have made possible. In this case, if you're reverting back to some sort of an analog, human subjective decision, you have to, that is a trade-off. You no longer have anonymity once you enter into that world.

What, can you talk about some of the different types of contracts on the spectrum from, you know, fully anonymous to not anonymous, where parties must know who there are. interacting with. What are the different use cases for these full-on smart contracts a la DAO to the sort of traditional contracts that we have that we use and we've been using for centuries and where DNA contracts fall in the middle? And you've touched on a very important point. Because we don't come from a tech background, we don't think smart contracts have to be limited to anonymity or platforms which provide anonymity. We think actually there is a huge amount of leverage to that technology being applied

in the whole world of relationships, which are documented under legal systems. And so if you, but it doesn't, anonymity doesn't itself mean that a contract may not benefit from having a human judgment applied. It does mean that it could be part of the framework that we won't need human judgment because that's what we're buying. We know we're doing this. This is what we are paying for.

We don't want to have the flexibility of a relationship. We don't want a banker to be able to choose to not foreclose. we want to be anonymous. Now, in the world of broader contractual relationships of high-value contracts, anonymity is not going to be possible because of the regulatory framework that everyone functions in because the regulators and government of the world want to know that huge sums of money are going to places where they think huge sums of money are going. But when you don't have anonymity, it usually means you have some kind of relationship,

relationship context, and that's where there is likely to be a benefit for the analog part to actually get value out of that loss of anonymity. When you do have anonymity, it is possible that having an analog context, which doesn't have to be a simple human making a decision, but something which is outside the very structure which creates a problem to solve a problem. So if there is an issue with a system which has anonymity, is it possible that that system could get itself caught in a problem that it can't solve? In which case, is there any kind of safety valve which can be used to resolve that problem? If we think about it in that context, that's effectively a large part of what we're doing with aspects of our analog contracts, is allowing the computation. element to call out for help when the computational element has effectively got stuck.

And as architects of that at the start, we're trying to build in those areas where it is now more efficient to not make the computer just spin wheels, but to actually provide an answer from the outside. So I think that's right. So you can have the code, you know, ask people for inputs when it needs them or ask some other source for inputs when it needs them, just as contracts do today, and then keep running again, that can be an element of using an analogue thing. It's looking outside of the code. And whether that's automated or not is a different matter. You can have that automated,

but you can also have things where we call them kind of hard off-ramps, where someone can go in and go, actually, I want to take this contract out of being fully automated. I want to deal with that with my counterparty now. Now that comes down to. So yes, there is no anonymity for that and that you need an element of trust and you need to know who your counterparties are. But there's no reason why you need that in a particular contract if the parties don't want that. So touching again on this question of anonymity, I'd like to get your opinion on this. If you had the choice, now that we can have anonymous contracts, I think, I mean, unless you can correct me, that this is relatively new that we can have anonymous contracts, fully anonymous.

In an ideal world, should we, by default, always try to tend towards having anonymous contracts rather than having contracts in which part of which part is an own? If we had to choose between what the default position would be, should it not be anonymous as much as possible where we can automate and then, and then have to, have fail safes that tend towards analog when it's needed? Where we see, let me speak to that, not by me making a choice, because it is certainly not my choice to make. But let me just speak to that as to when anonymity has developed

in the financial marketplace before this. Where it has developed, which is usually through things like exchanges and clearing systems, is when there is no element of risk between the parties. The risk has already been completely isolated and effectively it has become irrelevant as to who the other party is. No part of what has been bargained for and no part of what has been performed

actually is influenced by the existence of the other party. That is a very small kind of contract normally or it's a very short term as in I want to buy this standardized thing. You want to sell this standardized thing. When it is used in circumstances of longer term contracts, what has to happen is a super trusted third party has to be inserted in the middle. Because as it goes longer term, people are counting on the contract to actually be performed, which gives rise to credit. risk, which normally means I have to know who has just promised to perform this because there is a real risk they won't perform. In those circumstance, what the marketplace, what the people who consume these services

ended up creating was a super trusted party in the middle who would effectively perform in the place of everyone else. And so really what I'm getting to is in choosing whether to make it anonymous or not, we again have to work out whether what we're giving up by way of information is important to the contract that we're entering into. It might be critical to the contract if we're actually counting on someone to do something because even if the contract says the money is paid, once the other side has gone into bankruptcy, you have to give it back. So even if you try and hardwire rules of performance into a computational contract, under most legal systems, you'll end up in the same

spot as you would if you tried to hide hardwire something into an ordinary contract, is you just can't contract out of our legal system, which means that there are some risks, which means that information about who you're dealing with could be relevant to the way that you price that deal because you can understand the risks you're taking. So we've been talking a lot about DNA contracts since the beginning. And it occurs to me that we haven't really defined what the components are and actually what DNA contracts mean. So let's maybe let's dive in a little deeper and explain what we sort of have,

but briefly explain what a DNA contract is, what the different components are and how this components interact. Sure, sure. So DNA stands for digital and analog, basically. So it's one contract that comprises two sets of terms that do different things. One being a digital set of terms, which operates through automation through code. Another set of, we've called them analog terms, which is kind of legalese terms, terms in kind of writing. And the idea being, and we've taken an interest rate swap as an example, just as a proof of concept to see if it works is that the easy bits the bits that provide for calculations of amounts due so the calculations between the parties that Scott and I discussed earlier based on different interest rates that can be done by a computer so that can be put within what we call the digital terms but there's sometimes bits that you need discretion for so if for instance I failed to

pay a certain amount which gave Scott the right to terminate the contract should he want to, we leave out of the digital terms. We say, no, that's better for a human head to decide whether to trigger or not. That's in the analog terms. And so you go through each of the terms of the contract, and you make that decision when you design sort of architecture for it, whether something can be automated. And if there are benefits in speed, efficiency, and reduction of errors in doing so, because a computer will efficiently and effectively perform the same calculations again and again and again,

better than a person can do it. So we've then decided that actually what do you end up with is during the normal life cycle of this interest rate swap, quite often a lot of different contracts, nothing bad happens. The parties perform their obligations and the money gets paid and the contract ends when it's meant to. And all that kind of stuff is actually pretty useful to be automated. where it can be. But it's all the bad stuff that takes up quite a lot of traditional contracts. What happens when something goes wrong? All the discretions, all the commercially reasonable wording and all these sorts of things you see in a lot of legal writing takes up quite a lot of the contracts.

But that stuff's really important, but actually it requires a lot of discretion. And so we've kept that out of the digital terms. There's some elements of the digital terms that also pass questions or things to be answered over to a human and then can continue operating again. For example, one of the payments under an interest rate swap is calculated by reference to a floating rate of interest which is available on a particular we've chosen a Reuters screen. So the code goes off and gets that rate from the Reuters screen. But what happens if Reuters doesn't publish that rate on a particular day? Well, the code then goes, okay, I can't get that.

I'm going to go and ask a particular human. It's called a calculation agent in our circumstances. The calculation agent determines that rate in accordance with the analog terms. We've told them how they are meant to calculate that. And then they put that back into the code, and the code carries on working again. So that's an instance where you have a human intervention because it's easier to do so. And then the code carries on working and tells the people how much they need to pay on a particular day. One of the critical things there is that the provisions which are encoded are not just a way of executing the contract.

They're actually the terms of the contract at that point in time. So we don't see the D bit as just being a way to make the A bit happen. We see the whole thing as quite a smart contract because the relevant terms are written in the relevant language at the time they are best used. They are written in a digital language and they are the terms of the contract when it is most appropriate. And then those terms move it to an analogue contract when those terms are not appropriate. And the critical element of this, which comes from our background, is it is very important that these terms match what happens in interest rate swap contracts, which don't have this technology, because what is fundamental to the derivatives marketplace, because the sums of money are so huge,

is you can't have basis risk between the terms of a DNA interest rate swap and another interest rate swap, which is just on an ordinary basis. So we wrote it so that you would actually have computer terms. but then we had to make sure that those computer terms actually matched what the rest of the world did, because when you're dealing with billions of dollars, the smallest difference could produce an enormous cost for someone if the market moves in an unusual way. That's right. So the analog and the digital together constitute the one single contract for that particular interest rate swap and can form part of the larger relationship that Bacartis may have using, say, traditional

contracts as well. So when you say analog terms, I imagine like an English language document. And when you say digital terms, it's code. And then you have ways by which these two refer to each other. Right. Like when I look at the digital code, I can know which document is the corresponding analog term. And when I look at the analog term, I can know which is a digital term. How is this linkage made between code and English language pros? Yeah, that's exactly right. So, yes you do you have the English language prose and it refers to in our example it's fairly rudimentary but we just refer to digital terms having a particular hash and the same in the digital terms we prefer to the analog terms having a particular hash they speak together but the

idea is that they don't try and overlap so the digital terms do one set of things and the analog terms do another set of things and there shouldn't be conflict between them there should be a seamless pass between what a human needs to do in the analog world and then back to the digital terms and vice versa over time if needed, with the idea being that actually if nothing bad happens, there's no need to really look at the analog terms, particularly because the contract will execute through the code. I was going to add something which probably won't appeal to all of the technology people that are listening to this, but the way we explain it to non-technology people, and particularly

because we're from Australia and so everyone swims here. It is literally like you're swimming in the fast lane at a pool, which is obviously the computer lane because it works very fast. You run into someone in front of you who's not swimming very fast, so you move over to the next lane, the analogue lane because there is a blockage, and then the terms of the contract actually move you back into the digital lane as soon as you get around that blockage. And so you move from swim lane from digital to analog and back.

And really what we've done is work out, well, when you're, should those transitions occur based on our experience in the marketplace and then how those transitions should occur based on again our experience in the marketplace. So to actually make it make it more tractable for the audience because I suppose not all of us have, I guess maybe none of our audience has ever dealt with an interest rate swap before. But to make it more tractable, I would actually take the example of the Dow, the the DAO that basically had all the money stolen. Now when you look at the DAO contract, the DAO contract had this special role which was called a curator and a curator was supposed to

limit the number of proposals that were going to be considered by the Dow shareholders through voting. Now so this curator was like a human that was supposed to study all the proposals that come in and somehow apply a filter on these proposals. Now what ended up happening is, in the DAO was that the role of the curator was not expressed in code at all. It could not be, right? Because it needed human discretion. And the DAO didn't end up defining the role of the curator in an English language document. Now the problem here is in one future day, it might could have been the case that the shareholders

did not agree with what the curator did. And because they didn't have an English language contract defining it. this relationship between shareholder and curator, that would have led to conflict and probably, you know, in the future stalemates of various kinds. So what a DNA contract would do rather instead is you define the role of this human input giving curator in English language. And then you also define what happens when the shareholders are not happy with the curator and how they can be fired in the analog world. But when the relationship is working fine, the Dow code can handle that execution of that organization in an automated fashion.

So when everything is going fine, you use the automated code. When there's a conflict between how a particular human is satisfying his role correctly or not satisfying his role correctly, then you go into the analog world, sort it out there and then go back into the digital realm. And their DNA contract allows this switching from digital to analog and back. Yes, and I suppose the addition to that is that agreement as to what the code says when it's operating is what we agree, and then what the curator says is also what we agree. So that is part of one agreement, that is quite important because that means that you shouldn't be able to argue that I don't like what the curator did in circumstances where, well, you agree. up front either that he could make his decision as it sees fit or whatever or in accordance

with certain rules. And this is, again, in our background where we work with complex derivatives that often have very complex indices which have someone exactly like a curator, this is quite familiar to us. But we do make sure that people agree to everything. They don't just to get to agree to the ordinary. life cycle of a transaction, they have to also agree to the default mechanism. And that's important because that means that they should understand not what will happen when the unpredictable happens,

what not what the result is, but they should understand the process that you have to go through. And it's not an outside process. It's part of what you bargained for. And that is quite an important thing in from our world constructing complex things. And we think it's quite an important thing when computations are used in complex things as well. So one thing that occurred to me yesterday when we were talking about this with mayor is that even in a scenario where you may have a human intervention, let's take it back to, you know, this idea of mortgage and, you know, that one of the party, so the lending party, sorry, the borrowing party filing for bankruptcy. So we have this contract. It's being executed automatically. And at some point, the, you know,

the analog component is invoked. Some decisions are made in, so, the real world by subjective inputs. And then we go back into, we go back into the automated system. And having dealt with living in France, I have to deal with administration quite a lot. It's sort of the flagships here in France is that everything is very complex administratively. And sometimes you have to go back on decisions. So sometimes you have to provide paperwork and that paperwork maybe isn't processed correctly or maybe you provide the wrong paperwork and decisions are made and then you have to come back on them. So how would that work then in that case where we go back into automation land and then we discover that, oh, we made a mistake.

We have to come back and we have to revert these decisions. How would that work? I obviously can't speak to the complexities of French administration, although that did sound pretty tough, what you just said. that's part of the ability to lift out, lift the contract out of the computer lane in circumstances where you haven't even, the computer itself, the computation hasn't done it itself, but one of the parties has said, or maybe both of the parties have said, we need to lift this out to fix something up. Now, the reasons, you don't have to define all the reasons for that.

as long as you come from a starting point of we want our will to be better, not we are trying to create something where the computation framework is always the one applying. So for all sorts of reasons, you may need to lift something out and adjust something. And believe me, we see this all the time from our world too, where we have to adjust transactions, not because people are having an argument, but quite the opposite. They need to adjust the mathematical terms of a derivative because that's actually not what they wanted to do. And so the ability to move it effectively from the fast lane to the slow lane again, so we repair the fast lane and then push it back is always there. Where that would be potentially unacceptable is to people who don't accept that we should ever have an ability for the parties to readjust the settings. In the world of financial markets, you've always got to allow for that because it should never be set and forget because the future world is too unpredictable to have set and forget.

But if you just want to improve what currently is the case by pushing as many things into the fast lane as you can, then the fact that you can sometimes lift out into the slow lane to fix things up, that's just fine. because what the advantage is, is you're only in the slow lane when you need to be. And for everything else you're in the fast lane, using computers to do the work. Let's take a short break to talk about hi.com. You know you need a VPN provider to protect yourself against those nasty hackers trying to steal your private information. With high.combe, it couldn't be easier. You just install their application on all your devices, iOS or Android, log in, and you have a cushiony, cozy tunnel in which your data can move freely and unencumbered,

all the while protecting you from those mealed hackers. Now that's boom. To sign up for the free plan, go to HightopMe slash Epicenter. The best thing is when you use that URL, if you ever go premium, later, you're going to get 35% off and premium comes with unlimited bandwidth, using up to five devices at the same time. You can use all their servers worldwide. You can pay with Bitcoin, and best of all, it comes with a feeling of peace and satisfaction, like having tea with the Dalai Lama. to thank Hyde.me for their support of Epicenter Bitcoin. Let's bring it back into the blockchains.

Now, one of the core components of blockchain technology is digital signatures and the ability for parties in a contract, in the smart contract, to execute decisions based on those signatures. So that could be issuing a transaction, that could be issuing a vote, that sort of thing. Now, when you think of a DNA contract and having to make decisions in an analog sense, those decisions have to be made by parties, right, in the contract. So if, coming back to this idea of a mortgage, if we have to come out of the automated lane to the analog lane because we need to make decisions about someone's financial situation. It is up to, say, the bank to make that decision

and then bring it back into the automated lane. Do you envision that these terms would have to be defined in the smart contract before it is issued to the blockchain? I guess my question is, how do you establish who gets to make those decisions? Is that based on keys that would be published in the contract prior to it being executed on a blockchain? I think that's probably right.

I mean, we come from the background of trying to integrate the kind of legal relationship into contracts between parties and not the kind of more technical side of exactly how the technology would fit together. but that from our understanding is how you would be looking at doing so. You would agree up front before you put the contract on a blockchain, the circumstances in which people could go in, whether that just be at any time a person can go in and pull it out, that's fine, but you've agreed that up front,

or it could be, you know, in these certain circumstances, the parties can go in and change things or take it out. But whatever you do, you would need to agree with the parties at the beginning, that was going to be the deal. That's right. We're not trying to impose any kind of inflexible idea in that regard. It becomes a question as to, given how much you want to agree like that, how efficient has the use of the blockchain still become?

Is it still an efficient use depending on the fact that you have now got so much complexity in the underlying contract that the amount of time it will spend in automoburn, is not really worth the efficiency gains that you would otherwise have from executing that contract in that form. I'm getting the idea that there's a spectrum. So you have completely traditional contracts at one end, then you have these DNA contracts that are a mix of smart contract automation and traditional contract pros, and then you have pure smart contracts. So you can think of it as a spectrum, right? And maybe some relationship agreements such as a non-disclosure agreement should always be in the traditional contract from because there's not much to automate here. Whereas something like an interest rate swap or a mortgage falls in the middle where there's partly automatable.

The cash flow is automatable while the default scenario is not. And maybe there's a third kind of possibility as well. where a pure smart contract is the best and these might be situations where as you pointed as you pointed out that participants want to transact anonymously and their performance and obligations don't depend on each other that tightly so maybe there's this there's a spectrum and like we're going to see all parts of these spectrum in the future but in terms of the DNA contract what The question that comes to my mind is that you are really proposing a new kind of contract technology, something that's at least today non-standard, maybe in the courts.

Maybe a DNA contract has never been challenged in a court. So how are we sure and how are we sure that this linkage between analog and digital instantiated to the mechanisms of hash functions, etc., will stand. hand up to scrutiny when one of these agreements inevitably find their way into a court process? The reason is because this is just a progression from what we've done before. This is just a progression of contracts that were upheld in the financial crisis under the most rigorous scrutiny that you could have because this is just a mechanism for describing the terms of a contract in a different, and I would say heavily mathematical language, we write parts of

our contracts in mathematical languages already. We have to because the marketplace we serve speaks in that mathematical language. That stands up in court, provided it is clear and provided that there are sufficient experts to tell the court what that means. What we're really talking about is parties can agree the terms of their contracts such that those terms in being expressed in some form, it could be any form of computational code, are more easily performed. But the area of challenge to say that because that part of the contract is expressed in this language, rather than that language, is really to say that if I, had clause 13 expressed in French in an English contract, an English court would strike that

down. No, what an English court would do is find out, presumably, from someone who speaks French, what those words actually meant, because that's what the parties agreed. The same applies to this. We are not trying to choose the technology. We are not trying to change the fabric of contract law. We are just trying to demonstrate that that fabric can be adjusted to fit in with an automated world without changing the very nature of contracts themselves. And we know that the very nature of contracts themselves can be upheld because it is every day. Clearly, you have something to add there? No, I mean, you will have the same questions that come with any contract. So, you know,

do the parties adequately understand the terms, are there unequal bargaining power between the parties? Those questions will still remain. So I don't think that it would be any different because you've expressed part of it in code. Those same questions, well, do both parties understand the code? And are they in an equal bargaining power to understand the code? That's just the same as do they understand this algorithm in this contract today? Or is this contract too complicated for a retail investor, for instance, if you're investing in certain things. You'll still have those same questions.

Indeed, Claire, that's a really important point. The question is not, are these things always enforceable? I believe the right question is whether the expression a part of the contract in this language makes them any less enforceable, because you are not looking for a benefit from increased enforceability. You are looking for a benefit from increased efficiency, and you are hoping that there is no shortfall in enforceability which has occurred as a result. So it's not intended to produce the nirvana of everything will work all the time. It's intended to keep that as a level playing field, but produce the added benefit of having the computational code active when it is most efficient. Yeah. Awesome. I'm really glad to hear this answer because

it means there's not a big roadblock at least on that side for this for this technology so I think the final section we would like to cover some of kind of the like business and technology aspects so one of the first question is originally when when the Ethereum ecosystem was built this idea of smart contracts came the the fundamental driving force or the motive force was the perceived need to remove trust from financial agreements. And many people debated that this wasn't practically possible. Like in a loan agreement, when Scott is lending me a million Australian dollars, there needs to be a bit of trust on my side that I will repay. because if you go on the other end where if you completely smart contractify the process then I would need to put all of the monthly payments in escrow but that would defeat

the purpose of the loan because I don't have the money today if I had the money today I wouldn't need the loan right so you cannot remove trust from a traditional loan agreement and like loan agreements are such a huge part of the economy right so there's a big parts of the contract economy that you can't make trustless. But whether right or wrong, that was the initial motive force for building smart contract technology. Now we're coming to this point where we are saying, okay, we do need trust and we have to accept it and go for analog terms. Now, but what becomes the kind of business proposition for DNA technology? What do you think it can improve? And why do you think

the market would adopt it if it's not the removal of trust? That's an interesting question. because, as you have rightly said, we come at it from a different side, and it really comes down to the point as to what we think, what we see a smart contract as being. And in essence, we think a smart contract is a contract that doesn't need lawyers very much. So the lesser contract needs lawyers, the smarter it actually is, and certainly the more efficient it is. And indeed, that entire framework I described for the international derivatives marketplace is designed to not lead lawyers all the time. So from this point, there is a slight difference in the

philosophy, potentially, between a benefit of having a smart contract and the benefit from something like the blockchain as an engine of trust. And we don't think we're imposing this difference. We think this difference exists in the very nature of the transactions you're dealing with. As lawyers, we don't get to change the world and the way people transact. When we do try to do that, it becomes, we have to be very careful because people may not understand that what they once had is not what they now have. But in this regard, the mortgage is because it has pushed back an obligation of someone, so it no longer is a trade now. It is a payment now for something in the future. automatically create some sort of risk.

And that's what I would be being paid for. Had I lent you the money is you would pay me interest as being the price of the risk I was taking on you. Now, that means that there either has to be a level of trust because that's a fundamental part of that transaction or we mitigate that in a way which effectively negates the entire function of the contract. And that's what you said.

And, for example, you giving me collateral to make sure you would pay the contract, that would be pointless because I'd ask for a million dollars of collateral, please. So I think the point there is in considering what can be moved to anonymous, we are also considering

of which transactions in the outside world have trust as a fundamental part of them. And then the question is, do we want smart contracts to be involved in improving that world, accepting that there is still going to be an element of trust, or do we believe, based on some philosophy, that because trust must remain,

we should not try and improve that part of what people do. We, because we see efficiencies in what people do, think that you should make things more efficient, even if you don't remove the element of trust, but it might be that other people think that that's not the best use of smart contracts. our belief is lots of people will think that the more safety, the more efficiency, the more convenience is very much worth taking a look at applying smart contracts to what they do. Today's magic word is Analog, A-N-A-L-O-G.

Head over to let's stock bitcoin.com to sign in, enter the magic word, and claim your part of the listener award. So if we bring it back to, you know, recent events and the Dow, so recently we, there was the Dow hack, as you mentioned, and you point out in your article, as sort of the base for this whole discussion about bringing human intervention back into smart contracts, in a way, we could see the hard fork as, you know, bringing human intervention. because these decisions were made outside of the blockchain, and then essentially we had a fork, which changed the nature of the code and allowed Dow investors to take their money back out of the smart contract. Can you give us your views and thoughts about this,

perhaps from a legal respect from where you stand? What do you think about this whole Dow attack? and the resulting hard fork. That's a good question. Let me express that in wording from my world. The result of the hard fork is very similar to the result if that had happened in any kind of centralized financial market infrastructure. If we look at the Dow like any blockchain, it effectively from our world is decentralized financial market infrastructure. It's a way that people connect to transact, and that's what we see as that.

Now, were that sort of thing to happen in something that had a clearinghouse or an exchange with a regulator looking over the top, there would be intervention, which would be governed by the rules of that exchange, where the clearinghouse or exchange would say, just a second, that's not the result that's supposed to happen here. We are going to change the rules so that the money is going to go back. and what was interesting from our perspective is it seemed that the hard for process achieved a similar result, although based on our readings of what was happening in the press, there seemed to be a little bit of angst and pain in getting to that result.

And the potential for that sort of result to be, or that sort of process to be set in advance, is something where, which is more analog than digital. So I think your analogy to say that the hard fork is more analog because it is something outside the original rules of the coded contract, or so I understand, is very accurate. And I think the reason that it occurred is also very instructive as to when sometimes you need to look beyond the source of a problem in order to solve it.

That's really interesting. We have one final question and then we'll close down what has, in my opinion, being an awesome interview and a very educative interview. The question is, so today, like DNA contracts

are let's say in their infancy, right? There's probably not a lot of them around in the market. But let's assume a future scenario where they grow out of this infancy and maybe trillions of derivatives and other contracts move on to this form. How does this change the legal services industry? What big change do you anticipate seeing

if this technology were to succeed? I think that it will require us as lawyers to be more aware of different ways that people communicate their transactions. What this has taught us already is not that we need to be know all the complexities of computer code because we always see ourselves more as architects and engineers, but we do have to understand more of the language that engineers will speak in order to work with them. So what it does for lawyers, I don't believe it will remove the need for lawyers. And I don't, I'm not saying that just because I'm a lawyer, but it's because of my belief that the law is just a reflection of what society

regards as its rules. And society will always want some rules that people can't contract out of. We're all part of a society. And so I think there'll be a need for lawyers, but the lawyers will have to be adaptive enough to work out when we engineers could, and I mean software and computer engineers could implement this far more effectively and then being able to speak in a language that those engineers can understand so we can get out of the way and let them do their job and do their job well.

Yes, I think from my perspective it also goes to what you said about there's a spectrum. There's a spectrum of things that is desirable to automate and there's things that are not and there's everything in between. And so I think, you know, lawyers are just there to be flexible. So they're there to be flexible to be able to understand the interaction between both sets of terms. They're there to understand the interaction between when something should be automated or could be automated and when people don't want it to be. So a lawyer is really just a product, I think, of that and we'll have to change and adapt accordingly.

But I agree with Scott. And again, I caveat saying that it's not just because I'm a lawyer. I think there will still be a place for lawyers for a very, very long time to come. I would tend to agree as much as I like the idea of automation and blockchains and smart contracts and all this fascinating technology. I think that in the current system, I do agree that I think lawyers will be around for a long time. I don't think that anybody going to law school right now will have any lack of work in the coming years.

So just before we wrap up here, let's, I mean, we, you know, we, you. You've written a paper about this, which we'll have in the show notes. All of the documentation about DNA contracts and the examples that you've given are available on GitHub. I'll have links to that in the show notes. What is the current sort of technical implementation of this? Are you speaking with any developers about perhaps building a blockchain which would incorporate DNA contracts? At the moment, everything is just open source. It's an idea.

We are really looking for people's feedback as to what they think. It's just something that we happen to think is a good idea from our experience in the marketplace. And we're interested to get feedback from other people. We're looking to expand it into different kind of product areas as well to see how flexible the structure can be and where that level of automation versus analog is desirable. As we said, it will be different in different types of product. It's not just limited, I don't think, either, to financial markets products as well, although they are a really good test case, I think.

In terms of who we're working with and stuff at the moment, we're very much just happy for things to be out there. There are three people that are looking at it closely in their internal systems we know so far, and I'd have to say we've attracted an enormous number of friends that I didn't know we had and different parts of the world who are more from potentially your background than our background and they do seem to be tinkering with it. I should say from our perspective, we're not looking to have KLDM developers doing this because again I come back to the fact that we serve our clients and so it's really a question

as to them determining that whether this can be useful for them, and then us trying to respond to that and work out how we could make changes to make it even more useful. That's right. Great. So we'll have links to all of that in the show notes, and we definitely look forward to seeing how this develops. And maybe at some point this gets incorporated technically into some sort of blockchain

where we can have, you know, blockchains that, that, in the current system, in the current legal framework, would be able to work with things like mortgages, things like swaps, derivatives, etc., which I think probably is very well needed. So thank you so much for coming on the show. Thanks to the both of you. It was a fascinating discussion. Thanks to the both of you. It was great.

Thank you very much for having us. Our pleasure. Thank you very much. And thank you to our listeners for tuning in. We release episodes of Episenter Bitcoin every Monday. You can find us on the LTB network at lesstop Bitcoin.com where you'll find all kinds of great content about blockchains, bitcoin, cryptocurrencies, decentralization, Ethereum, all that stuff.

You can also find us on Twitter at Epicenter BTC. We're also on YouTube. You can download Epicenter Bitcoin with your favorite podcast app on iTunes or Android. We're also on SoundCloud. And of course, you can leave us a tip. a tipping address will be in the sort of description. And if you're looking for one of these t-shirts, you can get that by giving us an iTunes review. And just send us an email at show at episode at like 1.com, and we will get one out to you along with some stickers.

So thanks so much. And we look for it to being back next week.