 And we're back at law.mit.edu's YouTube channel, where we're having a hangout live on air with Ory Shimoni. And we're back at law.mit.edu's YouTube channel, where we're- Yeah, I can. Okay. So my monitoring indicates that all systems are go, and Ory Shimoni is, you're joining us again. This is kind of part two of a exploration of your recent work with your team and with all over good enough and others to actually kind of prototype and implement a Vermont law-based blockchain-based LLC, BBLLC. And so, obviously, I've been monitoring this with you at Brooklyn, at the Bushwood generator and in various circles that we ran in, and it's been very exciting to see you putting it together and building it out. But now you're at a real milestone, and you're poised to publicly launch and announce this later this week. And I just want to thank you, first of all, on what must be a tumult of activity to take a moment out to provide us a demo and a little discussion. And I want to say that we're very excited to see it. And we'll plan to hit publish on this video at the same time as your announcement. So with that, Ory, maybe you could introduce yourself again for those that may have missed part one, and then bring us right into the demo, and we can discuss it for a few minutes after. Okay. Sure. Yeah. So I'm Ory, as you introduced me. I'm one of the members at Dorg, which is a group that's building software, tooling, and now legal templates and pilots for distributed organizations. And I work on a lot of our operations and a lot of the technical specs for projects that we do internally and with clients. And one of the main projects I've been working on lately is setting our own company up as a DAO with a BBLLC link to it. So being sort of the first limited liability DAO, and that's in an effort to sort of what's called dog food to use, eat your own dog food in the tech circles, like to use the tools that you're building for others. So we're running ourselves as a Dorg food, eating our Dorg food. There we go. And we essentially run ourselves as a cooperative of freelancers. So if you're familiar with worker owned cooperatives, this is sort of what we think of as a supercharged version of that. So having all those governance rules implemented in software and persistent software smart contracts, and then having the legal agreements to be the backstop so that what we do in the governance processes of the DAO actually has a legal strength to it. And so yeah. And so we went over some of the details of that in our last conversation, but this time I thought I'd show you some of the software that kind of underpins the processes that we're talking about here. So I'll go ahead and share my screen and you can you can go ahead and keep asking questions and tell me what to clarify as I go along. Okay, sounds good. I was trying to politely go on mute while you were talking. So those long silences were hardly awkward. They were very gracious. Beautiful. Beautiful. Can you see the screen now? Can you see my, you're on mute, right? But okay, I'm assuming you can see my screen. Yep, screen. Yeah. No, yeah, feel free to interrupt me as I go. But I'll just first I'll show you our DAO is based on the DAO stack platform. So DAO stack is a protocol that allows for different sorts of very modular, extensible, customizable, distributed organization architectures on the Ethereum blockchain. And so we're using their interface. So DAO stack exists as a series of smart contracts on the Ethereum blockchain, but there's many different. So there's many different ways you can interface with those smart contracts. And so one of those ways is with the alchemy user interface. So all of this software is all of this user interface that you see is reading data and writing data to the blockchain, to the Ethereum blockchain. So right now, this is the main interface for interfacing with DAO stack DAOs, but you can imagine many other clients, front end clients that have different kind of specialized functionality. But this is the generalized one that I'll walk through today. So this is you can think of this as the application for managing. So these are a bunch of different DAOs that are deployed now. I'll show you one of the most active ones is Genesis, which was the kind of pilot DAO that DAO stack launched about a year ago. So there's over 150 members of Genesis. It gets about 60 Ethereum from DAO stack. The company every month to kind of pilot new, to kind of give to the community of voters so that they can control those funds and develop whatever they like. And so you can think of alchemy as the DAO management or DAO operation interface. So this is where you can make new proposals. You can ask for some ETH, you can ask for some voting shares, which are non-transferable shares of voting power. You can ask for different tokens that the DAO has, like maybe some dye, maybe some TUSD, some tether. And then you can say reward me for building a BBLLC. So you could kind of make a proposal with a description. You could link to a longer description. And then here you'd put something like your copy, paste your Ethereum address here to get rewarded. And so once you'd make a proposal here, it would turn into one of these. And then other members of the DAO could vote for or against your proposal. And there's also a pretty sophisticated game theoretic game going on, where people can bet for against proposals. I won't get into that in this demo. But basically this is a proposal engine. And so what Dorg has done, let me make sure I'm still here, yeah. So what Dorg has done is that we went and built our own interface. But ours is specifically for designing DAOs. And so what you can do is design DAOs on our interface, and then ultimately use them on this interface. But today, in particular, I want to talk about the integration of legal agreements that we've been working on into this flow. So first I'll talk about two different sides to integrating legal agreements with DAOs. So one would be into the DAOs formation. So that's what Dorg achieved recently that we're talking about a lot this week, which is the formation of our BBLLC linked DAO. So we did this very manually with the lawyers, with Oliver, good enough with Gravel and Shea in Vermont. And we manually went through and wrote our operating agreement, various service agreements that we can use as templates with future customers and contractors and members. But the idea is that with this next stage of this process that we're going to integrate those formation documents into the software itself for forming a DAO. So instead of having these separate manual processes that are manually linked, like what we just did, we want to automate it. So creating a legal entity in a couple clicks is as easy as opening a social media account. So let's just say test token. You don't need a token, but I'll just, for the example, we do this DAO. Maybe we have some addresses here. So we'll do some addresses for the founders. Let's say it's a 50-50 split of power. And let's say there's some tokens as well, but there doesn't have to be. Let's say there's one token. And let's say there's this other one. And they have, let's say, 60 voting shares and two tokens. And so it'll show you the reputation distribution. Again, reputation is just voting power. And tokens are units that you can create for your entity if you choose to. And so this is where we add features to the DAO. You can make different rules for all the different, like choose different kinds of voting machines for your DAO. Maybe you want an absolute vote for this kind of task. And for a more sensitive task, like actually managing the upgrades, you'd want a more sophisticated voting machine that has some of the betting games built in that I was talking about. Again, this software is very alpha. It's not very user-friendly. It's more for experts who are already familiar with this DAO protocol. But the idea is that in this, before this review and deploy step, that we're gonna add another step that has on the back end marked up versions of the legal agreements that we've worked on. And that lets you kind of add and remove clauses and also include additional information, like your legal name, your mailing address, the kind of stuff you would need to also register an entity in addition to deploying a series of smart contracts. So in the dream that Daza and I have talked about before, the real dream is having this end-to-end totally automated. So having some sort of API setup with the Secretary of State's office, for example, that would actually make the filing go through upon hitting this button. But short of that, we can also work with local lawyers, registered agents to kind of partner with them and have their optional add-on services here, just to, for example, file the entity to be the registered agent for the entity. So you know, you'd hit deploy DAO and bundled into the transaction that deploys the smart contracts. You could also bundle in some, you know, a fee to the state for filing and maybe a fee to a registered agent on the ground for serving as your home base. Does that make sense Daza? Do you have any questions regarding the formation side of things? So yes, that makes a lot of sense. And I think something that might be helpful for people that are viewing this, especially for the first time, is if you could say a few words about the connection between the filing requirements of the Vermont statute enabling blockchain-based LLCs and, you know, that subset of information that one would have to include in a filing with the Secretary of State and the information that you're collecting as part of this process would be number one. And then number two, maybe after the demo, we can talk a little more about what might be involved in connecting up those processes, like for example, the expectation that for the mundane foreseeable future state governments will be accepting US dollars and not cryptocurrency and things like that. First things first, maybe you could help us unpack just the sort of data flow and the data model between what information you're collecting and what information is needed for a state government in order to form a legal entity. Sure, so I just pulled up. I'm not, yeah, I'm not gonna make viewers actually read this, but here's the BBLLC sub-chapter that creates this entity. And you can tell, as you can tell, it's super lightweight. It's very, very lightweight in the requirements. So our operating agreement is actually about three and a half pages long. It's one of the shortest operating agreements that I've seen because mostly what our operating agreement says over and over again in different ways is this action, this process, this administrative function will be decided upon by the Dow's decision-making processes. So the operating agreement itself is actually, there's not a lot of requirements of what to put in there besides specifying the type of blockchain code that you're delegating responsibility to and talking about maybe like a security protocol if there's a bug of what you would do. So if you see here, all you have to do is specify that you're a BBLLC in your operating agreement and then also have these different provisions. So stuff like that you would have in a normal operating agreement like summary of the purpose of the company. What kind of blockchain is it? What kind of voting procedures do you have and how do you respond to security breaches? How do new members join? And what are the rights and obligations of the participants within the BBLLC? So we knock these out with the help of again, Oliver and Gerville and Shea in a three to four page operating agreement. So it's very lightweight and there's gonna be some differences with different kinds of Dow's. Not everyone is gonna go the route that Dorg went with our worker-owned freelancer cooperative. Some people want more traditional kind of mainstream ownership structures that can also be replicated in Dow's. Of course, we think these are more interesting because the kind of scalable, programmable, non-hierarchical organizations that Dow's enable is really what we tried to hit on with the language and our operating agreement. So what we're gonna do pretty soon is once we mark up the legal agreements that right now are just in your traditional Microsoft Word document, once we turn those into a nice web-friendly template using the open law markup language, we wanna, first of all, open source them and also include them into the flow of this Dow creator. And so have them be auto-generated by those extra fields that you would put in, such as what's your security procedure? And we could have ours pre-filled in for that and would give the user the option to write out different ones. And yeah, just at least one of the members, you need their name, legal name and mailing address just for the articles of organization you need that. And that's about it. And as far as I can remember right now in terms of additional information that you'd need for the operating agreement and the formation documents. Perfect. And so just as a, it's just a word, I guess, cross-walking and tracking the legal requirements and traditional legal entities to this new form of legal entity is the idea that the member and address that is listed in the initial filing would also serve as the contact for serving legal process and legal notices? Exactly. So that's an interesting problem that we had to architect the solution for once we started was that the state does need a single point, you might say a centralized point of contact to serve notices to. And yeah, everything you were mentioning. So the route we went is we have what's called, we have a manager or an administrative participant that has no material power or special governance privileges. The DAO decides all governance decisions according to its encoded procedures. But we do have this member with these formal responsibilities maintaining the mailing address, answering notices, filing taxes. So we have a member, and I say member, it's one or more. So since we're still small, we only have one. But you can imagine we could set up some rule like for every 10 members of the DAO we need one more admin, just in case one admin is on vacation or not checking their mailbox. So anyways, we have built into the architecture of the legal entity, this administrative participant who first of all could be switched binding in a legally binding way by the vote of the members. So for example, if the admin is being negligent, being slow to answer and getting the DAO into sort of trouble like filing taxes incorrectly then the members can elect a new administrative participant. Another kind of interesting kind of trick we added into the agreement was that the administrative, the members may require the administrative participant to post a surety or a bond to enact their services. So you can imagine I as the administrative participant might have to put up two months worth of pay to be the administrative participant. And if I ever disobey the DAO or become negligent the DAO could slash and take away the bond I put up. And so simple things like that we think can kind of keep a centralized single admin honest to the DAO in addition to rotating it frequently. So something we've talked about is having a something enacted at the social consensus layer where every six months or so we might just swap admins just to make sure that power can't like accumulate in this form purely formal rule. Perfect. And no, I'm not familiar with this aspect of Vermont LLC law but can the member that is listed for administrative purposes, if we just assume there's one for the moment be itself a corporation or an LLC or must it be a natural human? That's a great question. I think we considered having, for example, our law firm be the administrative member which is kind of I think where your question's leading. And I'm not sure about that. I think that that might be a nice solution to have sort of established companies or even companies that are specialized in this role be the administrators for these DAOs that don't want to have to deal with the meat space. But that's a great question. I would ask Oliver, I might ask him that. Okay, great. So let's definitely follow up on that. I wish I'd asked during the interview segment last time. And then the other question sort of kind of along those lines is when the member listed as the, you know, basically point of contact changes like say by a vote that's happening on chain then is the idea that for that to then become official and finding that someone somehow, somewhere has to make basically an amendment or some other filing with the Secretary of State's office to update that information and name and address? Exactly. So the vote to do so would be binding. And so then it would be up to the newly voted in administrator to go and do that or to the current administrator to switch that. And for example, if there was an issue where the current admin refused to do it, you know, any of the members could, for example, bring suit against them and have this evidence along with this operating agreement to show that they're not the admin anymore. If that makes sense. Yep, that makes perfect sense. And that's exactly what I was, partly it was animating the question. So, you know, I think what you've done here and I definitely wanna play with the code and, you know, try a few things but based on the demo, it looks great and it looks like a huge stride and like you've done a lot of work over the last few months and weeks. And we're thinking here at MIT, I guess with the benefit of taking like a long view and, you know, over the horizon visual kind of vision, thinking that some of the gap might be, as we alluded to earlier, that last mile connection between the software-based processes and the connection point, the authoritative connection point to the state government and then, you know, by extrapolation, you know, the tax authorities and the, you know, on and on the licensing and the permits or whatever else you might need, you know, filing with the Department of Labor, if you hire people and so forth. And so, you know, once that is prototyped and connected with one or more state governments and eventually in the fullness of time, a standard protocol arises that they can all implement in their own ways, it should be a goal to have more of a direct workflow that's verifiable from the organization to, for example, to change the point of contact from, you know, like Alice to Bob and then to have that filing, you know, digitally signed and authenticated just and happened without, you know, potentially being held hostage by the disgruntled old, you know, person or any of the errors or mistakes that could occur to thwart the will and the appropriate legal process that you've started. Yeah, and those are exactly the sorts of scenarios that we're right now mapping out and, you know, putting into language and that the reason that we went with the pilot-first approach where like the first step had needed to be incorporating as a BBLLC-linked DAO was so that we can throw a lot of these scenarios against the wall and see what happened. So we have an idea of what should happen. We have, you know, the way that the code is architected, the way that the legal agreements are architected and we have what we hope the process will be and so we need to just try these things out now. And so the plan now is to, first of all, just try manually these things. You know, I think within six months we wanna try to switch the administrative participant, like you're saying. Of course, we're not gonna simulate like a disgruntled admin, not switch it. You know, it'd be tough to simulate these sorts of things. But we do want to tighten the flow so that more and more happens in an end-to-end software-based context instead of hoping that some proposal passed, linking that to some GitHub document, you know, gets found for a lawsuit that needs to find out what the true state of the DAO was. So we're working on sort of tightening those flows and that kind of takes me, I'm actually, I agree with you, but I'm less concerned about tightening the flows when it comes to formation because formation is a one-time thing. So if you can call a lawyer in Vermont and pay, you know, 100 bucks to get them to file the paperwork for you, I don't see that as like the biggest bottleneck, although it would be nice that it's one-click and that there's no middleman. But to me, the bigger kind of piece that needs to be tightened is more in the maintenance on operation of the DAO. Like how do you switch the administrative member? How do you have a new member sign the operating agreement? How do you have a new customer sign the service agreement? How do you have a new contractor who claims a work order sign a customer or a contractor terms and conditions? So we have all these agreements. It's just the flows for cleanly signing it, checking it like the way that when you first use Gmail, you sign the terms and conditions. Like these flows that we're very used to kind of there's different problems presented in the context of having blockchain code but then also larger pieces of data that can't live on the blockchain that needs to be kind of owned by many different members in order to be resilient to any one individual misacting. Yes, yeah, indeed. And I think that's quite wise to start with what we call the basic or the baseline legal use case or just a filing in the ordinary course and not the edge case, hopefully of a disgruntled Ricalce of trends, like should be former point of contact is like the same as like holding your domain name hostage and your filing, all that stuff. But to go back to like the main thread of discussion, some of the, again, I also agree from experience that the most of what matters is the maintenance and amendments of the legal entity and maintaining it. But some of the reason why for purposes of the at least the current draft automated and autonomous legal entity challenge that we're trying to put together at law.mit.edu, part of the reason why we're starting that at the birth event of formation is based on a sort of, I guess I call it like a first order concept of an appropriate design where what we think is the authentication. So let's say the private key associated with the signature for the formation ought to be traceable through just normal audit on chain to those that controlled authorization of the signature. And then if for some reason or another, the key needs compromised or expires or whatever you use a new curve or whatever, for any reason at all, you kind of pass forward to a new key, there should be ways to sign that and have continuity. But the real way to do that so that the DNA of the legal entity exists in a completely automated and autonomous fashion that is also completely legally legitimate and gives you all the rights and privileges and functions that you would want to have without opening these crevices for ambiguity and dispute and lawsuits, God forbid. It seems like just modeling it from birth through the whole life and all the mergers and acquisitions and transactions that happen right down through modeling dissolution which is a natural life cycle event of an entity. Paperwork there and some special governance and procedural things that have to happen and some thought about how to terminate things like the private key material and other stuff so that you don't accidentally keep building liabilities or confuse people about whether the entity's alive. So we're trying to at least at a very high level of abstraction and as simple as possible conceive of the life cycle of a legal entity that is absolutely legitimately all online, baby. Yeah, yeah, it'd be great to have every single piece with no kinks worked out and then modeled. And that's exactly kind of why we're hoping to get more people involved so that those different parts of it that other teams are tackling can just be put together instead of effort being duplicated. For example, OpenLaw has their very nice user-friendly, attach an email to a public key sign, get the email, execute the agreement, hash it, put it on the blockchain. So that's why part of our next step is to mark up the agreements that we do have with the OpenLaw markup language. So that, and they also have a JavaScript library which is really nice because that means we can build that little screen into the Dow creator I showed you that's using OpenLaw to auto-generate the contracts based on the markup document. And that's the goal, definitely. Awesome, and the kinks you have worked out for the, I mean, I guess the way I referred to it last time was a birth event and a dissolution is fine but what we're really talking about is just the well-functioning of a legal entity like in the most of its life. And that's what you've taken, I think, where your focus has been and I think where you've really excelled and that is appropriately where the focus should be to make progress and where the value is and so I just think it's very impressive but let me come back to one critical thing that you just said. Don't worry, it's good, not bad. You said you wanna set things up in a way where other teams and people can help. So that naturally raises the question if people that have become aware of this say to themselves, I wanna get on Team Ori and I wanna kind of get an oar and start rowing on the doorknob. How, what could they do and how would they get involved? Yeah, absolutely. So you could contact me directly like Ori at doorknob.tech or the best place to kind of get involved with the conversation is our Discord server which you can include a link to in the show notes. I might have already given that to you but we have a chat there specifically about the legal process but the place where really the research is happening or at least the documentation of the research is happening is in our, we have a GitHub repository that's kind of lays out the big picture. What's the high level research process? What are the stages? Where are we at? What are the outcomes that we hope to achieve? And so I can share that with you too and it's a collaborative document. So I'm not the only one editing it. There's, when people see a mistake or they see a new section they wanna add they just do a pull request. And that's sort of for the people that feel safe with Git. I know a lot of the people on the legal side probably feel safer with Google Docs or Microsoft Word. So we are gonna find a way to kind of let all teams get involved. But I think right now we're just kind of forming the interest and seeing what form the project can take and who the main participants could be. And then after that we would have calls where we'd formalize things and take next steps. But the kind of guide, the big master high level document I can share that with you. And it'd be great to get feedback on that from anyone. Or yeah, like I said, contact me directly. Okay, so let's, then we'll get back to the screen. So I wanna screen share something that I hope you find enticing and delightful. Did you, did you, did you, did you, did you, did you, did you? Okay, can you see this? I can. Wait a minute, can you see this? Can you see like the page scrolling? Not yet. Okay, well, we'll catch up. Oh, wait a minute, maybe I've, wait. All right, one moment. Okay, can you see the window? Oh, then I can share my entire screen. Okay, there. Can you see the screen? Yeah, yeah, I see that. Great, so if, for those of you that are listening, if you come to law.mit.edu forward slash bdlc, we've got from this very, this kind of meta, this very video that we're still actually doing, it looks like it already has an arbitrary screenshot of it that will probably change from the demo. This is part one of the demo with you, Ori, and a friend, good enough, I'm not sure if we're much long among other athletes, who I know is good on this. And here, did you just look earlier? Yes, it does. That's what I was talking about. Yeah, if you go actually a level out to just the, maybe be better just to link to the repo and not to read me. Okay. Yes, just that. You want to see me do it? I would love to. I'm worried about it. Wait, don't do it right now, this thing's gonna never happen. So go like this and boop, and let's just save this, bang. Magic. Oh, that's better. Okay, that feels good. Now go here and we'll refresh it. Oh, wrong thing. Okay, so there you can find the actual organization, the best way to contribute is of course, always go directly to the, there we go, it updated to the repo and get involved with Ori. And then if you'd like to learn more about it and help us crack this challenge, this open challenge that we're looking to drop around the time of the first publication of the MIT Computational Law Report this fall, you can hit that last link and this is very drafty right now, but we're looking to, no idea how I just did that, but we're looking to have people basically help begin framing out how to do the entire life cycle of the entity system. So the formation, some ordinary stuff as it's alive, the dissolution of the legal side and signing of contracts and some business and some kind of business transaction of any kind, you know, whether that's some, well, so what kind of business interactions? So it seems like you can, you can authorize the expenditure of ETH and you can hold, I suppose you can easily hold assets as a, Yeah, you can actually, you can do any arbitrary transaction on the Ethereum blockchain and that's a Turing complete blockchain. So it's any computation imaginable. Of course there's expenses to expensive computations since the blockchain, but like for example, you can, I can make a proposal for Dorg to take out a loan on the Dharma protocol or to bet against the price of Ether or I could make a proposal for us to post a bounty on a bounty network. I can give you a million examples but any kind of Ethereum project that you've heard of and what the kind of stuff that they're enabling that's meant for users, our DAO or any DAO could be that user. So it's kind of, it's a nice modular process where our DAO can do any arbitrary action. So, you know, 90% of what we do will just be, you know, reward Ori for this many hours of work, give, you know, give this person this much voting shares for their contribution. You know, it'll just be very simple, like reward people, move around voting shares, admit new members, but we could do any arbitrary Ethereum transaction. So anything you've heard of Ethereum smart contracts doing, like that could be an action that the DAO takes. Outstanding. So well then that would be part of how we're conceiving of this challenge would be somebody to be able to spin up the entity, do some kind of computer business transaction, purchase and sale or something of that nature. And then, I think that's basically it right now. And then the other part of the idea is to see if it's possible for someone to, we have something called a data playground where most of it's for more like data science projects, not so much developer projects of applications, but for this particular challenge, we were thinking, oh, I'm sorry, and for the data science to really emphasize the science part of that, looking for people to upload the, not just the data set, but also like the script they use to create the, you know, the analytics or the visualization or whatever they did in a way that third parties that weren't a part of it at all could reproduce the same results. That's like the beginning of a scientific method. In that spirit, we're thinking of, for the legal entity, that whoever would win the challenge, which is how we're currently conceiving of it, that a third party could basically run the same code and scripts and configure it themselves, so the name of their legal entity or what have you, and that they would get the same results that if you look, for example, at the Secretary of State's site, you would see, yes, there is in fact a valid LLC of this name and this is the point of contact and it corresponds to the point of contact script and so forth or something like that. How does that sound to you? Is that sound the right way to do it? Yeah, definitely making it replicatable sounds the way to go, because like I was saying with our legal agreements, right now they're hard-coded for Dorg, but you know, it takes not that much effort to use OpenLaw's markup language to replace Dorg with your company and you know, they just go on OpenLaw and they fill out the blanks and it generates this legal agreement that just like we had, but for their specific use case. Yeah, and then taking that to the next level with actually looking at like registrations and the flow being automated that way. I do wonder if Secretary of State's Office of Vermont and I think almost every state does have a web portal and so one could conceivably build like a wrapper for those portals that does the fills in the fields, hits the buttons. That's not a great way to go about it because if the Secretary of State's changes their website a little, it breaks your wrapper, but if one might work more directly with the Secretary of State's Office and sort of have them expose or help them expose an API that would be less prone to change then I think the end-to-end process that you're talking about shouldn't be impossible. Yeah, indeed. The way you're talking about is 100% in sync with how we're looking at it. Again, in the fullness of time, maybe starting idiosyncratically with one Secretary of State and then eventually coming to something that's generalizable, more like a protocol that could be like a type of microservice or a general API that could be implemented for whatever the different systems are and processes and so it could be updated in sync. Yeah, sort of like an API standard that you make one version of, you work with one Secretary of State's Office to implement that standard and then you can go to others and say, hey, look at the standard, it's just a protocol and no one owns it. Do you want to implement the standard or have someone implement it for you? Yeah, just so. In a way, so one part of the API in theory could be the date of the annual filing or if it's bi-annual filing such as become something that each jurisdiction can configure, but it doesn't break the API and so therefore when they change something, oh, there's something different from jurisdiction to jurisdiction, changes in a given jurisdiction over time, as it does. You don't run the risk of your entity becoming involuntarily dissolved for failure and bureaucratic requirement. And again, this is the kind of over-the-horizon stuff. Right, annual reports are definitely an annoying manual process that yeah, having LinkedIn would be ideal. In the meantime though, it's something that's getting more attention by big law firms. Now, we're talking to a friend of a program here, Bob Craig, who's CIO of Baker Air Hostetler who's quite active in the space, is called RPA or Robot Process Automation, I think is what that stands for. It's just a little bit of a new label on old wine, but there's a set of companies that it's got some kind of buzzword cred with Gartner and Magic Quadrants now for automating kind of processes, including legal processes that are somewhat repetitive. I've been definitely filling out web forums and passing information from one service or app to another and so forth. So to the extent that you have some humans in a loop or are going through a law firm or a company that specializes and whose response we're staying up to date with jurisdictions, it could be another way to bridge that final mile between the entity that's living on the blockchain or in other automated processes and creating and maintaining appropriately the legal entity status with the jurisdictions and being able to adapt as things change and not kind of drop at all. Yeah, always have to have someone checking the, yeah, a bureaucrat in a loop. Yeah, a bureaucrat in the loop, that's great. You've done it again, Ori, you've coined a great phrase. So let me just ask others in the room, Robert Mahari among others, any other questions we had to ask? No, we're feeling good here. Anything else that you'd like to say at this time, Ori, like closing point? Yeah, that's all, just that this is the first step in this is where the work begins. So if anyone wants to help and become a part of the work, then reach out. Yeah, then please do reach out. We'd love to see this project continue and to keep growing and then to use it. So thanks very much and congratulations to the whole team for how far you've gotten and really look forward to seeing this blossom over time. So thank you, Ori. Yeah, thank you again. Thanks.