Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Stephen Palley: Lawmodynamics – How to Sue a DAO

Episode Date: June 13, 2016

For many the promise of decentralized applications and DAOs is to be beyond the limitations and rigidity of the existing legal system. There is no question that where DAOs can roam freely, innovation can accelerate. But can the law, courts and regulations be left behind so easily? Lawyer Stephen Palley joined us to discuss what happens when the new and old worlds collide and how courts will look at what goes on in the land of DAOs and DApps. Topics covered in this episode: Whether trust is reduced, removed or just shifted elsewhere in blockchain systems If creating decentralized applications could create liability risks Why courts will impose a legal structure if a formal one doesn’t exist The concept of jurisdiction and how it could affect DAOs Why one should be careful with saying a DAO provides insurance Episode links: How to Sue A DAO Blockchain Jurisdiction Smart Contracts and Smart Lawsuits Blockchain and the First Law of Lawmodynamics Smart Contracts, Performance and Trust DAO Insurance Company, Inc All of Stephen Palley's LinkedIn Posts EB125 Florian Glatz: Defining a Legal Framework for DAOs EB132 Stephan Tual: A Universal Sharing Network and a $150m DAO This episode is hosted by Brian Fabian Crain and Meher Roy. Show notes and listening options: epicenter.tv/135

This is Epicenter Bitcoin episode 135 with guest Stephen Paley. This episode of Epicenter Bitcoin is brought you by high.combe. Protect yourself against hackers and safeguard your identity online with a first-class VPN. Go to high.comme slash epicenter and sign up for a free account today. And by Ledger, makers of the best hardware security devices. Half peace of mind and knowing your private keys are protected by industry standard physical security. Go to ledgerwalt.com to see the full range of products and use the code Epicenter at checkout to get 10% off your first order. Hello and welcome to Epicenter Bitcoin, a show which talks about the technology, projects,

and startups driving decentralization and the global blockchain revolution. My name is Brian Fabian Crane. And I'm Meheroy. Today we are going to talk to Stephen Paley, who's an attorney based out of Washington, D.C. Lately, he has been writing a lot about DAWs, the legal aspects of DAWs and other topics. I found all of these blogs very interesting, so I'm really pleased to welcome him on the show. Before we start, Stephen, perhaps a bit about your background. Sure, thanks very much, fellas. I'm glad to be here.

I'm a lawyer in private practice in Washington, D.C. I've been practicing for about 18 years or so, both in the Midwest and on the East Coast. My practice is historically focused on insurance coverage for policyholders and particularly in the construction industry. And I've always had an interest in software and software development a couple of years ago. I had a crazy idea for a piece of, I guess you'd call it a negotiation platform, dispute resolution software. And I worked with another lawyer to build something. And in the process, I didn't really know much about modern development tools or modern coding practices,

learn enough about modern development tools, particularly Ruby on Rails, and about software as a service in general to, I would say, may become a little bit dangerous or, I suppose, framing it more positively, to appreciate the wonderful things that software developers and engineers do and to be able to have more of an intelligent conversation. And in the process, my practice has moved that way

in part to working with people to develop what I call compliance-driven software. And as you guys have pointed out, I also apparently can't keep my mouth shut, and I write a lot. And I'm glad that a couple of people have found some of the things that I've written to at least be notable

or interesting enough to object to. And I'm glad to be part of an interesting conversation. Yeah. So for listeners who have never read his blogs, you might want to go to... All of the blogs are on LinkedIn, I think, which probably is not one of the platform of choice in this community, but you can go to LinkedIn and check out all of the articles

that talk about how DAOs and like, you know, the legal uncertainty surrounding it. And then there's another article which lays out one of the principles Stephen has developed, which is called the first law of law more dynamics, and we are going to walk through that concept as well. But Stephen, how did you get interested in this field? What brings you to our part of the universe? You mean blockchain smart contracts in general?

Well, I also, because I'm a lawyer, I have to give a little disclaimer. Although I'm a lawyer, none of this is, it's kind of irritating. Like, if you know me, you can almost say it for me. None of this is legal advice, and I'm speaking, these are my own off-the-cuff opinions. None of this is approved or agreed to by any law firm that I might be associated with. And if I have any clients who are watching this and they disagree with what I'm saying, I'm sorry, but I'm not speaking for them.

So how I got interested in blockchain, smart contract, it's a, it comes in part out of an interest of making law more efficient and automating things. And a couple of years ago, I ran across a fellow named Casey Coleman, who a lot of you know who is now with Aris, which they've had wonderful success. for which I'm very, very happy. And I think I probably heard the term smart contract versus Casey. And if you were on this, he would point out very quickly, they're neither smart nor are they contracts. But I became fascinated with the idea of process automation, which is part of what the project I worked on, which is defunct, though it still lives on in code, impasse breaker, was about the issue was, how do I take settlement negotiations, which are ultimately about finding a bottom line that everybody knows to? and instead of spending months and months or years and years nickel and diming one another, is there a way to automate that?

And I think that whether you're using a distributed ledger or not, whether it's blockchain or not, what is incredibly interesting to me about the technology and about code itself is how it takes, how it provides the ability to automate performance. And I think that's what has gotten me interested in blockchain and smart contracts. And I think the Ethereum world or community is particularly interesting because there's so many smart people who are working at it and who are interested in this, taking processes, complex processes, and putting them in a code. And I don't think it ends up getting rid of lawyers necessarily, but I have to tell you, I mean, if that happens eventually, I think I may have said this last. night. If anybody's out there as read Herman Hesos, the glass bead game, Magister Ludi, if it all means that eventually I'm coded out of existence, there are no disputes and we get to

sit around in white robes playing math games with glass beads, I'm okay with that. So I don't see it as a threat. I actually see it as an augmentation. I'm not sure that always comes across. I think a lot of lawyers probably feel that way, too. That was a very long answer to a short question, which I think I'd probably be guilty of frequently this evening. Cool. Well, we certainly love that. So you mentioned performance here. One of the phrases that is often used when describing a lot of these things that we're doing here and that blockchins and smart contracts accomplishes the idea that they remove kind of the requirement to trust or they are trustless.

What do you think of this term? And does that relate to what you mean when you do? talk about performance? Yeah, that's interesting. Did you mention the first law of Lamuodynamics a second ago? Reaches might have, yes. Should I talk about that? Please do so. Or am I jumping too far ahead? So I'm really interested in the idea of trust because it's something that is part of negotiations. And I'll give you an example. It's a little bit of a war story, which lawyers are guilty of. This involves the first case that I settled as a baby lawyer years ago. And the other guy on the other side, let's call him, his name was Wally.

And it was a $10,000 property damage claim. I'm practicing law for maybe two months. And I had, I don't know, $2,500 on the table. And he was at $12,500. And I said, Wally, why we just, like we both know. I was like, I knew. I was like, the case settles for $7,500. But we were like, oh, $100 a time. I was like, well, why don't we just go right to $7,500? And what he said to me was, I'm pretty sure he said, kid, he said, kid, you got to dance to dance. And the reason you got to dance to dance is because nobody trusts each other, right?

Because if I put my cards on the table and it's $7,500, how do I know for sure you're going to? Right. So negotiation is all about, there are ways to get around that, but it's all about trust. So the idea of a trustless system is one where it's sort of what I initially set out to design is where you can remove that. You can create a system where I don't have to trust the other side because something neutral that doesn't have a bias and doesn't care is going to take care of it for me. Now, the first law of law on dynamics says, however, that risk or trust, they don't,

you cannot engineer them out of any system. They go someplace. So I think you should stop me if you want at any point, but I was going to go to the story that we were talking about before we went on the air. So when I hear trustless, the words that, the word that comes to my mind is riskless. And I think about something that happened to me about what years and I don't even remember. What are we? 2016? Yeah. So this would have been about, I don't know, 10 years ago.

And before that, several years earlier, I'd spent a lot of time in a very quiet anonymous office in the middle of the United States and a very low-level firm handling some very insignificant, except for the parties involved, real estate litigation. And I went through lots of loan files. And these cases were very sad, and they often involved people losing their houses. And I looked through these files, and I saw things that I didn't understand. I saw parties called nominees. I saw something called MERS, which I think people know of as a disease. Other people know of it as basically a clearinghouse in the United States that was set up to repackaged loans make the transfer of mortgages easier. I'm oversimplifying greatly.

Anybody who knows what it is is probably cringing now. So forgive me. But it didn't really make any sense, but I figured I didn't understand something. And what I came to understand was part of this mechanization. has been come to exist in order to support a mortgage securitization business, which had taken on the life of its own. And I had a conversation about 10 years ago with a fellow in New York, who was with a really big fancy investment bank, and he was talking about these things, collateralized debt obligations,

mortgage-backed securities, and he told me that they were riskless. and I was explaining you take a thousand mortgages, you put him into an instrument, you create a trust, you have insurance, you over collateralize, the holders of the debt can never lose money. And I asked him,

I said, what happens if a bunch of the mortgage holders can't pay and you need to foreclose? And he looked at me like I was an idiot who crawled out from goodness knows where and didn't know the first thing in the world about finance, I should go back to the provinces, blah, blah, blah.

And he said, it's riskless. We over collateralize. We use financial engineering. We created tranches. We've got insurance. And two years later, everything went kaput. So when I hear trustless, I think the same thing. Like the risk didn't go, it didn't disappear.

It went someplace else in the system. And it's the same thing with trustless, any sort of trustless, trustless peer-to-peer currency smart contracts, it might be that we can take the need for you and I to trust each other out of a system, but we put the trust into math, into something else, into minors. So that's what I think of when I think of trustless. I would also ask you guys, I would put it back to you, is there any advantage in calling something like Bitcoin or Ethereum trustless?

Do you need to? Just before that, I would like to ask you one more question on that. So I get your point that the trust doesn't go away, and I agree with that. I think that's true. But would you agree that the requirement for trust can be reduced and risk can be reduced? Well, reduced from what? Can we locate it? Can we move it?

Can we identify it? Can we centralize it in an algorithm? Yeah, but think about it. There's an interesting analogy with electricity. And I can't remember where I heard this. It was an interview some years ago. Basically, what this person said was, look, I mean, you can distribute the risk from power generation by having plants all over the country, right?

Coal, gas, whatever. And that creates a certain environmental footprint. But if something goes wrong in one plant, it might be bad, but it's not going to be catastrophic, or you can focus all of that risk and a couple of nuclear power plants, where you're able to control it greatly, right? You have a lot of control over the risk, and you can use engineering to manage it, but if something really bad happens, it's always going to be really bad. So I don't know if you can reduce it. Maybe you can. I think you can locate it, though, and maybe you can remove it from you and I, and you can put it into an algorithm.

or you can put it into miners, or you can move it to cryptographers or cryptography. But I'm not sure that it is reduced. I just think it moves. Having studied chemical engineering, actually, we kind of have a version of this. I'll try to explain, like, the first law of law mode dynamics in using an analogy from, say, building a dam or building a dyke. So imagine you have a river that, you know, that is an unstimely. stable river, it changes course every year, like the Yangtzee in China is like that, right? One year it's flowing one particular way the next year it will flow somewhere else. It keeps shifting.

The issue with rivers like that is if you build your house next to the river, next year it shifts, your house is going to get flooded. So if you build your house in the plains of such a river, you have risk that someday the river is going to shift and it's going to flood your place. now so imagine like very old times you know we face that this humans face that risk now then came the invention of dikes and dams now what with dykes and dams what you can do is you can take a river like that and you can force it to always go into one path you can you can you can build structures that you know always force it to go one way and so it doesn't keep shifting every year, right? And so the obvious, the thing that humans perceive is that the risk has reduced, the risk of flooding has reduced. Now, what happens when people perceive that the risk

of flooding has reduced? People build a lot of houses in that plane, right? They're going to build like earlier sale there's a thousand houses, now they're going to be like 100,000 because everyone perceives the risk is reduced. But what a, what are the, also happens concurrently with this reduced risk is in one once in 100 years there's going to be so much rainfall that there's going to be such a huge flood that the river is going to break the dam or the dike right the human structure is not going to be able to take all that water and it's

going to be broken and then the river will flood the complete plane and it's going to kill everyone who built a house around it so the you reduce the occurrence of the disaster, but at the same time you actually increase the magnitude of the effect when the disaster happens. So in a sense like the first law law modernics I think tries to capture this, right? Like we can reduce the risk of some bad thing happening, but then all it does is maybe the disaster is going to come later and it's going to be way bigger.

And if you multiply these two, the risk of a disaster, multiplied by the impact of a disaster, then that is kind of constant. All you can do is you can go low risk but of high impact, but you can go low impact, but higher risk. But that multiplication factor kind of stays constant. Exactly. And that's a beautiful analogy. And I guess what I would say there is when you recognize that, that engineers don't design riskless structures.

What they say is we're building a 200-year dam. But you need contingency plans, and you better maintain it. So it's the same thing. What I worry about in talking about something, or people can call things trustless if they want, but I would very respectfully suggest that it's important to think about contingency plans and also to think about engineering principles. I mean, how do you know, according to whom?

What are the risk factors? What happens if something goes really bad? There was a recent piece published by R3 by Vitalik Buteran. One of the footnotes actually talks about a potential risk associated with trusting miners. And look, I'm not a math expert or a crypto expert. I'd be bullish to try and tease that argument out. but I think it may be footnote one or footnote two. It does intelligently, which is not unexpected, raise the question of where did the risk

or where did the trust go in this supposedly trustless system. I don't think there's anything wrong with saying trustless for a particular purpose but not trustless completely. So that's where I get. That's where I go when I talk about the first law of Lamo dynamics, basically what you've just described may be better than I did. Let's take a short break to talk about hi.comi. 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. We would like to thank Hyde.m.

For their support of Epicenter Bitcoin. I think there's kind of two sides of this. I think on the one hand, you're certainly right that the term trustless is kind of misused. With Bitcoin, this was always kind of super obvious in the sense for me. Like if you look at mining, right, then you trust that those miners are going to go back and do a 51% attack, right? Which is something that's very hard actually even to assess what's the probability of that. Because you don't know them, you don't know exactly.

know what their incentives are. So I think saying that the term trustless is misplaced makes total sense. Of course, also, you know, who actually audits the software that is being run, you know, basically nobody or very few people, except for a few projects. So there's risk there and maybe risk on the hardware side. And so there's all kinds of risks. But I don't think it makes sense to say just there's some sort of constant quantity of risk and it just gets shifted around, I do absolutely think you can't reduce and change the magnitude of that. So, and I guess it's an interesting question. Oh, is this whole endeavor, this blockchain project, is that something that is trying to accomplish that, right, to create a reduction in the,

amount of trust required. Maybe that's one way to think about it. But I don't buy the point that it's just sort of, it's always there, it's just, and it's always there in the same quantity, and it's just sort of morphs where it appears. Yeah, I mean, so look, I'm being kind of literary and sort of maybe too cute by half. I acknowledge that. I don't know how you mathematically quantify trust or risk. I'm sort of trying to make a point, perhaps by exaggeration, which is whether or not you can quantify, whether or not you can mathematically quantify trust. I'm not sure you can get rid of the need for it someplace.

And maybe it's better to put trust in an algorithm, though I'm not sure. It depends on the algorithm, and it depends on the standards that we're using. What I like about automation, whether it's a cron job, whether it's something written using Ruby or solidity or it's blockchain or not, is predictability and process automation.

And the same thing with that, the thing I like about distributed version control, like Git. It was like when I saw GitHub for the first time, it was like magic to me. You know the history, you know the revision history. Now I know you can play with that, right? but I love the idea of revising things that way. That has nothing to do with, I'm not sure that I need to call that a trusted or trustless system. To me, those aren't necessarily helpful words.

Okay, so we've spoken a bit about trust and that that doesn't disappear. Now, kind of maybe the flip side of this is the question of liability, right? So things are going to go wrong. Smart contracts are going to lose people's money. And a lot of these people are now developing contracts, then they'll run themselves. So how do you think about the question of liability in these systems?

So the world's a really big place. How many countries are there? 180? I don't know. So let's say there are 180 countries. Maybe I'm wrong. And they're, let's say, in the United States, there are 50 states.

I'm only licensed to practice law in four of them, and I only have active licenses in three, and the law is different in all of them. So I'm necessarily going to speak in a very generic sense. Part of the answer is, you know, it really depends. I used this analogy last night at the Ethereum meetup. I think people may find that response irritating until if you're a developer, if I were to ask you, what's the best language to use? What's the language that's going to be less like?

It's going to allow me to create something that I'll, fails less frequently. Is it going to be C++? Is it going to be Haskell? Is it going to be Ruby? Is it going to be solidity? What should I use? Should I use it? You're going to say it depends. And sort of the same thing here from the standpoint of coming up with single answers to questions. So having given you that really long caveat, which is probably irritating, let me see if I give you some general guidance, the way I look at it. So code in and of itself is just that. It's not sentient. It doesn't have legal existence.

It's not a person. It could become a person if it's a part of a corporation, which in most places is recognized as an artificial person. If a programmer creates something that is flawed or balky in the United States, they could, and their flaw is an actual and proximate. cause of harm and they cause someone damages. They might be liable in tort under a negligence theory. It's possible they could be liable under a strict liability theory, under products liability law. It's also equally possible that there could be a contract claim if they were in privity of contract with someone. It's open source may be different. You may not have a contract, but under certain circumstances, you may be deemed to have a duty or an obligation to

not do things that cause a lot of harm. So here's an example. I sent a copy of this article earlier today. It's an incredible article. It was apparently funded. This research is funded in part by oh, what's his name, Elon Musk. And it's called, what's the title of it? How to Create a malevolent AI? I mean, it sounds crazy, right? I mean, it's a wonderful article. scary and hilarious at the same time. And, you know, basically what these guys say is, so there's been a lot of talk in the security community lately about preventing things,

but, like, we don't really know what happened if there was a malevolent AI, so maybe we ought to think about creating one so we can know what to do if one shows up. Be kind of like creating a super virus to test. I'm not passing judgment, although it sounds like I am. I don't want to be forcibly cyborg. which was one of the parts of their risk matrix, that would be bad.

So I'm good with preventing this stuff. But I guess, you know, it's a roundabout way of saying, what would happen? Like, what would the theory be if somebody created an open source malevolent AI, pushed it up to GitHub and the thing caused a lot of harm? I think there are, in a common law system, I can imagine lots of ways to go after those people who probably only meant to do good, but maybe ended up doing a lot of harm. Part of something to think about too is just because you do something for free doesn't mean someone can't sue you. You know, sometimes it's the stuff you do for free that causes the greatest harm.

So kind of going back to a sort of more narrow response, if I were a developer and I was creating things and I was giving them away, I probably would think about what could go wrong because things can go wrong. And I would not assume that I'm going to be scot-free or free from liability. I think there are ways to be liable. Does that a specific enough answer? I feel like I don't want to be too vague. So feel free to beat me up a little bit and make me be more clear. It makes complete sense, right? Like, let's take a few examples, right?

So the simplest examples we might take is Ethereum Foundation. right those guys went and created guess and and that get software basically kind of underlies the whole Ethereum network at least today right and nobody in their right minds none of the authors in their right minds would ever say that this software is always going to work in all situations right there could be consensus bugs there could be things that lead to a fork in the chain that lead to like nasty scenarios and people end up losing their money or losing their sleep or whatever, right? I mean, nobody would in their right minds would deny that this possibility exists. So I actually like agree that, you know, there's always the risk and as an engineer, you always

kind of accept that whatever you have created has that risk, right? Now, the hard problem is when somebody is making something open source and you don't know who is going to end up using, it because suppose I'm creating a CDM or the next cryptocurrency, I don't know, then I don't know who will end up using it and they could be spread across all of the jurisdictions of the world

right? How do I and in principle I accept my I accept the risk in what I'm creating how do I kind of ensure myself against liability? Yeah, so there's a concept in

U.S. law and I'm not an English lawyer but I think the Brits follow it too. Maybe they don't. I shouldn't speak of British law, but at least in the tort context of reasonable foreseeability and duty, at least in the tort context, if you're giving stuff away,

there's no contract. And I guess the question would be to, if you created a malevolent AI and gave it the ability to attack life, health, and safety systems and actually wrote that code, I don't know, maybe it's reasonable to, and you didn't bother building any security so that nobody,

you didn't bother building an off switch. I can see a tort claim against you. Let's say you wrote a, I don't know, some sort of better CSS, right? Like, you managed to like, all of the beauty of, or maybe not beauty, but all of the utility of, what do you call it, bootstrap, but in 10 lines, 15 lines, I don't know, you're a genius. And somehow there's something about the code that causes somebody's application to crash someday, and because it's been incorporated into,

I don't know what, somebody balks their nose on a door. I mean, that's different, right? So you have to look at what the application is, maybe what the reasonably foreseeable use is and what could go wrong. That's kind of the way I would look at it, like what's the range of what could go wrong? How could people misuse it?

And I'm not saying that giving stuff away to people who you don't know necessarily is going to mean you're liable. We just, we don't know. So you have to, I mean, part of it is use common sense. I mean, it's a lawyer's best friend too. If you build stuff that's really nasty and inherently dangerous and you give it away and it's used for bad purpose and someone dies, I mean, maybe you should be, maybe you do bear some responsibility or liability for that.

I'm not sure there's anything wrong with saying that. I think a lot of very smart and responsible programmers would agree with me. So there's no silver bullet to this, right? Like there's no, there's no method left. There's no process by which, like, I built something and, and you can, and somebody can come to me and say, okay, Meher do steps one, two, three, and four. And this will guarantee that you will never be held liable for what you have built and give it away. You know, if I could predict the future and I could tell you the law,

of every country in the world, I might be able to do that for you. I think the best that you can do is it's a matter of probabilities. And there are ways to, I mean, again, it comes back to the, it's impossible to create something that is risk-free. Do you ever read Nassim Taleb's Black Swan? The Black Swan? There's a great book. And basically what he says in that is essentially in boiling it down is the only, the only, the only certainty is uncertainty.

And it's a question of managing that. And I think that's true for every profession. If you don't mind, I know we want to go on to talk about other things, but he uses an example, which I think is wonderful. He goes to Las Vegas, and he talks to a casino manager, and they talk about risk. And the casino manager says, basically, I'm paraphrasing, he says, you know, we don't actually worry about making money or losing money. we understand that, right?

We get how this works. He said, what I worry about is the things I don't know, and I can predict. Like, for example, the person who fails to fill out a license application to the state and causes us to almost get shut down. So there's no risk manager out there in the world, I think, who would tell you that you can come up with a perfect hedge. If there was, I mean, I think I'd probably become, I'd be a very, very wealthy lawyer, right? because I would have the answer to everything.

We'll talk afterwards, right? Today's magic word is collision. That's C-O-L-L-I-S-I-O-N. Head over to Let's TalkBitcoin.com, sign in, enter the magic word, and claim your part of the listener reward. We've been speaking kind of about smart contracts in a very general way, but now there is a whole bunch of activity around the concept of a DAO, decentralized autonomous organization,

which does have some interesting features, right? Because you can really kind of neatly separate the creation of the code and the operation of the project, of the enterprise, right? So somebody can write the code and then somebody, an entirely different group sort of goes implemented. And then those people all may be totally anonymous. they may not actually be sort of involved in the implementation itself as it kind of runs on Ethereum. Of course, the DAO, which we've done now a few episodes on already, being the most famous example of that.

What do you think of that? I know you've also written about some of the legal risks around that. Yeah, so I don't want to single out any particular DAO, big or small. what I would say is that I see one of the words I, I mean I knew the word before, but one of the words I learned from developers early on in my more recent journey in this world is iteration. And software development is an iterative process. I think that's very useful. So I don't think it's fair to criticize a DAO framework, whether it's called standard or not, for not being perfect.

It's version one of version two. You have to look at it for what it is. And I see the thing about the DAO that I think is interesting and useful, I think you see some of this in Christoph Jempsi's paper, which is the notion that you can automate governance. And I certainly don't speak for Christoph or any of those folks, and they might not share my view on this. but as a lawyer, the interesting piece for me is how that code can automate what an organization does and how it operates.

And by doing so, remove the need for trust between people because their relationships or the relationships intersay between themselves is placed in code. I think it's a very heavy lift to expect at the outset to be able to take, an entire governance structure and put it into code. It's complicated. And in our presentation last night, I think it was Sean Murphy, a very fine lawyer at, and excuse me if I've gotten his name wrong, at Norton Rose, described the DAO as, I mean, I think of it as you've got DAO code, which is dry, sits someplace, then you have the DAO once instantiated. It's instantiated by someone, then you have the DAO as the relationship between people, which is, I think, would have the way Sean described it. I think it's very, very useful. And so what, I know there's

been, there's been some heated discussion and conversation online among people about the best form of governance. I've been impressed by, you know, aside from some of the things that had unfairly been said on Reddit about people, I've generally been impressed by the level of discourse, even when people aren't agreeing with each other. I think what you have to do is continue to iterate. That's something that lawyers do, and I think that's something the developers,

I think it's something that we have in common. So to focus a little bit more specifically, you wrote once in one of your articles that when you hear some of the language of the DOO's, what you're thinking about is, well, they're avoiding, forming a sort of a traditional legal structure, but the implication of that is just that the court is sort of going to assign you one.

And the one that you mentioned there was the structure of a general partnership, where you said then people would be kind of liable. First of all, that would have very serious, implications, no? And is there a way around that? So very simply, just consistent with what I've always said, if you do not create rules or an organization, it is possible that in any venture, a court will impose those rules upon you. I'm not saying that any particular DAO, any particular place in the world has to have any particular organization.

I'd be providing legal advice to people if I did that, and I'm not going to do that. I'm also not going to speculate about what any particular court is going to conclude about any existing DAO. Here's what I'd say, though, something that I said last night. This goes back to the idea of the risk goes someplace. If I were getting involved in a venture that ultimately had people involved as stakeholders, I might like to know what rules apply. And some people may be comfortable thinking that it's enough to have some smart contracts, controlling things. Another way, which might not be right for everyone, to manage the risk associated with being a default

on incorporated association or a partnership. That might not apply in every country in the world, but one way to deal with that is create a standard corporation, have a meeting, have a resolution attached to which is some smart contract code, which, and that smart contract code would include certain governance rules. Have an old-fashioned vote of an old-fashioned entity to place a portion of your government, on A or the blockchain. Everyone votes. Everyone agrees.

Boom, you have an old-fashioned entity, which has new-fashioned, newfangled governance. Now, the response that I've gotten from some people, and it's fair. I'm just this is that I'm missing the point, the beauty of automation and that people don't need these entities anymore. That's not for me to say. I'm just saying the risk is if you don't have an entity, something goes bad and your DAO decides to create a malevolent AI and decides to rob a bank, you know, it's possible that you could have some risk or some exposure. One way of managing that is to pick a corporate form. That's not a

perfect hedge, incidentally. You can break through a corporation under certain circumstances and get at the participants or a partnership. I think what's more important is to ask the questions unemotionally, rationally, and make a decision. And maybe, you know, there's nothing wrong with asking the question and deciding that you don't care. I mean, you just have to be willing to face the consequence. That's up to, it's not up to me, it's up to others. So what I'd like to clarify for some of our listeners is, so whenever, like, a group of

people are doing an activity and they don't assign a corporate form to the activity, right? then it's like an unincorporated association of people doing something. Then the challenge is that if somebody sues the group as a whole, then the law enforcement system can come after you individually, right? Yeah, I think it's important not to generalize internationally. That can be a risk, and that's a risk of a, in the U.S. sort of a default general partnership. But there's a piece I wrote, How to Sue a DAO, which I probably should have called how to be involved in a DAO and protect yourself or how not to be the guy in footnote three. If you read the footnotes, I give a little war story in it about being in court and seeing this poor guy end up getting stuck with a lease that somebody else had signed that he knew nothing about.

And it was because the court found that they had a general partnership. The court looked at their conduct, their behavior, and decided that it was sort of a default general partnership. and as a consequence, that party B was responsible for stuff that party A did, even though party B didn't know about it. Again, I want to stress, I'm not saying that is always going to apply to every DAO or that it applies to any DAO right now.

All I'm saying is might, and you might want to think about it. And there are solutions, or at least, you know, know your risk. That's, um, associations are slightly different than partnerships under U.S. law. And again, in some countries, you know, there might be an Italian lawyer or Estonian lawyer

or a Kenyan lawyer listening saying, you know, Palli's all washed up, he's got it all wrong, there are solutions under Kenyan law or Liechtensteinian law. And, you know, that's the hard part. It is really hard. I said this at some place sells, distributed presence can create distributed liability. and if you're a big company, let's say you're a Ford or your Apple and you want to distribute your product in 180 countries,

you probably are going to follow the law of each of those countries and get opinions in each of those countries, right? It's expensive. It's kind of the way the world works. So if you don't do that, you take on a certain amount of risk. Let's take a quick break so I can take it to Paris. I stopped into the ledger offices and met with with Eric Larchavek, Ledger's CEO, and he filled me in on the upcoming Leisure Blue. In early 2016, we are going to release the Ledger Blue. This is a personal privacy device which runs on a SETU elements, has a touch screen, NFC, Bluetooth and USB connectivity, and it will be a full-fledged hardware wallet with a second factor validation of the transaction directly on the screen.

It will be fully open source, you will be able to add your own apps, and it will also be compatible with Fido Second Factor authentication. Password are going to disappear, and it will be replaced by this kind of cryptographically secure authentication. The ledger blue will be certified by Fido and will give you the possibility to login on any website very easily just by signing a cryptographic. electrically secure challenge. Ledger is making hardware wallets easy and convenient without compromising on security.

If you want to get a secure setup for storing your Bitcoins, go to ledgerwalt.com and use the code Epicenter to get 10% off your order. We'd like to thank Ledger for their support of Epicenter Bitcoin. So another topic that is somewhat related to the deal, or can be at least, but has been sort of in this space for a long time, is the idea of token sales and crowd sales. And of course, those could be either conducted by sort of projects that aren't really DAOs, like let's say, for example, the Ethereum Foundation back then, or now they have been conducted, for example, by the DAO, and I'm sure many, many more will follow.

What is, do you think those are legal? Are they, you know, specifically on the US law? Do you think they are sometimes legal? And what kind of makes a difference here? of whether they are okay or not? It depends on the jurisdiction. I'm sure people who are familiar to the space are familiar with the Howie test.

There has been plenty of written on the subject. I would not want to speculate about securities law risk for any particular DAO. I would simply say that those laws exist for a reason, and just because something is digital doesn't mean that it is outside of the law. Anyone who thinks that is free to think that, but it's what I call VHT or vacuous happy talk or delusional. So people are free to reach their own conclusions. I think it is there's a wonderful paper by, I can't remember who wrote it.

There's been some really good work in this space, and I think you can do things that involve. I mean, a token is a, it's a database record, right? Sort of? All right. Yeah. Look, I mean, it's certainly possible to have to,

if it's a database record, database record isn't inherently anything. The question is, if you're selling people a database record, what do they get for it? And talk to a securities lawyer. That's what I would say. And, you know, be careful. Just because there's some, I don't have the site in front of me, but something I wrote recently, basically a judge said, it's like the judge basically said, yeah, I know, it's new. We've dealt with new things before. I mean, the law is what the law is. And this is something that was true 100 years ago, 500 years ago.

And the law did change in response to the printing press. You had the development of copyright law and the statute of N really interesting. Totally off topic. But it's not like there aren't laws on the books. Maybe they'll apply in some cases. Maybe they won't. So so far there's been a lot of those.

and so far there hasn't been any real action from SEC or others. Do you know, does that mean they are okay with it? Or is there just such a long lag time? I'm checking my telepathy. Wait, wait a second. I'm like trying to hack it. Yeah, I mean, so I will say this generically, and this isn't necessarily related to DAO or blockchain.

Law takes a while, but limitations periods are long. Just because something doesn't happen in a day doesn't mean it isn't going to happen eventually. And again, this is just a general principle. I'm not, I am not singling out any blockchain project. This is just a, it's a good thing to know just because you do something and you don't hear response from law enforcement the next day. It doesn't mean that you might not hear something a year. year later. It depends what the statute is. There are some long statutes of limitations,

and you have people who have lots of things on their desk, and they've got time. And sometimes, you don't hear anything because people are investigating. I honestly have no idea. I, you know, that's basically what I would say. There have been prosecutions involving Bitcoin, of course. And in the U.S., the decisions, which you may or may not be aware of, the courts have said, Bitcoin is essentially it's a cash equivalent or it's currency, right? So it's not like courts haven't been able to understand what Bitcoin is. And I think the same thing. I haven't checked in about a month, but the last time I checked U.S. case law,

I didn't find any references to Ethereum. It's probably still the case. But, I mean, it's a question of like, what do you do with it? If you used Ethereum, if you used Ether to buy something illegal, it wouldn't matter that she'd used a distributed database entry to do it. It would still be, you know, likely that would still be a problematic transaction. I'm sorry, I can't give you an absolute answer. I just, I think anybody who tells you that they know for sure is either lying or they work for the SEC or, you know, regulatory agencies anywhere. I do think, like, if it were me, I would look at the people who are involved in the project.

I would look at their track record. I would look at governance. I mean, you can tell a lot about things by the people who are involved and by their behavior. So another topic we would like to go into is this notion of jurisdiction. Right? So first of all, like, let's let's kind of have a rough idea of what is the notion of jurisdiction for courts. And the reason we want to go into this topic is we want to drill down into how a court could assume jurisdiction over a DAO's activities or not. How this could happen. So first of all, but we should go into what is the notion of jurisdiction for courts? Sure. And I'm speaking as a U.S. lawyer by general principles of U.S.

law. And it's been on somebody, there's some been wonderful comments online. Americans always think that the rest of the world is just like them. I really don't. I'm actually sitting in England right now. Great country. I think the rest of the world is wonderful. I just don't know law from somewhere else. So I apologize. I'm not assuming that U.S. law is coextensive with the rest of the world's law. I mean, it would be useful. I could like give you blanket answers if it were true. Again, to my lawyer brethren elsewhere in the world, if it works differently where you are, that's cool. You know, please say something. Generally speaking, jurisdiction is the power of a court to decide things.

And I wrote something about this recently and distinguished between different kinds of jurisdiction. You've got, ultimately, you have to have subject matter jurisdiction, which means the ability either granted by constitution or statute. to decide certain kinds of disputes. So, for example, the U.S. is a federal system. We've got federal courts and state courts. Federal courts are courts of limited jurisdiction, and their jurisdiction is provided by the Constitution. Article 3, there are also statutes that grant jurisdiction.

One type of jurisdiction is called federal diversity jurisdiction. And in order to file a case in federal court in the United States under diversity jurisdiction, I have to have at least, pardon me, I should have turned off Twitter. Meher, you're tweeting. You're multitasking. In order to have federal court jurisdiction, you have to have, no plaintiff can be a citizen or resident of the same state as any defendant. So I have to be like, for example, if Stephen Pally sues Meheroi, if I live in Maryland and you live in Maryland, I can't, the court won't have subject matter jurisdiction over a dispute between us under

diversity jurisdiction. Another component of diversity jurisdiction is the amount in controversy. Let's say you and I are citizens and residents of a different state, but the amount of controversy is only $25,000 exclusive of cost and interest. If I sue you, there's still no diversity jurisdiction, which means the court doesn't have subject matter jurisdiction unless some statute applies. So that's the first issue. Does the court have subject matter jurisdiction?

And there are lots of federal statutes that provide courts with subject matter jurisdiction. Another type of jurisdiction is personal jurisdiction, or if you like Latin, impersonum jurisdiction. And impersonum jurisdiction or personal jurisdiction is the right of a court or the power of a court, which has subject matter jurisdiction to impose their authority on a person. If you're present in a state or in a federal district, a court may have personal jurisdiction over you by dint of your presence, and you can then be served with a summons and complaint that way. If you do certain things in a jurisdiction, a court may by statute have personal jurisdiction over you, and that's by something called in some states a long-arm jurisdiction. So if you go to Kansas and you commit a tort in Kansas, or if you sell insurance in Kansas, not licensed in Kansas, I just happen to like it.

It's not as flat as people think either. You might be subject to a lawsuit in Kansas, even though you're not a citizen or resident of that state and you're not present there. But by doing certain things there, you've in effect consented to personal jurisdiction. The court can also have jurisdiction over things. That's called in rem jurisdiction. and that can happen if there is a piece of property that is subject to a dispute but no person can be found. And there are cases, actually there are some cases which you'll see where Bitcoin has been sued. So those are sort of the first principles.

First, the court has to have subject matter jurisdiction. It's got to be something about dispute that it has the power to decide. Then it has to have personal jurisdiction. And you can't create subject matter jurisdiction. I had a case involving a dispute between somebody who, was, I don't know, I think they were in Belize and somebody who was in another state in the United States and they filed a lawsuit in federal court in Missouri. And the court, you know, the lawsuit had a forum selection clause of Missouri. And the court was like, well, there's anything to do

with Missouri. And I've got better things to do with my time. So you can't fabricate subject matter jurisdiction. So, you know, there are limitations. So like this, this notion of jurisdiction seems to be like one of those themes that will come up once like I think like for me I think there are going to be cases people trying to sue DAOs and all and I think this this this this this notion of jurisdiction is is very interesting because I think like I think if if there's some guy who's involved with a DAO and somebody else outside the Dow is trying to sue the DAO and get to this guy then perhaps the the lawyer of the guy who is inside the DAO, part of the DAO, can use this notion of jurisdiction to try to argue,

right, that the court doesn't have jurisdiction over the defendant. Yes. This, like, this notion of jurisdiction seems to me like one of those things that's going to be fought out in court and clarified when the court has jurisdiction over it. Any lawyers who are listening would probably tell you this is, you cover this in civil procedure in the first year of law school. I'm not actually saying anything that's very wise or brilliant. I'm just providing basic what's known as Hornbook Law. These are really, really simple principles. A lawyer doesn't have to know anything about code to understand that. Now,

what's interesting about them is, not to get too far afield, it's actually not, I mean, I'm kind of talking, these things are subject matter jurisdiction. You can think of it as a class, and within it there are different subclasses that inherit. I mean, there are things about this that are very, very similar to code, and there are actually things about this that would be interesting to put into smart contracts eventually, because some of what courts do is decide whether they have jurisdiction. And I think some of it could actually be automated, interestingly. I don't think we'll see federal courts doing that in the next couple of years,

but I think there are a lot of judges who would be perfectly happy if that portion of their adjudication was automated or simplified. It would certainly do a lot for docket control. Are there other things at the intersection of traditional contracts and smart contracts, like structures that can fuse the two and create something that is useful? Are there like parts of that space that are interesting to you? Yeah, so again, I'm at the risk of embarrassing. I probably wouldn't listen to this anyway,

but I got this term from Casey Coleman, and that the notion is dual integration, where you have dry code and wet code, and where you put as much of the automation or latticework or framework as you can into software and automate certain things, but there's certain parts of contracts that will remain outside of the software. And that might be, those might be, you know, general conditions, terms and conditions.

It might be, you might have a variable. Let's say you've got a struct that is contract, and within that you have a variable, which is the contract, and it's actually, it's, or general conditions, and it's a PDF. You're pointing to a PDF. That is something, but you've got, you. You have variables like, you know, starting date, ending date, daily payment, contingency. Those are all things that can easily and probably are already included in solidity smart contract codes. So that's a structure that I think as useful.

And, you know, if I were, you know, and if I, and as I think about building these things, what I would do is look at traditional contract forms and start peeling away the things that can, be performed automatically. But I would also think about ways of being comfortable with keeping certain items in the, I think you would call it the wet code outside of blockchain. Everything can't be automated, right? I mean, it's particularly things that are off chain. I mean, they're hard. There's something wrong with that. Doesn't mean you can't happen eventually, but iterate, right? Take your time. Okay. So, so yeah, like this team is, of one of the one of the things that is I think special to Ares industries like it's

it's like one of the few companies that are you know can in their blogs and all kind of come out with with this view with this notion that you can have integration between like wet code and dry code and combined they can do something that is that is much better than wet code or dry code alone and I and I find this like a really really powerful notion because like there are many things in which you almost seem to need wet code right like think about a mod gauge right so I go to a bank and I ask for a loan to buy my house now in this case a smart code just a smart contract is pretty useless because in the future I need to make payments into the smart contract because I took the loan but the smart

contract does can't kind of if I if I stop paying it can't go out into the real world and foreclose my home. So we do need like a wet code contract for this interaction. But where a smart contract might be useful is kind of automating all of these real estate payments. So combining these two things seems to be like a very powerful, could be a very powerful area. Yeah, absolutely. And I know that's what Casey and Nina Kilbride and Preston, I mean, they're all lawyers. and I know that's something they're very, very focused on.

So I'm excited to see what they come up with. So one final topic we'd like to touch on is the topic of insurance and Dow's insuring something. So you've been dealing with insurance for the construction industry. And insurance is one of those industries that's very highly regulated, right? And so just tell us broadly why insurance is so regulated. and what are the issues when kind of Dow's try to insure something? Yeah, so again, speaking of the United States, I had a tour of Lloyds today, and that was, thank you, Stuart Mast,

that was quite something. Lloyd's has been in business for several hundred years. I mean, it's 400 years, 500 years, amazing to see. The reason that in the United States, it is particularly difficult is because insurance is, for the most part, regulated on the state level, unless you're talking about certain types of group health and life insurance, but for personal lines, you've got 50 state insurance commissioners, each of whom have regulatory authority. They may have approval authority over forms, over rates and premiums.

Why is it set up that way? There's a consumer protection function or purpose. the way insurance works, generally speaking, is I can self-insure, which means I can put some money into a bank account. If something bad happens to my car, then I'll have the money to pay for it. Or I can put money into a pool, which a third-party manages, and they manage it, and they hopefully invest it prudently and providently. If there's ever a problem, I'll be able to then make a claim and get money back to cover my loss. Now, if someone doesn't manage the funds properly, then I won't have the funds available to pay my claim. So part of what insurance regulators do is they help enforce, set, or establish reserving requirements,

the amount of money that an insurance company has to set aside to pay claims. They also make sure that forms are fair, and I'll give you a simple example. And I'm speaking mostly in the consumer context, but it can apply in other contexts too. So one of the earliest form standardizations was through something called the New York Standard Fire Policy, which is a statutory fire insurance policy form, which is used to insure homes. And it includes, in many states, a sort of a guaranteed baseline limitations period. In other words, you are guaranteed a certain amount of time in which you can file or make a claim. And if insurance company tries to shorten it, courts are required to ignore it. So regulators also, in certain circumstances, they try and make sure that the playing field is level and fair,

and that forms that are filed make sense and have language that's fair and even handed. I think it's important to remember, too, that insurance backs up or covers risk of loss for trillions of dollars, probably in real estate. I don't think I'm exaggerating in that number. And if you have an insurance market that is not consistent in certain ways, you... can create risks to that into a huge market. So there's a, I think there are lots of reasons why insurance is heavily regulated. And also from the standpoint of creating something that purports to regulate insurance, you're going to have a lot of purports to provide insurance.

You're going to have some very interested state regulators who will do their job and come asking questions. Did that answer your question? I feel like I rambled towards the end there. I apologize. No, that does answer the question. Like, the reason kind of this came up is in some of the stable currencies

schemes that we have seen, like currencies that hold their value against, let's say they are roughly pegged to the dollar or whatever. Right. We have had, like, the cryptocurrency community has needed to invent the, notion of trustless insurance, right? Smart contracts that insure people in case the peg is broken or something like that.

And like you have one of your articles that says like, okay, this is an insurance service that has a lot of regulations. And is it even a good idea to call this thing insurance in the first place? Yeah, so I had an interesting conversation with, very nice man. Is it Rune? I don't know how to, yeah. And I don't want to call out any particular DAO, but I don't, I'm not sure that the intent there was to create anything that is necessarily insurance. I don't completely, and I haven't looked at it recently enough to be able to comment on it, but because my point was in my post, be careful what you call it.

I mean, if it's not insurance, don't call an insurance. Because if you call an insurance, there are a whole bunch of regulations that apply. That's my thinking. If you're going to call something cheese, there are cheese regulations. Don't get mad at me for pointing out that they're cheese regulations. If it's not cheese, don't call it cheese. It's the same thing with insurance. If it's not actually insurance, don't call it insurance.

I understand why people call these things smart contracts, but it honestly confused me a little bit at first. They're not really smart contracts. They're not contracts. I'm not, I don't think anybody's going to stop using the term. and if anybody's throwing stuff at me right now, I apologize. It's not the personal. I find it,

the terminology is a little bit confusing, and that was my point about that in that article. My question was, is it really insurance? I'm not sure that it is. If it is, yikes, right? If it really is cheese, and you're selling it in Pennsylvania

and the cheese regulator hasn't, Given your approval, you're, you know, yikes, no different. All right. Well, thanks so much for coming on, Stephen. That was really interesting to talk to you about all these topics. I think the topics that are going to stay with us for a long time and kind of accompany this industry. And I'm sure it's going to be very interesting also to see when some of these concepts

and ideas and projects are going to get tested in court and in real lawsuits and battles, etc. So thanks so much for discussion and for you work, and we will look forward to kind of following where this space goes and where your work goes along with it. Thanks very much. There's a lot of fun, fellas. I'm honored to be asked to speak and enjoy the conversation. Absolutely. So, Epson and Bitcoin is part of the LTV network.

You can find our show and lots of other shows on Lysdorb Bitcoin.com. You can also subscribe to our podcast with any app. you can watch the videos on YouTube.com slash episode of Bitcoin. And we look forward to being back next week.