Good afternoon. My name is Hilary Brill, and I'm here on behalf of the Decentralized Future Council, hosting today's panel on The Smart Contract Paradox: Automation, Disruption, and the Quest for Control. Here at the Decentralized Future Council, we look at new technologies. We like to say technologies that are decentralized, beyond cryptocurrencies technologies that we don't always get a chance to discuss. And today, we're discussing smart contracts, which are just that, whether they are used for retail to mortgages, music to supply chain, smart contracts, they're an essential new decentralized technology that is rapidly being adopted by many different industries that are understanding and wanting to reap the benefits of automated transactions that eliminate costs and inefficiencies of intermediaries. And today, we have panelists that are going to discuss in detail some of the issues beyond the benefits that go into the difficulties that are going to be explored related to smart contracts, for example, recent legal and regulatory actions, threats to harm the innovation and the civil and society societal benefits of smart contracts. So we are looking for I'm looking forward to and I hope you as our guests are looking forward to digging into those policy and compliance topics and addressing the smart contract possibilities and limitations. So I'm going to briefly introduce the panelist. The panel of five different speakers that have a variety of different views. We're very fortunate to have Ari Jules, the chief scientist of Chainlink Labs, and faculty at Cornell Tech. He is the co-director of the initiative for cryptocurrencies and contracts. And his areas of interest include blockchains, cryptocurrency and smart contracts, as well as applied cryptography user authentication and privacy. We are pleased to have Marta Belcher. Marta Belcher is the General Counsel and Head of Protocol Labs, President and Chair of the Filecoin Foundation and special counsel to Electronic Frontier Foundation. She was previously an attorney on blockchain emerging technologies and has been hailed as a pioneer in blockchain law and policy, testifying in Congress, state legislatures, and speaking with the European Parliament. We have Wee Ming Choon who is a technology and corporate lawyer with a focus on blockchain and emerging technologies. He is the deputy general counsel of Ava labs previously at meta consensus and Latham and Watkins, he has a background in computer science and prior to becoming a lawyer, was a software engineer at a quantitative fund. We have Ross Schulman the first and founding senior fellow for decentralization at the Electronic Frontier Foundation. He is an expert policy technologist. And prior to eff worked at New America's Open Technology Institute, Center for Democracy and Technology CCIE, and in Congress in variety of capacities. And definitely not last, Ekene Chuks-Okeke, who is an IP attorney and fellow for the Internet Law and Policy Foundry and has recently written a paper on sanctions for smart contracts, "Won the battle, lose the war" with a law technology and entrepreneurship program at Cornell Tech. She is a Foundry fellow focusing on emerging technologies, and brings a unique perspective, from advising clients internationally, and specifically in Lagos, Nigeria. So thank you, and hello to all of our panelists. Since we have so many and so many different interests and perspectives, I want to jump right into it. And we're going to have an open table, round type of discussion. I do hope our panelists will jump in if I haven't specifically called on you. I hope that our viewers, if you have questions, we will hope to have a question-and-answer opportunity. But please bring your questions in there's a questions opportunity for you. And we will try to either answer written or during this conversation or possible afterwards, it would be a nice opportunity to have some back and forth. And with that, I would like to jump right into some table setting. Because many people that work on these issues every day they understand some of these key words, but we have people that think they understand some of these key words or they'd like some more background. So with that, I would love to start with you Ari, as our professor to quickly tell us what smart contracts are. How do they work with Blockchain? Are they different than the blockchain? And how do they work
Thank you, Hillary happy to do a bit of level setting here. Briefly, smart contracts are programs that run on top of blockchains. A natural question to ask of course is how do they differ from ordinary software applications non blockchain applications? To answer that question, we have to understand some of the basic problems Reviews of blockchains themselves. And, and two in particular are relevant here. The first is that blockblockchainschains offer transparency in the sense that every activity that takes place on a blockchain, every piece of data that is sent to a blockchain is visible on the blockchain to anyone in the world, in principle forever. Second key property of blockchains is their immutability. Once a piece of data or a program like a smart contract, so I'll explain in a moment is placed on a blockchain. It remains there, as I said, in principle forever and also cannot be modified after the fact. So smart contracts inherit these properties. They inherit the transparency property in the sense that when you interact with a smart contract, you know exactly what you're getting. The code is visible on the blockchain. And that's the code that you're invoking when you interface with the smart contract. But immutability is also important here. As I said, the code is immutable. Once the smart contract has been launched, this improvisers mentioned the moment it cannot be changed, its code cannot be modified. Another feature of blockchains that's going to be important in our discussion here, stems in some sense from the immutability of blockchain really relates to a slightly different property. But that's the fact that are the property of autonomous execution that smart contracts enjoy once the smart contract is launched. If it's designed to allow for interaction by anyone, then anyone will be able to call it at any time into the into the future. And no one unless there is a pre programmed facility, this sort no one can interrupt its execution. And so it becomes essentially a free standing capability, facility service, whatever you want to put it another way, smart contracts by dint of the fact that they operate on blockchains are unstoppable. An important thing to recognize here is that immutability, as I said, does come with some provisos here, as I said, smart contract code once placed in the blockchain can't change. That's essentially true, except that it can change if there is a built in provision for change to take place. So it's possible to instrument the smart contract in such a way that, for example, it can be upgraded, if some critical set of controllers or a community decides to upgrade it. And additionally, you can do things like build in an off switch or a kill switch the ability to terminate the smart contract. If that facility is there from the get go, then it can be invoked later on in the lifetime the smart contract.
Thank you. Excuse me. Thank you. That was great table setting. And you brought up some words that I'm glad you did, because I definitely think we should discuss the potential to controversy around kill switches later on in our conversation. That's definitely a highlight that folks are talking about right now. I wanted to use some real life examples of smart contracts that are currently being used by some of the actual panelists that are on the panel. I know that Eva labs works with smart contracts. Marta, I know that filecoin Foundation relies on smart contracts, if a couple of you could give us some examples of how smart contracts are used with organizations, that would be helpful for our listeners.
Yeah, sure, I'm happy to start. So at Ava labs we develop software that run on the avalanche, public blockchain, an avalanche is a smart contracts platform, like Etherium, you know, like a number of other blockchains and support smart contract functionality. So what that means is that anyone can write software, and then deploy that onto the blockchain. And the smart contracts then become accessible to whoever it's intended to be accessible to. A lot of smart contracts tend to be open and permissionless. And so this goes to what Ari was saying earlier, the software can be accessible really by anyone, which creates a very open way to interact with software. So at Ava Labs, we spent a fair bit of time developing functionality that allow others to develop smart contracts. And so in the avalanche ecosystem, there are defi protocols that they rely on smart contracts for the most part, their energy projects, they use smart contracts to mint create their NFT's. And there are lots of gaming projects that use smart contracts to allow their users their gamers to own and trade in game items are in the form of entities, you know, at our lattice ourselves, you know, we do use smart contracts in some of our services. And so the bridge that connects between Aetherium and Avalanche, as well as between Bitcoin and Avalanche does use some of our smart contracts than I think it's fairly common in the division world to use this type of automation. And it's very attractive to rely on the automation of smart contracts, because it does away with the need to rely on an intermediary. And I'm sure we'll spend a fair bit of time and this panel talking about intermediaries and, and, you know, what, what it means to not be intermediaries, when people can transact directly with a smart contract, what's called peer to protocol, or directly with each other peer to peer. But you know, that's, that's a little bit of flavor of what we see an avalanche.
Marta, can you give us an example of how filecoin relies on smart contracts?
Yeah, sure, absolutely. So, you know, I really think of it a little bit more in simple terms as just programmable money, right. But the idea that cryptocurrency really creates this ability to program your money and to send value across the internet, instantly and automatically with no intermediary. And so you know, one example would be writing a computer program that says, For every second of a song that I play, automatically transfer a millionth of a cent from me to the songwriter and for me to the singer, and that can happen instantly and automatically, as though I'm handing them, you know, a millionth of a cent right with no intermediary in between us. So basically, filecoin uses that concept of programmable money, this smart contract idea, and uses it to create a decentralized file storage network. So it's sort of like Airbnb for file storage. So basically, it allows people to rent out their extra digital storage space to people who will actually pay you to store their files. So we use this programmable money smart contract. And to have a computer program basically, regularly check that you're still storing someone else's files, and if so you automatically get paid in filecoin. So that enables you to basically create this decentralized alternative to things like Amazon Web Service, or Google Cloud, where instead of having one central intermediary, that storing files, you can have files stored all over the world, but have them stored in a peer to peer way that is also reliable over time, because you're using that smart contract technology to incentivize people to store them.
And what, what's a great team about all of this, from the perspective of people that are watching blockchain technologies and people that are naysayers are critical of what is going on with cryptocurrencies. They're not always talking about how blockchain can enable these types of technologies and these types of opportunities, and it can sometimes get lost. So it's exciting to dig into this concept of smart contracts being used yes as programmable money, but not necessarily just Bitcoin or some opportunity to invest. It's being used in ways that we're making our lives better. And it was mentioned about eliminating intermediaries costs and inefficiencies and how we normally do or normally use actual day to day activities or how we use our storage or storage systems. So I'd love to dig into that a little bit more. We talk about the benefits of smart contracts, can some people share how we talked about mutability, and, and transparency, but can some folks chime in with a little bit more about what people can see as a tangible benefit with decentralization and smart contracts?
And chime in anyone can chime in? Well, the the applications that are most popular today tend to be financially oriented. smart contracts enable the creation of financial instruments that may replicate in a decentralized way. Those who are accustomed to interacting with the real world, or in some cases achieve completely new functionality. And I think perhaps the most interesting advertisement for smart contracts and their native capabilities is something called a flash loan. So I'm not sure you walk into a bank and say, I'd like to borrow $10 million. But I don't want to. I don't want to give you an identity document, I don't even want to tell you who I am. And I don't have any collateral by the way, right now, you will be, at best politely ushered out of the bank. But you can in fact do something like this on a blockchain using this feature, or application that I mentioned called the flashin. Why can you do this on a blockchain when you can't do this in a real bank? Well, you can borrow anyone can borrow $10 million. From a Flashman enabled smart contract, but there's a catch, you have to pay back the money in the same transaction, which was driven. And if you don't pay back the money, then the transaction rolls back, it reverts. And it's as though it never happened. And it says no time rolls back, and you never took out the loan to begin with. So there's no risk to the lender in a flash loan. And this is not something that you can do in existing financial infrastructure or anywhere else to the best of my knowledge. Why would you want to do this, this enables you to do things like arbitrage, right? If you see that the price of Bob's bubble token is $1 in one smart contract and $2 in another, you can take out a flash loan, buy up Bob's bubble token on the from the contract where it's selling for $1 and then turn around sell for $2 make a profit pay back the one this is typically the flash Lindsay's for as I said flash loons in my view are an excellent way to underscore the capabilities that smart contracts can bring to financial infrastructure that would otherwise be unachievable.
I like the the flash loans example because I think it highlights one of the strengths of smart contract based software, which is composability. And that is the ability for, you know, the outputs of one software to be fed into another piece of software. So obviously, in a traditional technology world, you know, what we call the web two world, you can have those types of relationships between software, using each other's software typically requires some level of agreement on a standard way of interacting. So open source software is very good for this because anyone can inspect the code, and they understand how the interfaces are intended to work together. But you know, there tends to be a convergence towards walled gardens in the web two world, for a number of reasons, companies have their own way of doing things, or are protective of their data and want to get who has access to that. With smart contracts, they are open source by their very nature, because the deployed onto a public blockchain for the most part, anyone can see the code that's running. The code itself is also on a public repository. And so you can actually just download that, or copy that and launch your version of the code. And now the the classical example, you know, really saw twice on the point that one smart contract can call another smart contract. Right. So for example, you'll be among using a swap in a defined protocol, but calling a flesh loan, smart contract to obtain the loan, and then feed that into the swap, smart contract. And it also hides the fact that because there is an agreed standard, for example, in the ethereal world, they are ERC standards, which folks have agreed that define types of smart contracts, and therefore the types of tokens. It's an easy way for developers to leverage what's been built, whether it had to reinvent the wheel every single time. And this increases innovation greatly. It encourages experimentation. And it really allows for a very open, equal playing field for developers and users to participate.
One last thing that I would add that I would not last I don't I feel like but one thing I would add, that I've found really interesting lately is the use of smart contracts for governance. In some situations in particular, I just came across recently, work being done to use smart contracts as a governance layer for cooperatives. So businesses that are wholly owned by the people, usually by the people working in the cooperatives are workers in a cooperative and using the smart contract both as a token there represents that partial ownership, as well as using that token in, in a governance setting to help make decisions about the direction of the cooperative, for example, so there's a so having nothing at all to do with, with money or Well, I guess it's something everything has to do with money eventually, but nothing to do with the actual financial transactions that might be going on in other contexts.
Thank you, Ross. And I'm gonna turn it over to attend a, partly because one of the internet law and foundries former guests was Vint Cerf. And I know, he was talking about smart contracts. And he was discussing how smart contracts can use code to monitor smart contracts. And notice when something wasn't possibly going on, and could alarm a system that actually smart contract wasn't working, and that there's almost this infinite opportunity of innovation with smart contracts. But I know that you've dug in pretty well into the you know, how we won the war. Have we lost the battle? Excuse me? Have we won the war? Have we lost the battle? We're talking about the benefits, but there are some concerns, and I know that you've done some work in this area and your supportive innovation, but you're looking at it from a perspective of how can we, how can we use this code and make responsible smart contracts?
Yeah, thanks, Hillary. These are all very exciting uses of smart contracts that everyone has mentioned. But then, as you mentioned earlier, like smart contracts, work by disintermediation, right? So they eliminate the need for a middleman for all the transactions that they enable. And this is challenging for governments because they would typically rely on peple or middlemen to enforce certain regulations. And now, these are things that are automated automatically by smart contracts. So it does raise some concerns, as I believe we'll discuss further about turning to cash. So yeah, so those are the challenges that smart contracts raise for governments.
Thank you for that segue, because that's exactly what I would like to dig into a little bit here, because that has been what really inspired a lot of this panel on a lot of discussions. This was an unprecedented case. Can you tell us a little bit about the background of the tornado cach case, and some of the issues that it's presenting right now, to us for for for our listeners.
So tornado cash is an unprecedented case, because the US through OFAC, the Office of Foreign Assets Control. The recently sanctioned tornado cash, tornado cash is a service or a smart contract very loosely, that helps people send money. So it's a cryptocurrency mixing service or smart contract of sorts. And the US government recently sanctioned tornado cash through OFAC and added them to the list of specially designated nationals. So essentially, no one is meant to transact with OFAC or deal with their property. And it's raised questions because tornado cash is not a bank is not an LLC. It's literally a smart contract, which we've heard from everyone is programmable code on the blockchain. So this raises new questions because again, Tornado cash is not the traditional person that the government will typically try to enforce laws against. It's the smart contract that is used by hundreds of 1000s of people. And the government link tornado cash is used to people who, in North Korea, who had they had led some cyber heist, and they basically use tornado cash to make their currency or to move their currency. So this is why tornado cash was sanctioned. And just raises these new questions. Because again, the tornado cash founders and people who use tornado cash are not directly responsible for the wrongful use of tornado cash by others, but now turn into cash itself has been sanctioned in the US and people are not meant to use it anymore. So that's the latest.
Right? Thank you. So that as you mentioned, and I did to this is unprecedented. We've never had code directly as a focus of an SDN list from OFAC. So we are dealing with which is, which is nothing new with emerging technologies. I mean, that's the same old story, how do we take technologies and place existing rules and ways that we can regulate ways that we can have compliance ways that we can touch on and make sure that our protections are in place and law enforcement here was concerned about a specific type of technology but the response was, at some people say to ban code or to ban technology, which can raise its its own type of thorny issues and thorny questions and questions that have all sorts of obvious it concerns. Marta, I would really appreciate hearing your perspective because I, I know that you add an added perspective that not everyone's looking at. And it's from a civil rights and human rights perspective.
Yeah, you know, I think that, from a civil liberties perspective, you know, what happened with tornado cash is, this is a technology that enhances the ability to make transactions privately. And fundamentally, putting this entire protocol putting this this code onto the, the SDN list is not only unprecedented, but also quite problematic, in a couple of ways. The first way is that it really raises a lot of First Amendment concerns regarding the really hard fought precedent that computer code is speech and the protections around computer code. The second is, it's really part of this larger trend of lawmakers really taking financial surveillance and imposing it on to the cryptocurrency space. And I think that it's part of this larger issue that governments around the world really see transactions as not being subject to protections around privacy. And there's this idea that okay, well, we may, you know, just in the United States, right, we have the Fourth Amendment, and what's supposed to happen is if the government wants to see your transactions or to see your communications, or really, if they want any information, they're supposed to have a warrant and have probable cause to go look at those those things. But we've sort of just come to accept it as normal in, in the financial sector, that the government sees transactions by default. And there's this sort of sense that the government really wants transactions to be to not be private, and not only to not be private, but also to be accessible to the government at all times. And so I think that's really where this sanction came from. Is this the sense that financial transactions should not be private. And I think that that is something that is really, really problematic for civil liberties?
Thank you, Marta. I also think with the discussions and the news and the movements with digital currency in general, some of the same issues have definitely been bandied around and talked about if we have a digital dollar, what happens to opportunities that we had just to be private, and it doesn't private does not immediately equate with something wrong, it equates with your privacy. I don't know, I don't necessarily me, Hillary rail, you know, doesn't necessarily need the government to know what every single cent dollar I give to my children to buy something or I give to someone else, like there are just inherent privacy issues, and I'm just talking about my own privacy that I may not want, if everything is digital in a digital dollar. And that discussion is going on. I think there's similar concept, their concept they're about what do we do if we move into a digital currency world that are being discussed, but not in a concept of smart contracts? And and, and you're correct when it comes to financial transactions or issues about anti money laundering and know your customer, but then there has to be the civil liberties and this balance. Anyone else on the panel wanna want to discuss that or bring their perspective to bear?
Um, I think just to come to the mic when Marta said the challenge tornado cash is also the scale. So if they can prove it, OFAC is saying that they've processed about $7 billion through money laundering. So it's the so the scale also matters. And the privacy point is valid. But then it's like there are also other ways people could enhance their privacy. On the blockchain. There are other services that have not been sanctioned, specifically. So I think that's like the Contra points to that. So tornado cash is one way to enhance privacy in transacting on the blockchain. But then it's just the scale of money laundering, that it's allegedly Foster's.
Thanks for me, the other interesting thing about the tornado cash, in addition to the points that Marta and Ekene both very, very well, is the way in which we're seeing the very aspects of smart contracts that we've been discussing the the immutability, the almost inevitability right the the inability to stop them coming into conflict with the but fairly normal, everyday expectations of governance and regulators in that, in another world were turned into cash was, say, a bank, with a CEO of some sort, there probably would have been an intermediary step between, you know, saying go and OFAC sanctioning, right, like the CEO would have been hauled into, you know, the Treasury Department at some point and said, do something about this, you know, et cetera. But what we have, instead is a situation where there is no person that can be spoken to, in the case of tornado cash. There are developers, but they don't control it, it can't be stopped really accepting some of the ways that I was going into earlier. And, and when you say to a government or a regulator, I'm sorry, there's nothing you can do about this. They don't find that amusing. Judges don't find that amusing that to be told, there's nothing you can do here. And so we are going to start seeing and are already seeing this conflict between the expectations of regulators the expectations of governments that they can do something about a problem. And this this nature of blockchain and of smart contracts. That is sort of contrary to that. And I think we're going to have some interesting few years here, while we try to square those particular circles.
So that thank you, Ross. So that that raises a general question about tornado cash, I can ask what do you think will happen in tornado cash? And then we can say you heard it here first, if anyone has some kind of, you know, prognosis or idea but if you don't want to answer that question, for fear of being wrong, or don't want to gloat if you're correct, I will then change the question a little bit. And I will say if OFAC actually succeeds in tornado cash, and governments then choose Ross to either not pass statutes or they are OPAC. OFAC doesn't succeed and the government's choose to then say, wait a minute, this isn't okay, we have to be able to have code on an SDN list or we need to use other types of tools that are disposable. We need to regulate, decide what agency is going to do it is there going to be a new blockchain agency, as we know, these policy discussions can go in a variety of different ways. But if they choose to do try to limit smart contracts, well, then I think you sort of touched on this, what do we do? Who can actually stop these smart contracts? If they need to? Or who can actually help design the smart contracts in a way to make them responsible? Do we even need them to do?
So sorry, we mean, just about, I don't mind being wrong in future like about tornado cash, is just looking at the different arguments is returns on is trying to catch a person? are they dealing with properties since they are noncustodial? And is there a property interest in the software itself? I think that there's enough to ground tornado cash as a person. They might not be a person and the way that a human being is or an LLC is. But there is enough, I would say legal theory that can be wrangled to explain that, you know, to justify the designation of turning to catch as the person. They have a DAO, they were organized as such. So I think that is plausible that Tornado Cash, the court could decide, as they did in the DAO case that you know this DAO is an unincorporated association, the oppression of sorts, as you said, can it be stopped? I can't speak to that. It seems impossible, but they could go as far as saying their person. I don't know what effect that would have tangibly. But I think there's enough for the courts to say their a person potentially.
Yeah, I was gonna say a couple of points, not so much to answer the question, because, you know, I don't have a crystal ball on this topic. But I guess the first point is, how could one stop Tornado cash? Right? And it's, it's generally right that it's very difficult or impossible to do that to a smart contract is already operational. And there are questions about what the effect is to stop this instance or turn into cash when someone else can fork the code and launch a new version and just call it you know, to another cash to or just doing something friendlier, but I was always gonna raise is who the responsibility then falls on if not tornado cash. Right. And I think as we've seen since the August designation last year, is that validators on Etherium. Some of them have been maybe correctly paranoid that the responsibility now falls on them to try to stop to the cash transactions. And since there's not a lot of guidance on what it actually means to do that, you know, there's been a variety of approaches. One of the approach is to if you are a validator, and you are processing transactions, and recording them onto the blockchain, you would choose not to record a transaction that has led to another cash address, either revisionary from tornado cash, or, you know, be sent to tornado cash. And I remember seeing reports last fall about how potentially two thirds of elders in the US have taken that step. But I don't want to, I don't to say that that's definitely happening. And that definitely has an impact on you know, that the those reports are claiming. But it is a bit worrying, that they're responsibly false on validators because the role of validator really is to record transactions on chain. And for, you know, they're agnostic about what the transaction contains. So I mentioned early on the panel that transactions enabled by smart contracts could be you know, any nature of any activity. Summer financial, summer gaming with I mentioned, some of the NF T's in central government use cases, right Supply Chain Management, contract procurement, disaster relief. And so it's a weird position to be in for a validator, the performance of very rudimentary technical function, to keep the network running, to now have to screen the type of transaction based on the activity and comply with sanctions regulations. So, you know, I think there's a bit worrying and I'm sure there are other concerns, from a personal perspective to apply. But I think for developers worried that it impacts our ability to innovate, and to write code and experiment.
Thank you, we mean, because I wanted to add to perspective as someone who works for Ava labs, you know, if there is a regulation that goes in a certain direction, what do we do about the concerns that Marta raised? What do we do about privacy? What do we do about First Amendment concerns and speech and code? And? And I believe it was you who mentioned before, then who is responsible? And who is liable if it's not code? And if it's open source, who actually owns this code, and if it's going to be a person attached to it, there's all sorts of difficulties and complications and trying to figure out who's going to be responsible. And that that's something I'd like to dig in a little bit more. And it can you briefly mentioned, there are other opportunities to protect individuals. But the facts for tornado cash are the people that actually did use tornado cash for their own personal reasons. There were some compelling reasons and ways that they were using it that had to do with their own personal privacy is the question or is the answer, okay, turn into cash, since you can be used in such and such way, as a tool and technology badly that we are going to shut out all these other posit opportunities. And can we even do that? I mean, is there an opportunity for another type of very, very curated, smart contract that will only allow certain uses but it's private? I mean, is that is that even possible?
All right, go ahead.
Sorry, I just wanted to interject that that is technically possible with adjuncts to blockchains. For example, use of what are called Trusted Execution environments, think of them as black boxes, in which smart contracts can execute. There are other technologies that enable for privacy preserving functionality on chain, what are called zero knowledge, proofs, and so on and so forth. So, in fact, the design space is a pretty rich one.
So are you are you saying that we can actually curate a new type of tornado cash that would allow privacy for financial transactions but not allow for potential misuse?
Well, I'm saying that one can write a policy that dictates who's able to use the smart contract, whether the policy, in fact achieves its intended aim, of course, as I said, Question. But you could, in principle instrument the smart contract. So it will only allow those with credentials demonstrating that they are not on the sanctions list to interact with the contract that is technically possible at least.
So all chime in here, I think, I think there are a couple of sort of big picture things like and assumptions we're making. Right. So. So one question is, like, I think some of the assumptions of what we're saying here assumes that creating software that enables private transactions is like bad and someone should be held responsible for that. Right. And I think that's like an important question that we should think about. Because I think the idea that technology that enhances privacy, or anonymity is bad, is is a fundamental misconception. Privacy isn't bad, and it's not illegal. And an enabling privacy should not be something that we just assume is, is bad. These are exactly the same arguments that we have seen used against encryption, and against other technologies that enhance the ability to do things privately and anonymously, like Tor, right. And so I really worry about these types of arguments being levied just because you're talking about financial transactions. I also think that things that are illegal, like money laundering are illegal. And we should go after people who money launder you, there are all sorts of things that you can do that don't involve taking an entire technology and banning it effectively, right? You don't need to ban a technology just because it happens to have been used by some bad people. Otherwise, you know, we would have to ban cars, because they're used as getaway vehicles, right. I mean, so I think fundamentally, the idea that technology can be used for bad things doesn't mean we should ban that entire technology. And I think we should be really careful when we talk about technologies that enable privacy as though that is somehow bad or illegal.
I definitely agree. And I don't think it's wrong to have privacy enhancing technologies. My perspective is more informed by the litigation itself. So we have these big picture Tornado Cash is big stakes for the crypto industry, which is why they're taking the litigation so seriously. It's just that the arguments advanced so far, like there's the privacy big picture benefit, but then turning most of it on personhood and property, as is the present case. In the courts. There's also the privacy bit, but that person heard, that was like the crux of the response from the industry. And the case put before the court. So that's what I mean, it's kind of dicey. Right. So turning your cash is not your person in the traditional sense before OFAC designated attorney to cash. I don't think anyone would think a smart contract is a person. But he's just going back to you know, how the law is drafted. And seeing that. Yeah, there are other arguments, as you've advanced here, which are grades, but the person had one is just not the best one. Basically.
I think that's a greater general question, Should tornado cash? And I think we got your answer, can I but I'm asking the panel to think about it should tornado cash be considered a person? And as OFAC said it was, it is code.
So should to be considered a person?
Well, so I think what, and obviously, like for the lot non lawyers in the audience, it's not obviously a person, right, we're talking about a legal person, right, and an entity of some sort, that that, you know, can be brought into court can, you know, be be prosecuted in the case of a crime or something to that effect? Like, like a company is under many US laws? And I think, fundamentally, I'm not necessarily, I don't necessarily think that needs to be a person or a corporate person or legal person. But I think it needs to be legally something. Because there is going to come a time, even if we think that Uchida and even we think 20 out of cash, if we even if we think that these particular cases are illegitimate, our you know, are non valid for privacy reasons or other reasons, policy reasons. There will come a time at some point where a data is going to create is going to commit a crime, you know, there's going to commit fraud of some sort in some way, shape or form. And justice, we will want justice to be served right? We want to be able to recuperate, might losses of some sort. And so some sort of personhood is going to be desired there because the alternative right now is which we sort of alluded to earlier is general partnership, which is under corporation law in most states in the in the country in the US, at least means that every person, actual physical person that is participating in the down in some way, shape or form is what we call jointly and severally liable, which means that if I hold one single token of this dow that committed fraud, they can come after me for every single dollar of that fraud. And that's what you really don't want that for innovation to continue for people to continue using smart contracts. We need some other solution, whatever that solution is, whether it's an LLC, like, by default they become an LLC is whatever that answer is, but we do need an answer, because the alternative is general partnerships jointly and severally liable. And nobody wants that.
I think what's also interesting about smart contracts is to Ross's point about general partnerships, that is looking at the torndao cash DAO, but then when you also think about the actual users of the tornado cash, who are facilitating the transactions, whether it's legal or illegal, I mean, some personhood should attach, they are the actual persons that the law is trying to hold on to. So it's just appears that it's because of the nature of smart contracts, it's hard to figure out the identities of these people. So it's just easier to go after the, you know, the DAO or the attorneys, the tool itself than the actual people making the illicit transactions?
Yeah, I think that's an important point, right? We are seeing a situation where regulators go after the closest thing they can to attach liability. And, you know, usually it's developers, in this case, and that's, that's interesting, because, you know, at least between developers or service providers, software service providers and their users, you know, the way that liability is a portion is governed by current traffic law. And so, you know, we're all used to seeing terms of use when we sign up for a new service, whether personal or enterprise service. And it's, it's become fairly common to have disclaimers that touch on when the developer is responsible and whether or not but in a smart contract, you don't always have the ability to have these terms, right. Because, you know, you could interact directly with the smart contract without having to agree to anything in writing, right, any written contract ahead of time. And so be interesting to see how the courts sort of try to read the liability there. And this goes to the point about the liability of the smart contract to its users, right, in case there's a fraud or loss. This doesn't necessarily cover what happens when a regulator or company agency goes after the developer. But but it's an important question, because it's not limited to blockchain. But you know, we are living in the age where things are becoming increasingly digital and increasingly automated. And so smart contracts, you know, what we call autonomously functioning software. But there are other autonomously functioning software, right, in the form of generative AI. So if you want to use some sort of general AI service, to create documents, or a design or proposal, and it turns out, there's flaws in that and people are hurt or lose money. It's a similar question of what's the responsibility there? And so, you know, I think these questions haven't quite been figured out yet. And we need to talk about that in the context of how to sort of balance the need to promote growth and innovation and allow these things to further improve, while also making sure that, you know, user harm or I guess, national security interests are taken into account.
So we have had a lot of discussion about benefits of smart contracts. We mean, what you just said, really dovetails nicely into their issues of liability when regulators start to participate in the process and consider how to regulate the negative effects of smart contracts that we've also discussed. So I'm going to present to to all of you when we want to protect an invasion. We want to protect these positive aspects with smart contracts. Some of the benefits that we talked about the beginning and we want to protect privacy and we want to also protect against bad actors. Should regulators be regulating creating new legislation creating new compliance rules, do our existing rules work? And adding to that if the answer is yes, So should they be actually regulating to protect smart contracts? Should they be regulating to proactively protect privacy? It should be they shouldn't they be going on the other side? What is this balance? And I say this because we do have regulators that listen and are trying to figure this out and dig into it. So to the extent that you have a view and an opinion, or even this has solicited advice for for regulators and legislators, you know, what should we be worried about what it should be protecting,
please share and just jump in? Well, if the EU Data act provision for kill switch to be incorporated into smart contracts as any indication, legislators are really struggling to come up with viable ways for regulators to ensure the safety of smart contracts, ecosystems and kill switches are in particular problematic for a couple of different reasons. One is that if one jurisdiction has access to a kill, switch, or can incorporate a kill switch, it's natural for other jurisdictions to want to have the same ability. And so the EU as its own kill switch and smart contract, then it's natural for the US to demand one, China to demand one, and so on and so forth. And if the the goal here in providing safe environment is to stimulate innovation, someday we could have, I don't know, a $10 trillion financial system powered by smart contracts with a kill switch that every country in the world has access to, right. So the Taliban and Afghanistan could decide to turn off the world's financial infrastructure if you take this to an extreme right. So that's one problem kill switches another as a technical problem, namely, that it's very hard even for sophisticated actors to secure keys and secrets more generally. Well, we've seen this thing number of instances of this from the Snowden leaks that implicated the NSA, to loss of cyber weapons by the CIA, and so on and so forth. So do we really trust the EU to secure keys that have the ability to turn off? What could eventually be a piece of critical infrastructure critical financial infrastructure? And and this question has arisen in the context of encryption, encryption backdoors. And one of the arguments that the technical community has made against them, is the fact that they introduce vulnerabilities into infrastructure, a kill switch would do the same.
I'm happy to chime in here as well. I think everything I said about kill switches is exactly right. You know, I think fundamentally, there there are a bunch of layers here, like the top layer is should we go after people who commit crimes? Absolutely. Right. should we ban entire technologies? Because they were used to commit crimes? Absolutely not write? Should we go after developers? Who created software that happens to have later been used to commit a crime? Absolutely not? Should we create backdoors to technologies like it's I think, Ra's point about kill switches being like encryption? Absolutely not. And I think it's really important to separate out people who are committing crimes, who to be clear, we should go after from developers of technologies that enhance privacy and civil liberties, which is a totally different thing from committing crimes.
Yeah, I agree with all that. I think I think we understand the perspective of the regulator and government agencies who are doing the best to develop the skill sets and the tools to trace the flow of illicit funds through transparent chains, where it's easy to create a new wallet, it's easy to use, you know, services that that make it harder to track your flows. But we are seeing an increasing number of analytics on chain service providers that have, you know, much better built to do this today than it did you know, let's say five years ago. And so I would say rather than try to take an approach that would work in the traditional web two world and just paste it onto the web three will expect everything to work, rather than that, you know, is to try to see what the benefits of transparency outweigh the cons and to to develop something a bit more custom and I work within this realm. So for example, in taking on the responsibility of developers, so I took responsibly, whether liability but because it's trying to think of a proactive things that developers could do to make it harder for bad actors to use, for example, or less susceptible to misuse, perhaps one area are sort of security reviews of the code when it's become standard and industry to get your code audited, right, at least four major flaws that will allow a hacker to drain all the funds, for example, from a defi protocol. And we can debate whether these reviews should be mandatory or voluntary, right, there are different vector regions around the world where some of them are on a voluntary basis. But there's recognition that businesses, developers who seek voluntary certification and things like that might have access to just a larger market, right, or the government clients, for example. And so I think, you know, trying to cover off technical type issues and looking for solutions within the realm is a good way of doing things. And you know, I know some government agencies are doing they're having conversations with different participants in the space to leverage what they can about the technology, rather than to apply existing laws that that might not exactly work, or to write new laws, they basically convert everything back into intermediate, and world.
Because we only have a few minutes left, I want to wrap up and give you a chance to say any last closing words, there's some key important points here, as we all understand smart contracts or code. Code has been designed by people. There are questions here raised about how do we design smart contracts in a way that can promote the innovation and the innovative aspects that we've discussed, but also prevent bad actors from using them in ways that they either weren't intended for? Well, obviously, in ways that they weren't intended for or to prevent ways that we don't even know and we haven't even thought of yet, how do we prevent anyone from using a positive technology in a negative way? Without taking away that it is just a technology? There are some solutions about as you just mentioned, gaming auditing it are you suggest that there were present potential ways to design and redesign code in a way that would protect it? There are privacy considerations that we need to take into consideration in any kind of design and code. And there was a brief discussion of court and discussion about concerns with kill switches that is in the EU DATA Act? And how do we legislators now have to figure out how are we going to handle a kill switch concept here in the US and internationally? So there's a lot to be discussed, that that many people aren't looking at when they think about contracts. And I hope this is the first discussion that it's useful for folks that that are working on these issues that you continue to have this discussion, but I do leave the last few minutes for anyone to throw in about any final questions, anything they wanted to say?
I think, you know, if there's
if there's Let's see one question that was thrown in there about soft, soft, smart contracts are programs and software has bugs, and they don't always do what they're intended. And this person says software can perpetrate mischief. But what protection against bugs and bad actors, being visible doesn't necessarily a short of perfection and good intentions. I don't want to answer this question. But I think we touched upon some of that, that there are some ways that we can actually try to use technology in a way that prevents mischief. And, Ari, I think you touched on it the most when you said that there there are possible ways to design code. I look to computer I don't look to a computer scientist or code to fix it. I'd like to think that the people on this panel agree that people and designers encode can help fix problems. But in the last few minutes, if anyone wants to answer our, our, our actual viewers question or or add anything, please do.
Well just mentioned that the concerns we've raised about malfeasance, facilitated by smart contracts don't involve truly imminent or catastrophic threats. In the case that such a threat arises there is a kind of break glass solution, which we saw implemented way back in 2016. And 2016, there was a smart contract in the Aetherium ecosystem called the Dow, which at one point held 15% of all ether And it turned out to have a serious bug. Fun started getting drained from that contract. And what the community did essentially was rewrite the rules of the blockchain or forking to be more precise, and this was this was a very contentious decision. I think it was probably the right one to make at that time. But those who objected to it said that there is a social contract underlying the blockchain. And that social contract stipulates that blockchain the rules, the blockchain should not change. In this case, they were changed in response, as I said, to a threat to the ecosystem in its entirety. So just mentioning that drastic solutions of that type remedies of that type are available to a community should something like the DAO or a more serious problem arise in a smart contract system.
Ari, you get the last word. Thank you, for everyone for attending. I do hope that whatever solutions do not disrupt the general positive benefits of decentralized technologies, and are growing and useful blockchain technologies that are beyond crypto, that we did get a chance to dig into a little bit today. Thank you so much for all of your time. Thank you so much, all of you who participated. And I look forward to hearing more of this conversation with all of you and I hope you're all there and available for future regulators who are going to have many of the same questions. So thank you.
