Charting Zodiac & DAOs with Nathan Ginnever and Auryn Macmillan

Anna Rose (00:00:05):
Welcome to zero knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web. As well as new paradigms that promised to change the way we interact and transact online.

Anna Rose (00:00:27):
This week, we dive into DAOs, with Zodiac, a standard for composable DAO tooling. Guests Nathan Ginnever, Auryn McMillan. And I chat about the origin of the Zodiac project, the learnings they gathered from earlier tools like Gnosis Safe and Safe Snap. We do a run through of the components that make up the Zodiac standard, new upcoming innovations, the emerging trends in DAOs and their management, and more. But before we start in, I wanna encourage anyone who's looking for a new opportunity to work with the teams, building ZK tech, to check out the ZK jobs board. There we have teams from our community posting their open positions. It great place to find your future collaborators. We've added a link in the show notes. Now I wanna pass the mic to my producer, Tanya, to tell you a little bit about this week's sponsor.

Tanya (00:01:11):
Today's episode is sponsored by Polygon. Polygon is one of the top Ethereum scaling platforms for developers with over 130 million unique user wallets. They are known for Polygon POS chain. One of the most popular chains built on top of Ethereum, sometimes clocking even more daily active users than Ethereum itself. And the team is actually working on a spectrum of solutions, including EVM compatible, zero knowledge rollup solutions like Polygon Hermez, Polygon Miden and Polygon Nightfall, which is built in association with Ernst & Young. They also recently announced their acquisition of Mir Protocol, now known as Polygon Zero. These solutions inherit the security of Ethereum and use the power of zero knowledge. Over here at the podcast we have been tracking Polygon’s journey and have even recently had Bobbin Threadbare from Miden and Jordi & David from Hermez on the show to talk about their respective projects. We strongly recommend you check out those episodes to learn more about their vision, project roadmap and progress so far. Polygon is also hiring and have a few jobs listed on the ZK Jobs Board. You can check out that link in the show notes. So thank you again, Polygon. Now here is our deep dive into Zodiac.

Anna Rose (00:02:21):
Today we're gonna be exploring Zodiac, a standard for composable DAO tooling. And with me on the show, we have Nathan Ginnever an applied cryptographer working with Gnosis on the Zodiac tools and Auryn McMillan, a product manager and solidity developer who co-founded Gnosis Guild. So welcome to the show Auryn and Nathan.

Auryn Macmillan (00:02:40):
Hi Anna. Thanks for having us.

Nathan Ginnever (00:02:42):
Yeah, thanks having me.

Anna Rose (00:02:43):
So I did an episode with Martin from Gnosis, I think about, let's say eight months ago, and in that episode we talked about something called SafeSnap and, you know, Gnosis Safe and how useful like that, that multisig had basically become this tool for DAOs. And as I understand it, Zodiac kind of came out of that. We also mentioned something called the Gnosis Guild. So maybe you can give us a little bit of a sense for like, what are these different elements? How are they related?

Auryn Macmillan (00:03:17):
I guess late 2019, we started making kind of very concrete steps towards launching the Gnosis DAO. And in doing so did this kind of wholesale review of all of the DAO tooling in the space and, and essentially arrived at the conclusion that none of it quite checked all of the boxes that we wanted for the Gnosis DAO and in particular, those kind of three boxes that were really hard to check all three with the existing tooling. So one was, we wanted to use a framework that was, you know, proven to secure really, really large amounts. So the, the Gnosis treasury is, is really large. I mean, I think it's somewhere around 600 million in various assets in the moment. So we needed something that we were really comfortable to, to kind of migrate that treasury into the next one was not wanting to price participants out of participating, not wanting to price out voters with the kind of cost of on chain in voting on on mainnet.

Anna Rose (00:04:22):
Is that like gas fees?

Auryn Macmillan (00:04:24):
Yeah, exactly. So like the, the the fees associated with voting on mainnet particularly around the time we were trying to launch were, were absurd. You know, like a, to, to cast a vote, say an Aragon hour or a Moloch or something like that would cost you know, hundred dollars to, you know, a few hundred dollars. Often just because of these kind of absurd gas price spikes. And so, you know, for someone who has only a few hundred dollars worth of governance tokens in a DAO, it just doesn't make any sense to, to burn that amount to to participate in voting. So we're very conscious of to lower the barrier to participation as much as possible. And then the third piece was wanting to make sure that we didn't get unreasonably or unnecessarily lock ourselves into one kinda particular path we wanted to, you know, maintain maximum possible future flexibility. And so it, the end it ended up I don't know, I guess maybe somewhat, obviously we, we ended up landing on the Safe as our best kinda possible foundation for this and decided that we would lean into a pattern that already existed in the pairing of the Gnosis Safe with Snapshot. This, this was kind of a, a pattern that emerged fairly organically from response to kind of DeFi summer. And this was yeah, most of the tooling didn't work. And so we, there was this kind of really common pairing between GnosisSafe and Snapshot that they kind of emerged as a, as a de facto standard for a lot of the projects spinning up or kind of wanting to, to kind of become more DAO like during this kind of defi summer. And so leaning into that trend, we said, oh, how can we give Snapshot instances more concrete control over, over Gnosis Safe.

Auryn Macmillan (00:06:17):
And so that's where this SafeSnap plugin and the kind of underlying contracts, the reality module were born. And that essentially kind of snowballed into what is now the Zodiac ecosystem, the Zodiac standard and all the kind of suite of tools and, and the whole kind of mission behind that. And I guess to, to kind of disambiguate that from Gnosis Guild from Gnosis DAO, essentially Gnosis is the system of legal entities that exist in the real world. Gnosis DAO is this kind of illegal DAO structure that was spun up relatively recently. And, and now is the kind of custodian of, and steward of the, the kind Gnosis ecosystem and the treasury for the Gnosis ecosystem, Gnosis Guild is a team that has spun out of, or is in the process of kind of spinning out of Gnosis, to kind of specifically steward the Zodiac ecosystem, which is this of essentially standard for composable DAO tooling along with kind of a collection of tools built to that standard.

Anna Rose (00:07:24):
Cool. So do you see the Zodiac standard as sort of a competitor to what was there before things like the Aragon tool set, or do you see it at a different point in the stack?

Auryn Macmillan (00:07:37):
Yeah, it's, it's definitely not intended to be a competitor. I mean, a lot of the stuff that tools like Aragon, Moloch or DAOStack, or Compound governor or any of these things do, we don't do natively rather what we, I think like the really key insight is the idea of kind of decoupling your account with the mechanisms that control it and in doing so kind of enabling a whole bunch of possibilities and, and avoiding the kind of platform lock in that that you kind of may end up in otherwise. And so I guess, to, to illustrate there, what I mean is, say you were to start off as a as an Aragon DAO and then six months down the road you wanna migrate and become a Moloch DAO. He just said, Hey, Moloch does this thing that we like better. And so now we wanna be a Moloch DAO to do so. Now you have to kind of create proposals to move all of your assets to update all of the systems where your DAO might be a, an owner of some kind of external contracts to update all of the external references to your to your DAO, probably on a whole bunch of websites that you don't control. And so you kind of have this monumental coordination challenge to move from kind of one framework to another. And so what the, the really kind of key insight is for for Zodiac is if you decouple those two things, if you treat, if you basically have an account that you can then plug those other mechanism in, into you avoid those kinda monumental coordination challenges. Now, if you want to move from Aragon to Moloch, you use one proposal to enable Moloch as a module to your account and disable Aragon as amodel to your account. And so I wouldn't say it's a competitors to those things. Instead, I would say it's a way of, of making all of these tools much more composable interesting. They, they can kind of exist in, in one ecosystem and, and kind of work in parallel on one kind of one organization, or kind of in parallel as part of one system that kind of is, or represents an organization.

Anna Rose (00:09:44):
Nathan, I wanna hear a little bit from you about when you kind of joined this project and what your contribution, like, how you're contributing, cuz you're an applied cryptographer. So I am curious like where, you know, where's the cryptography actually?

Nathan Ginnever (00:09:57):
Yeah, that's probably just a, a fancy word that I use to say, I take the hard work of real cryptographers and then put 'em into things like solidity contracts and, and hash things together. And, and do yeah, merkle proofs that, you know, simple stuff like that. Right. But I think it's kind of cool how I came about this project. I was getting interested in building a DAO and building, you know, a DAO you start to look around the landscape and you'll look at the Molochs and the Compounds and the the Aragon and the, and the DAOs Saxons, you know, the first kind of thing that came to my mind was this, this idea that, that, or mentioned about not having the ability to decouple away from the stack, if I wanted to. Right. So I was like very kind of conscious ahead of time to, to want a system that would be flexible and something that I wouldn't get locked into. And at that time I didn't see anything that would facilitate that. So I just started going off and building and started to create my own stack and I was building my own stack and I realized that my stack would just be like every other stack, if I didn't find a way to make it easily upgradeable. And that's when I kind of saw, you know, what was happening with with Snapshot and the Gnosis coupling. And I kind of came to the same conclusion independently that Gnosis was coming to in the same timeframe that the, the safe makes like a, a great base layer to stack a bunch of other tooling on top of. And so I started building a system that's you know, similar or composable with Compound. It, it runs in the same sort of manner is Compound delegated votes. And I intended it to be stacked on top of the GnosisSafe and nowadays as our or mentions these things are not competitive. So we, you know, you'll see things like Aragon supporting the ability to plug in the Gnosis Safe and to make calls and send Gnosis Safe in a way that looks like the Zodiac standard. So we can kind of see this, you know, nice connecting point between all of these different frameworks and, and swap them in and out as we please. And it also, I think, is, is cool for experimentation as well, to, to be able to, to try out new forms of governance and new patterns to build tooling around.

Anna Rose (00:12:17):
When you use the term standard. Like, I keep thinking that there's like these components, like a ..., like a module and stuff like that, but when you say standard, maybe can you, can you kind of explore what that actually looks like? Like, how do, like, is it, is it that each side, like Moloch, Aragon, would they have to plug something in like, yeah, what is the standard part of it?

Auryn Macmillan (00:12:41):
Yeah. So when we say standard, we really mean kind of like a standard way of building tools so that they can play nicely together. And so essentially what we've done is just take in the interface that already existed on the Gnosis Safe particularly the, the module interface. There's a handful of functions add module, remove module execute transaction from module, execute, transaction from module, with data. And these these basically form the base of the, the kind of Zodiac standard nows that we, we kind of used the safe as our prototype for what this standard should look like. If, if we want to have external contracts come and own a Gnosis Safe or, or kind of any other avatar contract that that would represent the kind of core of the organization then that it should essentially implement this interface. If you want to be build a tool that can, can plug in and control these things, then it should be able to interact with this interface. So when we say standard, we really just mean, like it's a, it's a standard way of kind of building up tooling so that they can kinda be stacked together and play nicely together.

Anna Rose (00:13:48):
Got it. So it's sort of like it's particular, I'm just picturing from the Moloch side, for example, like, are they already built that way that they can easily lock into the standard? Do they have to, do they have to do something?

Auryn Macmillan (00:13:59):
So the nice thing with most of the existing DAO tooling is that they generally have some method by which they can make arbitrary contract calls. And so because of that, they, they kind of are compatible out of the box, even if they're not gonna explicitly designed to be compatible because they can make arbitrary contract calls, arbitrary function calls, then they're able to interact with that interface that I just described. And then the, the kind of more explicit step usually is baking that into the interface somehow. So going in and adding the, the ability like the, the guys from rate Guild, and DAO Haus went and built out the ability to control the Gnosis Safe from a DAO Haus DAO to kind of explicitly add support for this kind of standard and this feature set.

Anna Rose (00:14:49):
And just in terms of dating, sort of what, at what point did well, and we'll get into the components of Zodiac, but like, at what point do you feel like Zodiac really arrived because you you've talked a little bit about this evolution, right? Like it was Gnosis Safe, snapshot, Safe Snap, like where does Zodiac start in this, us in this trajectory?

Auryn Macmillan (00:15:12):
Yeah, we, we kind of officially announced it on September 4th sorry,14th last year. So maybe that, we obviously been thinking about it internally for quite a bit longer. And we pulled Nathan into to a lot of that discussion quite a bit earlier, but I don't think it had fully materialized publicly into Zodiac until then.

Nathan Ginnever (00:15:35):
Yeah, I think in back then there was less general EVM calls by some of the platforms and the standard part of this. It, it creates this ability to stack tools together in a nice cohesive way. And so things like what Rate guilt did to to get the Moloch DAO to, to be able to plug into the standard opens them up to trying some new things as well.

Anna Rose (00:16:01):
So I think it's a really good time now to start diving into the components of the standard, because I feel like some of them, I mean, really you can see existing, concepts ideas, products that have sort of been incorporated into this, but there's a new, I guess, framework. Is that an okay way to call it like a, a bit of a framework for thinking about these different components? Yeah.

Auryn Macmillan (00:16:24):
I think that's a perfectly fine way to think about it.

Anna Rose (00:16:27):
Cool. All right. So let's start with these kind of the components, and maybe we'll start from something that we are somewhat familiar with, which is SafeSnap, although we should potentially redefine it for the listeners who didn't hear that previous episode. So what was SafeSnap and what is it in Zodiac?

Auryn Macmillan (00:16:46):
Yeah. so it hasn't really changed since launching Zodiac, but so what SafeSnap is as a, so actually a way of bridging off chain votes on snapshot to on-chain execution via a safe and doing so in a, in a kind of trustless way or a way that's kind of secured by game theory. It's actually, it's a pretty novel mechanism that most people haven't interacted with and, and rightfully so, a lot of people are a little bit spooked by when they first kind of realize what actually is under the hood, but it's, it's really cool.

Anna Rose (00:17:19):
It was taking from what I remember, it was taking the sort of off chain signaling component of snapshot and forcing sort of an on-chain execution. So it's like, your vote actually will happen. Not your vote is a signal that you want something to happen.

Auryn Macmillan (00:17:37):
Right, yeah. And so the, the way that, that works, so there's, there's there's this Oracle problem here, right? Like you, it's an off chain vote and you have to somehow get a representation of it on chain and you want that representation to be truthful. And so there's a whole different whole array of different ways that kind of Oracles can function and do function out in the wild. And the one that which chose is called reality.eth, so the underlying contract for our SafeSnap is actually we call our reality module. And it's, it's kind of generally applicable. You could use it to bridge outcomes from snapshot like we do with the SafeSnap plugin, but you can also use it to you could bridge outcomes from just about, anyway, you can have discord polls or Twitter polls, or you could roll dice or flip coins or whatever you want to, to trigger execution so long as the, the Oracle can kind of verify that the outcome happened. And so anyway, the Oracle is really, really cool it's an escalation game. And so basically what happens is you ask it a question, you say, did this proposal pass, and then anyone can come and set the outcome of that question to set the outcome. They have to put down a bond when they put down the bond, then kicks off a timeout period. If that timeout period ends, then the answer is set. But at any point during that timeout period, anyone else can come and double the bond to change the outcome that resets the timeout and, and kind resets the game. And so that process continues on and on and on until the timeout eventually ends. And so, because the bond is doubled every time the bonds can get kind of unreasonably large very quickly. Okay. And so the, the way that the kind of game theory plays out is that at the top of the escalation game, the shelling point is the true outcome as the outcome that, that should resolve to it's essentially, that means it's much easier to coordinate around the, the true outcome than to coordinate around a false outcome.

Auryn Macmillan (00:19:38):
And so the, the bonds have gotten so large that people need to start pulling capital to, to make them. And so they're going to, it's gonna be much easier to pull toward the shelling point, the true outcome than the, the false and so, because, you know, that's how the top of the escalation game will play out. It's, there's very little motivation at the bottom of the escalation game to try to sneak a a false outcome through, because you're essentially just paying the person who comes and doubles your bond to set it to the true outcome. And so like in practice, we very rarely see the bonds move beyond just the first bond. Usually someone puts down the first bond, they set the right outcome, and that's all that happens. Every now and again in, in other contexts, we've seen the escalation game play out through, through a few levels. And then in, in some like in Omen prediction markets case, we've seen it actually kind of go all the way up to then being kicked off to an arbitration, which is an option in kind of Kleros court. And that is, is a really fun process to watch as well. I'd recommend going searching for Kleros case 302, if you wanna dive into that more there's some, some really fun stuff that you'll find on YouTube around that. But yeah, in general, we don't ever see it progress past the first bond, because there's just no incentive to lie on it.

Anna Rose (00:21:04):
I actually, as you were saying, this, it did, it showed echoes of what I had understood sort of the Gnosis work before, when they were doing prediction market stuff. I don't know that they had exactly this game, but this idea of bidding for truth, and like somehow putting up money to kind of make a vote or prediction or say some sort of truth, this sort of has echoes of it. So you mentioned two things though, Omen and Kleros court. Can you, can you say what those are actually?

Auryn Macmillan (00:21:33):
Yeah. Yeah. So Omen is a prediction market. This is the one of the prediction markets that kind of Gnosis helped to bootstrap and its Oracle mechanism, the way that it brings kind of results from real world events on chain is reality.eth. And so this is obviously the, the kind of connecting thread that landed us on this. It was an oracle that we were already comfortable with that we understood how it worked, and we were, were confident would work well in this context as well. And then Kleros is the arbitration option that Omen uses. So it's a it's a decentralized kind of court system. And one of the options for reality.eth is to select a arbitration option that could be used if the question goes kind of too far up the escalation game, and you just want to get a definite resolution out of some other mechanism. So reality is kind of agnostic to the arbitration option that it uses Omen users Kleros as their arbitration option for the reality module. Most of the time we don't, or at least like the ones that we've helped set up and obviously like for the Gnosis DAO and stuff, we don't have an arbitration option set. But for, yeah, for other DAOs using it, there is an option there to set an arbitration option. If you do wanna be able to defer to something like Kleros court or some other yeah ultimate arbitrator for those outcomes.

Anna Rose (00:23:00):
Cool. So just to recap this though, so this is reality and reality is, was SafeSnap with this, like was the oracle kind of escalation game already in SafeSnap before it became reality or...Okay. That was like already connected.

Auryn Macmillan (00:23:17):
I think the, the naming here is probably pretty confusing. So reality.eth is the Oracle and then o ur module, we ended up calling the reality module because it's basically deferring to reality.eth get its decisions.

Anna Rose (00:23:32):
Got it. So this is, but this is one of the components, right? This is one of the pieces modules of Zodiac. Yes, no longer called SafeSnap more. And, and now you've kind of rebranded that also as reality because it calls the reality.eth contract.

Auryn Macmillan (00:23:46):
Again, naming's probably confusing. So SafeSnap is still a thing like SafeSnap is to the setup. That's just how we refer to the setup with snapshot. So you have this kind of plugin within snapshot, that is the SafeSnap plugin. And so it's kind of, I guess a distinction between the kind of application and the contract layer piece. So at the contract layer, it's called the reality module. And the reason being is that it's, it's use case agnostic. Like you could use it for snapshot as in like SafeSnap, or you could use it for bringing information from just about anywhere else. So if we wanted to set up a similar similar thing with discord or tool at polls or anything like that, then we'd use the same reality module and we plug it into discord instead. We plug it into Twitter instead, and you have a bot kind of running on, or yeah. A bot or something else like that running on on that platform rather than on snapshots platform.

Anna Rose (00:24:42):
Sorry. I think I missed this though, the app, but you sort of mentioned like the, the contract level, but then the application level, it is also called reality or

Auryn Macmillan (00:24:50):
At the application level, it would be called like in snapshot's case, it's still just called SafeSnap. Okay. And so, yeah, this super confusing. I know it good to know though. Snapshot is how we would refer to it. If, if like we'd refer to this kind of, this whole setup of, of a snapshot instance with the SafeSnap plugin that, which is connected to a reality module, which is connected to a Gnosis Safe. So like the shorthand way of saying that whole thing is SafeSnap. But then yeah, there's all these kind of separate pieces that make it up.

Anna Rose (00:25:24):
Okay. The next thing listed after reality was Bridge. Is Bridge a component or is bridge, as we understand it, bridges to other things, what, what is Bridge?

Nathan Ginnever (00:25:36):
So Bridge is actually a pretty exciting one for me. So what we just talked about with the reality module is, you know, a system to collect votes in, in an effective way, right? Since gas prices make it, you know, hard to do certain types of, of voting, you know, you have delegation as the primary means of on chain voting. And part of the reason for doing that is to make the gas costs reasonable. So reality is a, you know, type of bridge, you know, using an Oracle is a type of way bridging data to the main chain. Okay. And the bridge, the bridge module is you know, a Zodiac module. And so we could clarify what modules are inside of Zodiac and, and modules are a piece that can plug into the Gnosis Safe, and they can do anything as long as it follows this connecting point standard to get information from whatever you want to code in your module over to the safe and bridge is a particular module that is intended to pick up data from other chains.

Nathan Ginnever (00:26:42):
And the current bridge implementation that we have right now is working with the the Gnosis chain formally known as Xi chain. And it is intended to take bridged information from that chain. And so you can do things like put a voting system on an alternative chain and then do the more expensive parts, which would be collecting votes from people and have the final result, you know, bridged over to the asset manager where you're holding the majority of the things that matter and the more secure or robust chains. And that's one example of using the bridge. That's, that's the example that I'm particularly excited about out. But in, in general, it just will bridge any data from that chain.

Anna Rose (00:27:27):
That's cool, too. It kind of speaks to the problem that was highlighted earlier, this idea of gas fees. So if you were voting on the L2 on the Gnosis chain, then it would be quite cheap. And anyone, even with a small amount could actually do their vote without noticing kind of, you know, any of their, of their holdings being drained away by gas. And yet the execution would still happen on the main chain. So you just mentioned though, like bridge right now is the Gnosis old xDai by the way, is that, when did that happen? That's like really, really recent, right? This is like, like xDai is now Gnosis. When, when did that happen?

Auryn MacMillan (00:28:04):
Within the last few weeks. That sounds, yeah, that's really, really, really what he said.

Anna Rose (00:28:08):
It's very cool though. It's a really amazing evolution there, but yeah. So right now there's that sort of, there's, there's something called bridge, which bridges Gnosis, to the L1 being Ethereum, but like, is there a plan for this to also be dealing with all of the other L2s can you imagine this actually even be being used on like other EVM compatible, non L2 chains?

Nathan Ginnever (00:28:33):
Yes, absolutely. And that's part of some of the research that I'm actively working on right now. And so what we really want is the most trust minimized bridge possible. And so there are trust assumptions to most of these bridges. Even in Oracle with an escalation game, has, you know, some assumptions with the the game theoreticals there and with the bridging mechanisms for the Gnosis chain it's fairly weak trust assumptions. It's some multisignature signers that will be able to pass the message over. So you know, that's not the most ideal way to secure the connection between, you know, where the decisions are being made and the actual assets that need to be moved or need to be dealt with or wherever the end point of those decisions are. You know, you want to make sure that's secure so that the, the bridging cannot corrupt the important parts of the things that are sitting on layer one.

Nathan Ginnever (00:29:31):
So we have the ideas of using you know, roll ups potentially. So there's an EVM roll up from ETH relay that will, you know, try to do header validation from EVM chain to EVM chain and header validation between, you know, say Bitcoin and Ethereum is rather simple. And this is because of the proof of work consensus mechanism that Bitcoin implement months that is fairly reasonable for the Ethereum chain to validate. But the Ethereum chain uses a bit more of a complex consensus algorithm with Eth hash and a lot of these proof of works. And these consensus algorithms started to pick up this idea of making them memory hard. And this is an attempt to keep them on GPUs as opposed to moving them onto ASIC very quickly. So you end up with you know, validation being a little bit more expensive and it's currently a little too expensive for the just base smart contracts of the layer one to be able to you know, validate these headers in the trustless way. So things like Eth relay are working on a bit of a roll up system, which would be kind of like a, a fraud proof game to be able to, to verify that these validations were done correctly, but we're also looking into zero knowledge for this as well. And there is a bit of research that's been done on being able to do these validations and zero knowledge, but from my understanding and my latest research, I think that that's still an open question being able to get a circuit that can do these kind of validations.

Anna Rose (00:31:08):
You're thinking of something like MACI, maybe like this is the, at least the most popular ZK focused schema that I, that I've heard of.

Nathan Ginnever (00:31:18):
Well, MACI is a bit of a different concept. So MACI is a, a voting system and I'll let Auryn get deeper into this cuz he's, he's very knowledgeable on this MACI system, but it's generally to prevent collusion and bribe attacks, but for purely bridging, you know, you, you could, I think in theory, think of using something like ZK EVM, potentially. Okay. Where you would, you know, run all of the, all the, on the EVM ZK - EVM chain, and then potentially, you know, all the bridging happens for every piece of state on the ZK EVM. So that would be like a natural bridge that is not ready yet. And there's still a lot of work. And I know you've talked to, I believe Matter Labs in the past about ZK EVM. Yeah. And it's a really exciting piece of technology,

Anna Rose (00:32:03):
I think. Yeah. And Jordi from Hermez is also actually there's I, as far as I know, there's like three groups working on ZK EVM right now, ZK EVM also has different meanings in different contexts. Sometimes it's like equal op code. Sometimes it's a compiling down to anyway. But that's a whole other topic and actual on the topic of voting. I actually wanna hold on that because I have more questions on that. So I wanna come back to it first. I wanna continue with these modules and I actually have one more question on bridges. So like there are a lot of, there's a number of bridge focused teams that are just building bridges, but given that this is very much like about taking a snapshot, not necessarily about like transferring tokens from an L2 to an L1, are you even looking at those alternative bridging technologies or companies something like, you know, XLR or like Nomad these, these kind of, you know, bridge focused teams? Is there any work on that?

Auryn Macmillan (00:33:04):
Yeah, yeah. Yeah. So, I mean, you you're spot on like most of the bridging that people do is concerned with moving value from one chain to another, from one layer to another. And so generally when you think about securing those bridges, that kind of hanging fruit or lower hanging fruit still complex and difficult to engineer, but the low hanging fruit is to kind of economically secure them, essentially ensure that the person who would be sending on the kind of destination chain is bonded on the origin chain. And, and you always have some way of kind of proving if they don't deliver on the on the destination chain. So you can kind of slash their bond or kind of recover your funds on origin. So they they're kind of incentivized to follow through on sending it on the destination because you've, you've got their money held hostage on on origin. The same isn't necessarily true if you're trying to bridge data, if you're trying to bridge state in that you may be trying to bridge data that would, let's say, control a system, or change a system that is much more valuable than what you could reasonably expect a kind of router to put up as a bond, you know, say, say, you're, I don't know the, the Yearn DAO, and you're wanting to change some fundamental piece of, of a Yearn vault with billions sitting in it. You obviously can't expect the router to have locked up billions in a bond so that you can pass some state across or alternatively, like if you're just trying to bridge something that has essentially no financial value it's you are just trying to bridge I don't know a, a message to someone or something, you know, when you said timestamp something then these things, again, that there's very little it's very hard to kind of assign a specific value to it, even though it is valuable to you. And so those, those types of bridges typically are kind of not suitable for this application. And so that's why we get into the territory of using things like the arbitrary message bridge that has this is the, the bridge between Gnosis chain and xDai, which has kind of an Oracle set that you effectively trust to have unilateral control over your over your thing on the other side which is much less than ideal.

Anna Rose (00:35:22):
You just said, you actually just said Gnosis and xDai, but I think you meant Gnosis chain and mainnet, right?

Auryn Macmillan (00:35:28):
Yes, Gnosis chain and mainnet or, or Gnosis chain to a variety of other chains. I'm still very much cool, cool. Trying to, to kind of replace xDai with Gnosis chain in my mind. It's I'm sure I'll slip out more than once. Fair enough. In the rest of the call.

Anna Rose (00:35:44):
It's very fresh.

Auryn Macmillan (00:35:46):
Yeah. So we, we're kind of actively researching other options. Nomad is one that I had previously written off and I think it was because of my own kind of misunderstanding how it works. And I guess maybe to, to get a little bit gritty in that I had kinda through reading through the documentation, come to the conclusion that it was essentially secured the way that I just described where I would be able to punish on origin, but not be able to stop the message on destination. And in fact, the the way the, that it works, they have essentially a, something analogs to kind of the optimistic watch towers optimistic kind of Watchers, where there is a, a network of users that are able to stop a message on a, at a kind of financial incentivized to one, be online and two stop fraudulent messages before they actually are executable and kind of in doing so they would then also kind of participate in punishing the, the actor that sent the fraudulent message. So by having this additional layer of kind of Watchers, I think they actually earn a position where they're much more suitable for this use case. I, you didn't come to this conclusion until last Friday. And so I actually haven't chatted with Nathan about this yet. So Nathan's learning this at least like, he's learning about my current understanding at the same time as you. So yeah, this is super fresh. Yeah, yeah, yeah, exactly. But yeah, no matter, I think it's really interesting and I, I would definitely like to look at and implementation of our bridge module that makes use of Nomad. I think that's probably a shorter path to essentially anywhere to anywhere any EVM chain to any EVM chain - bridging still doesn't have ideal trust assumptions, but it's definitely better than where we are currently. And we should be able to kind of roll it out to enable any to any bridging much sooner than the, the system that Nathan's describing, which is still very much in its infancy.

Anna Rose (00:37:47):
Very cool.

Nathan Ginnever (00:37:48):
Yes. Yeah. So we are, you know, at the stage of, you know, the AMB from no chain that, that does work and I do have prototypes of, of that working and a nice full fledged DAO ecosystem. So, but yeah, moving over to these more, you know, trust less systems is the way to go and I will need to check out Nomad, or you just hid that one from me.

Anna Rose (00:38:13):
All right. Let's move on to another module delay there's delay in exit. So we've done reality bridge delay and, and now we're on delay and exit. So what's Delay?

Nathan Ginnever (00:38:25):
Yeah, Delay's a very simple one. It's a common pattern in voting systems to put a delay mechanism between finalizing the vote and actually executing it. And it's a bit of a safety measure to kind of, you know, check the results and give yourself some time in case something went wrong. So Delay sits between some system, you know, potentially a, a voting system and the Gnosis Safe and will gather up the transactions just put a delay on them and let it sit there for a little bit.

Anna Rose (00:38:59):
And why do you do that? Why do you need it?

Nathan Ginnever (00:39:01):
It's it's a bit of a safety mechanism, so you can kind of couple it potentially with other modifiers or other modules, and you could, this could lead into a module that we're building well it's, and modifier, we might wanna clarify the difference between modifiers and modules at some point. But it could lead into this other modifier that we built that has roles, and you might leave a specific role that can do a specific action. And potentially that action would be to say, remove a bad module that decided to go do something corrupt. And while the transactions were being delayed, you would have a, a chance to do that.

Anna Rose (00:39:39):
That's, I mean, I'm kind of wondering like what bad action could happen, that you would even need this?

Auryn Macmillan (00:39:44):
Like, let let's say you have a, a governance system and it gets clearly kind of co-opted in some way, and starts trying to push through malicious proposals, you know, drain the treasury and send it to X a that kind of malicious proposal. It's, it's beneficial. If you have some mechanism to stop it or it can be beneficial if you have some mechanism to stop it. And so that's what this delay me delay modifier is essentially designed for it. It gives you a window of time to respond to to these kind of things, and then has a function where you, you can actually mark delayed transactions as invalid and so stop them. And so there is a, an owner on the modifier and that owner has the ability to call a function to essentially skip a transaction that's in queue. And so if, depending on what you set as that owner, that could be anything, it could be your multisig, it could be some other kind of trusted user. It could be a a governance mechanism. It could be a decentralized court whatever you like. You can kind of set us the owner of this module, and then that owner has the ability to skip transactions for you if, if they come through on their, their malicious or, you know, don't align with what the DAO kind of agrees to do or whatever it is. So yeah, it's really there just as kind of a safety precaution to enable that. The other thing that it can enable you to do is maybe this is a good segue into the exit module. So let me, let me kinda explain the exit module first, and then we'll tie it back to this.

Auryn Macmillan (00:41:20):
The exit module essentially allows you to claim a share of the DAOs treasury in exchange for some designated token. So essentially, unless you replicate a rage quit like functionality where you have some, some designated token and you can yeah. Redeem that for a proportional share of the DAO treasury of proportional, share of the DAO, other ERC 20 and native token assets. And so a really key piece of rage quit a really key piece functioning as intended. Is there being a period of time after a proposal passes to when it can be executed.

Anna Rose (00:42:01):
During which you can rage quit.

Auryn Macmillan (00:42:03):
Exactly. Yeah. So without that delay, your rage quit is pretty meaningless. If a proposal gets passed that you disagreed with, and, you know, now it goes and spends all of the funds that you would rage quit away if only you had the time. and so that's, that's kind of another use case where this might be, might be applicable is just to make sure that there's always enough time for people to exit for people to rage quit before a decision is, is actually enacted.

Anna Rose (00:42:27):
The rage quit you're talking about, I mean, I think this was first popularized by Moloch DAO. Right? This was this idea that you could, like, I mean, it, it's what it sounds like, like you hate a decision so much that you're like, I quit and you leave the space, but you actually get to take with you. Yeah. You flip the table, the table, burn your bridges and leave.

Auryn Macmillan (00:42:53):
Okay, exactly. And so I think there's a, also a really good illustration of kind of what the Zodiac ecosystem or one kind of thing that it enables you kind of, you get all these small building blocks and you can kind of combine them together to create systems that, that kind of take on a variety of different shapes. And so you could, you could create a kind of Moloch structure by combining the safe with the exit module and the delay module, and then some other governance mechanism.

Anna Rose (00:43:22):
Interesting. And this is kind of different from how a lot of other DAOs were kind of building themselves in the past or building up their tools cuz often what they do is like fork, the Moloch contracts or fork and existing DAO, which had been kind of built from scratch. And here it sounds like, yeah, you you've basically made the components and maybe some choices that you can, like you can configure things in a way so you can get the same effect without having to fork the exact code.

Auryn Macmillan (00:43:48):
Yeah, exactly. And I think the other thing that we we kind of touched on briefly was not wanting to kind of unreasonably future decisions. And so we kind of just recognize that most DAOs start off as a small group of people and, and probably the best choice for most DAOs initially is, is just a multisig. But you don't wanna cover unreasonably restrict them to just being a multisig forever. And so part of what's already enables is, is really incremental steps along the kind of progressive decentralization pathway. And, and that can kind of branch in any direction that the, the DAO wants, but you can slowly add in pieces to give the community a say and give them more autonomy and add different pieces of security, start to restrict or remove the multisig owners and add in all kinds of different decision making mechanisms for different functions. And I guess that's the, probably the last piece that I really love about this as a framework is that it really allows you to match mechanism and decision type in a, in a much more granular way where you can, because you can have multiple mechanisms running in parallel and you can if you want, can very strictly scope those mechanisms then you can very much define which mechanisms should be used for which types of decisions and, and ultimately should be able to get much more efficient DAOs as a result.

Anna Rose (00:45:14):
Cool. I had one before we move on to the sort of, cuz there's this other component we've mentioned modules and like very briefly mentioned modifiers or something called avatars. I wanna also understand that dimension, but first with the delay, I mean, when you talk about a delay, I also have this, like, I feel like there's a bit of an echo of the DAO, the DAO hack, the DAO hack that had this 35 day delay that sort of saved well, it gave people a little bit of breathing time to be able to potentially, you know, head to a white hat attack on it. That by the way is an amazing story. If people are listening and have never heard of the full DAO story, I I'll try to dig up. There's a really old episode we did with Griff Green, where it was like a play by play of what went down there. It was very cool. But yeah, that delay, you know, it was this idea that there was a malicious attack, but because of the way the thing was built, there was this 35 day wait period before some action could be taken. And now that was actually the time that people had to like make decisions and like find out what the community wanted to do. Is that where that comes from? Was it always part of sort of DAO thinking?

Auryn Macmillan (00:46:22):
Yeah, I think like time locks of delays are, are just a pretty proven strategy for for securing things, you know, like that has roots well, and truly before the DAO ecosystem was ever a thing, you know, like a time lock in a bank, vault is a is a, is a proven way to, you know, make sure that one of the people you share this bank vault with doesn't go and run off with all the money. And so it's, it's, it's very much a yeah, and old strategy. But it's been, reincarnated multiple times in the DAO ecosystem, obviously with the DAO with Moloch like we just mentioned with OpenZeppelin and Compound governor with their time lock with colony and the delay between oh, colony of lazy consensus mechanism has a time lock built in, I don't recall if DAO stack had a time lock. I don't think so. And, and, you know, trusted, proven mechanism for, for adding Layer security.

Nathan Ginnever (00:47:21):
And I do wonder if it's a bit of an admission of our code is law kind of inability to get things completely. Right. So it does leave you with the some sort of escape hatches and potentially introduces some trust requirements. And, you know, a fork came out of the original DAO delay and, you know, potentially that's the most decentralized solution to, to be in, in this situation of needing a delay. So, it's maybe not the most, you know, perfect solution, but, you know, perfection is hard to get rights. And so we're incrementally pushing our way towards that.

Anna Rose (00:47:58):
Very cool. So let's talk about these other elements. So what we've just covered the reality bridge delay exit. These are modules, but you also have these things called modifiers, but like, let's even take a step back. There's something called avatars, there's these, this other sort of access. So let's kind of cover those. What's an avatar, let's start there maybe.

Nathan Ginnever (00:48:19):
An avatar is a, a cool name for something like Gnosis Safe. Okay. It's what would be representing the, the asset vault that holds onto the, the core pieces that you want to, to secure or passes the messages on as the kind of identity on the chain that you want to interact with the rest of the chain with. And it's an agnostic terminology. I think it's meant to allow any other type of system to plug itself in as an avatar, if it, you know, fulfills certain sets of requirements.

Anna Rose (00:48:50):
But it isn't the voters, it's not like individual voters have avatars the way we understand it on Twitter or something like this. It's more like the shared wallet. That core thing is the avatar.

Auryn Macmillan (00:49:02):
Yeah. So we think about the avatars, like the DAO, the representation of the DAO on chain, essentially the address, they can only address that you would say, this is the DAO on chain, that that is your kind of avatar. And so the Gnosis Safe is our prototype for an avatar. We're obviously pretty incentivized to use that, but we were very deliberate about wanting this to be a kind of open standard, wanting it to be opinionated as much as possible about what you plug it into and wanting to leave it open for other people to make a choice on what that avatar is. So we don't wanna force people to use the safe, we think it's the best choice, but we don't want the standard to be more opinionated that it needs to be about that about that choice. And we wanna leave it open to other people to come and implement alternate avatars. If there's some improvement that they think they can make over the safe.

Anna Rose (00:49:47):
I wonder like, are there other really popular multisig standards? Like there used to be Parity multisig, but I think that was wound down. What else was there, like, are there other multisig that are really

Auryn Macmillan (00:50:04):
That's a polite way to put it? It was the Parity multisig had a...

Anna Rose (00:50:07):
Well, it had two hacks and then it, then they stopped. They were like, let's not use this anymore.

Auryn Macmillan (00:50:15):
Right. But yeah, there are some others out there. I think Argen is another really good example of a contract wallet that could be used as an avatar. The interface is a little bit different, but it, it has some very similar kind of design philosophy. Ethereum had a contract wallet implementation that could probably be used in a similar way. Perhaps there's others. Nathan?

Nathan Ginnever (00:50:40):
I'm not familiar with any others. I think you would, you would know more. Yeah, I've always thought of Gnosis, as the canonical one, although I know that's not necessarily true.

Anna Rose (00:50:50):
I have a little sort of side question on this. Like obviously this is very, very Ethereum solidity, EVM focused, but like, what if is it possible that there'd be like a multisig on another, like blockchain altogether that could somehow tap into some of this? Or would it need to be, I'm assuming all the contracts are written in solidity, so it's not like something you could like easily port over to like, I don't know, a fully different system, but yeah. Have you thought at all about that? Like the avatar maybe coming from a different place?

Auryn Macmillan (00:51:20):
So, I've thought a lot about the avatar still being on an EVM chain, but messages being passed from other other chains. So the, the near rainbow bridge is a really good example of a header relay that's pretty much trustless, pretty well trustless. And so I can imagine a, a scenario where you have some kind of DAO structure on Near that's bridging decisions over to a Gnosis Safe mainnet Ethereum or on one of the other kinda EVM chains that kind of scenario think could, could be possible from just about any network. And it's really just a matter of having a, a suitable data bridge the other way, having like a, an avatar on another network would obviously mean rewriting all of the the avatar code and than all of the modules. Yeah. Yeah. Okay. Yeah. So that's, that's a much more difficult kind direction for information to flow, but if you're talking about kind of control flowing from yeah, from Near or from I don't know, Solana or from yeah. Any of these other kind of smart contract platforms that are written in some other language as long as they have some suitable data bridge, then it would certainly be possible.

Anna Rose (00:52:32):
Interesting. okay. So now let's talk about the modifiers. So I think we've covered modules quite well, but yeah. What are, what's this modifier? And, and I don't know, are, are they already like listed? Are there too many of them? Like, what, what do they look like?

Nathan Ginnever (00:52:46):
We have less modifiers than modules at the moments, and it's just another one of those building blocks. So the way that I see modifiers is a, a piece of code that sits between a module and the avatar. So you can kind of, you know, deploy your module, deploy your avatar, and then say, I want to do an extra step or two between, you know, what's happening in the module and what's happening at the avatar level. You could hook in a modifier and, you know, re reroute the, the message passing between these components and have some extra logic happen, in that intermediate step. Maybe we can talk a little bit about a modifier that we are building right now, and we're calling it the rolls modifier, and the idea behind that is to take some execution and then, you know, check that execution before it reaches the avatar and determine some permission levels on that execution. And this is I think, particularly useful. It goes again into a bit of the safety side of DAO tooling. But what it can do is enable, you know, certain bypasses to governance where you know, this, you know, became a, a problem in practice for, I believe it was Compound DAO that made a mistake in one of their protocol upgrades and left some money on the table. And the only way to fix that was to go through the slow governance that initially caused the problem to begin with. So there was no fast way to like correct this mistake that the original proposal had created. So you could conceive of having a specialized role for a committee or some other form that little bit quicker to enact that could, you know, quickly route a message to correct that protocol upgrade. And that's kind of a, you know, the idea behind the roles is to, to give some extra permissions to, to bypass or to do certain things.

Anna Rose (00:54:40):
Cool. And that sounds like it could be incredibly useful, especially for younger protocols where there's, there'll needs to be a little bit of oversight from potentially the, the team before they fully decentralize.

Auryn Macmillan (00:54:52):
So for kinda a, a concrete example of this or more concrete example we were talking earlier about the delay modifier being a kind of security feature in that by allowing a time delay, you allow potential for someone to react to it and kind of who that someone is we talked before about being kind of quite nebulous. It could be any one of a number of different things. So let's think about this in the context of the roles modifier, you might define a role that is essentially like someone who is allowed to call the veto function on this delay modifier, or the skip function on this delay modifier. So now you have a role that is allowed to call that function, and you can assign that to whoever you want. So you may have a group of relatively trusted people in the community that you say, Hey, it's your job. If something goes through that, we need to stop. We have this upgrade to our protocol and oh, no, it means, you know, we just realized after it's gone through and it's sitting in the time delay that it means you're gonna leave a whole bunch of money sitting there that anyone can take someone, please go and veto it. And so you have now this group of people that have this one unilateral power, they can veto any proposal that goes through and they don't need to wait for do approval or anything like that. They can just go and call the veto function and and stop it. So you kind of avoid that scenario by granting some limited power, some limited kind of unilateral power to some small group of people. Yeah. Kind of a concrete way of thinking about the delay modifier and the roles modifier maybe acting in tandem.

Anna Rose (00:56:25):
Nice. And there's one other point, which is guards, what are guards?

Auryn Macmillan (00:56:30):
Yeah. Yeah. Those are the, the kind of, I guess, four kind of key components, avatars modules, modifiers, and guards and guards are a a type of contract that lets you do, you know, pre and post checks on execution. So you can install a guard on the safe or on a Zodiac compliant module or modifier. And basically what it's gonna do is before it tries to execute the code and then after it tries to execute the code or, or pass the code through, it's going to run this kind of pre-check on it. And then a post check on it. And so the guard basically defines what that pre-check or post check is. And so it might be things like our scope guard that is, is very similar to the roles modifier that we've just talked about, where you can kind of set up some specific addresses and functions that a particular module or modifier is allowed to interact with, or the say the multisig signers are allowed to interact with. Or you could do things like a post check that makes sure that some state hasn't changed. So say you wanna make sure that a multisig sign, a particular multisig sign is not removed or a particular module is not removed. You know, you wanna make sure that no one puts the real proposal that removes the reality module as a module and breaks the down. Then you can have a scope guard that does that or you say you have a guard that does that, that checks to make sure that that piece of state hasn't changed. And if it has then the whole transaction reverts. Got it. Maybe it's good to do a quick recap on just like what each of those pieces are. So the avatar is kind of the address on chain that represent the DAO. A module is something that would plug into an avatar to, to control it. A module has unilateral control over the avatar. And so you can of implement whatever logic you want, the the module to be able to do in that module contract a modifier would sit between a module and an avatar and you can kind of arbitrarily chain those as deep as you want. So you may have multiple modifiers sitting between a module and an avatar and then a scope is applied to either the avatar directly or any of the modifiers or modules in between to do pre-checks and post checks on execution.

Anna Rose (00:58:42):
And like, just to double check that too. So in terms of modules there's reality bridge and exit is exit a module?

Auryn Macmillan (00:58:49):
Yes, exit is a module.

Anna Rose (00:58:50):
Okay. And then modifiers would be the roles and the delay.

Auryn Macmillan (00:58:55):
Yeah. And the other way to distinguish modifiers is that they implement both the the module and the avatar interface. So they're basically, you can, you can plug in and, and they've got kind of both, both plugs, whereas the the modifier kind of can only send messages out essentially.

Anna Rose (00:59:14):
Okay. Very cool. This is actually really interesting because I mean, we, I, I've been thinking about potentially playing with a DAO idea in the near future. I don't have any, I have too many projects, so I really don't wanna promise anything here, but I've, I've really appreciated going through the steps and the each module and trying to understand how they'd all work together. And also I'd like this idea that you just described, which you start with a multisig, you start with something relatively easy. It's pretty easy to set up. People are kind of familiar with using it. And then you could potentially add to it. I have a question a little bit about the types of DAOs that this is for, I mean, I know it's, since it's modular, it's potentially for a very, very wide range, but like, I feel like there've been, and I don't know if maybe someone has defined this more accurately than I'm about to, but I feel like there's these clusters of types of DAOs kind of coming up.There's the DeFi DAOs, the DeFi DAOs when I say this, it's like, you know, the Compound DAO, I don't know if Aave has a DAO, but I'm guessing like all the Dows that basically decide on the percentage of rewards that are gonna be coming out. What's the fee, like these, these sort of numeric decisions happening in DeFi there's the NFT DAOs, which I fully don't understand at this point. To be honest, I don't know what I know that they have funds and that they have to do something with the funds, which I think is like market themselves more or something or buy albums. And then there's things like the investment DAOs grants or, or like actual investments in there you can have like Moloch DAO meta cartel. There's like a bunch and those are actually a little bit older. So yeah. I mean, this is, this is sort of a, a distinction I'm seeing. Maybe you have a different way of thinking about the landscape and yeah. I'm curious to hear how you think about it and maybe where you think these tools are most effective.

Auryn Macmillan (01:01:09):
Yeah. I mean, I think I think those categories are pretty useful. And, and probably describe a good chunk of the DAOs and the space. There's there's yeah. Defi kind of governance DAOs for governing both the kind of treasuries of, and, and generally, and in some cases kind of parameters of various DeFi ecosystems the, these kind of more cultural or NFT focus DAOs have become much more popular. And think Nathan probably has more insight on that side of the ecosystem than I do. And then broadly these kind of fund allocation DAOs you, you identified those as potentially being a little bit older and I think that's, that's probably true. The, the Moloch ecosystem really catalyze that I think there's probably a, a fourth category there of kind of mission driven DAOs that have some kind of specific purpose that they're trying to achieve. They want to go and change the world somehow. And, and they kind of, you know, they're, they're trying to kind of direct funds towards doing that. And then I think there's, there's a very different style of DAO. I mean, generally I would say, like you've got two really broad classes of DAO. One is kind of very narrowly scoped DAOs like the Bitcoin network or the Ethereum network where you have your participation is running a node. And you know, the scope of work that you have is literal really kind of running that node or running that consensus algorithm, participating in consensus to, to kind of secure the network. And then the other kind of broad class of DAO is, is much less tightly scoped where it could be, you know, they they're trying to do something that may or may not kind of interact with the real world in some way, but it's it's much less tightly scoped in terms of how they, how they actually interact and, and what they do. And then yet in that second kind of broader class, then yeah, it branches down a whole bunch, but I think your categories make broad sense.

Anna Rose (01:03:07):
There might even be one that I, I feel like is missing here, which is like the DAOs that are there to make decisions about protocol upgrades. I don't know if you would consider the Zodiac as a framework for something like that. And maybe that's not a DAO that does that, but it's mostly maybe like, in some, like, I'd say like Cosmos and Polkadot you have actually on chain governance, which makes decisions on, and, and maybe some others, I bet I bet some others that I'm missing, but they make decisions on actually what upgrades are gonna happen.

Auryn Macmillan (01:03:37):
Yeah. I, I would lump them in as the same in the same category is that, that second kind of big bucket is just like, that's, that's a DAO that's much less tightly scoped than one that you participate in just for consensus.

Nathan Ginnever (01:03:49):
Yeah. I think that the first mention of DAOs that I could pull up was I think 2014 Vitalik was writing the difference between DAs are just decentralized applications and DOs, decentralized organizations and DACs with, you know, company at the end. And I think the real kind of difference between, you know, a Bitcoin DAO and an NFT DAO is the, the autonomy part where, you know, Vitalik was defining the autonomy being how much of this DAO is self running and how much of it is, you know, just code based and running completely on its own. But even Bitcoin requires, you know, some human intervention there's been forks in Bitcoin where clients got out of dates and had to be corrected by humans to make sure that these, you know, forks it and run and, you know, often parallel directions and just go mad. So think, you know, the autonomy part is probably the most vague part of the, the DAO acronym. And there's always gonna be, you know, less autonomy, you know, depending on certain, certain types of DAOs and yeah.

Auryn Macmillan (01:04:53):
Yeah, I guess maybe so to go back to your original question then about like where we would see Zodiac being useful, probably I would say any with the exception of that first kind of really broad category of essentially like narrow scoped kind of protocol DAOs, you know, they get so Zodiac's, probably not useful to participate in the consensus you know, to, as to participate in mining or proof of stake or something like that. But it's a anywhere else. It probably is. It could probably be used for it's, it's definitely built to be as flexible and generally applicable as possible.

Nathan Ginnever (01:05:36):
I agree. I like the idea of this facilitating, you know, and to use the autonomy part, maybe the less autonomous ones, the ones that require a little bit more human intervention which is I think the general broader landscape of what we see as DAOs currently. So I, I do think that it's useful for are most DAOs and I've been building in that direction to, to try and make, you know, these tools as useful as possible to most DAOs. And I think a way to do that is to try to incorporate as many strategies as you can and by strategies, I mean, ways of, of voting ways of, of coming together, we have kind of a, a narrow scope of ways of voting and this has presented some issues and there's been posts about, you know, the pitfalls of, of coin voting and just relying entirely on you know, plutocratic methods to, to get decisions across. And, and so it's been the majority of my work has been spent on making sure that there's other forms, you know, simple things, you know, reintroducing classic politics, reintroducing, reintroducing, legacy politics into DAOs things like one member, one vote, and maybe things that are a little bit more interesting, like quadratic voting, which was actually tried in Congress, I believe in Colorado at some point in, in 2018 or so. And the idea there is to, yeah, to kind of put a little bit of stake in what you're voting on to to avoid the potential problems of just one number one vote and majorities, outweighing minorities, and to be able to get a little bit more voice across, but still not run into the issues of full on Plutocracy, where money just is the, the ruling class.

Anna Rose (01:07:23):
That actually leads me to my last kind of question I had, which was to revisit that concept of voting. Because when we went through all of the components of Zodiac, there isn't really a part that says what kind of votes or what the voting systems are. And I wonder, like, you know, if you look at even like reality and the staking game, the Oracle escalation game, that's not really a voting system as far as I can tell. So, so yeah, I'm curious to hear, like, where does the votes, like, I, I get the idea that they might be happening on the L2, but yeah. How, like, how are the voting systems defined, like say you wanted to do MACI say you wanted to use quadratic voting. Do you build that with Zodiac or do you build that separately and then use Zodiac to kind of like get the results somewhere?

Nathan Ginnever (01:08:09):
So I created a module to fit into the Zodiac framework. That is what I'm calling Usul, which is a term from from Dune, which is a name of the, a main characters, like secret name or something. But it's the idea is it is just a voting system, right? So it, it kind of fills that question that you're having, where, where does the voting come from in this and it's its core. The module is just a place to load up your proposals to, to get the data that you want executed into a centralized place. And then from there, you're able to register different strategies to come to decisions on whether or not that data should pass. And so these strategies can be any type of voting. And I started with the example, that's the most common, which would be delegated coin voting, which you'd see out of Compound, but we've also built one member, one vote to try things that, you know, systems like cooperatives would be more interested in. We are working with more, more exotic voting strategies like MACI, and, you know, you'd be able to create the MACI voting system and then just plug that into this module. And you can always, again, keeping with the design philosophy of Zodiac, swap these things out and even granularly on a proposal level, you know, as you're submitting proposals to the, to the Usul module, you can say, I prefer this voting strategy or this other voting strategy for the, this specific proposal.

Anna Rose (01:09:38):
I wonder like, since like MACI has been implemented, I believe there's like an implementation for the CLR fund and quadratic voting has definitely been implemented for gitcoin. Can you reuse any of that or would you have to rebuild it somehow to fit within Zodiac?

Auryn Macmillan (01:09:54):
Yeah, the plan's definitely to reuse MACI. We we'd really like to leverage MACI. I think like the fact that all the DAO voting right now is out in the open in public can easily readable easily tie-able to your identity leads to the possibility for some really negative outcomes. And so the ability, ability to kind of leverage tools like, like MACI to make much more kind of collusion resistant voting is crucial for the DAO system DAO ecosystem to kind of evolve and, and take a next step. I think taking a, a step back, you kind asking where the voting happens. This is a really, again, kind of deliberate choice in designing Zodiac. Just kind of recognizing that there was already a whole bunch of really great voting and decision making tools out there. And so we didn't really need to reinvent the wheel. The idea here is more about plugging those things into one cohesive kind of core, using them as a essentially a module to this, this larger framework, as opposed to trying to displace them. So it's up, you know, the, the existing tools that, that are already out there and in Aragon and DAO stack and Colony and Compound, and Moloch really great. And we, we shouldn't just throw them out and stop using them. Zodiac is, is really there to just make those all kind of composable pieces to one larger tool set. And then, yeah, Nathan's, tool also, he he's gonna work on that as what originally connected us. That's, that's how we found Nathan. And yeah, the, the fact that he kind of arrived at that conclusion independently and then started building was, you know, he was just a natural fit. And then yeah, MACI a project or kind MACI integration into all as a project that Nathan and I had started in our last build cycle and it got derailed by some other priorities. But we're very much hoping to get back into in, in a future cycle. You, you mentioned clear fund that's a a side project that I work on. Cool. yeah, I it's, so I had a lot of experience kind playing with MACI and we we're currently navigating the challenges of trying to do it on a true layer 2 it's turning out to be a lot more expensive than than we had predicted for we, we were hoping to run around on Arbitrum and just kinda benchmarking based on our previous round that we ran on xDai and Gnosis chain. We, we had 6,000 almost 7,000 participants who averaged about 10 messages each. So somewhere around 70,000 messages. And this basically means we have to do, we have to do 7,000 transactions to Arbitrum if we wanted to run that same size round. Okay. which would end up being a, a really significant amount of money given that, you know, a transaction to Arbitrum right now is a dollar or two, maybe three. Yeah. And so, yeah, we're, we're trying to kind of reconcile the want to run rounds on a network that is the kind of shares Ethereum mainnet security model with just the, the reality of the cost of doing it. And kinda what scale we need to achieve in order to make that cost worthwhile wild.

Anna Rose (01:13:28):
Yeah. Actually I wanted to create a grant over there. That was, that was where I think Wei Jie came on the show and shared MACI and mentioned that thing. And I was like, oh man, I wanna go over there and try it. I haven't done it yet. Still just on gitcoin for now, but maybe one day...

Auryn Macmillan (01:13:43):
When we when we fire up the next round, you absolutely should. Cool. But yeah, this is this is all kind of relevant for us thinking about how we would utilize it in Zodiac as well, because part of the point of Zodiac obviously part of the, the inspiration for it was lowering the barrier to entry. And so I wanna be really lowering the barrier to kind of participation. And so I wanna be really con cognizant of building systems that have a, have a reasonable home if they are gonna be kind of gas intensive, you know, have a reasonable home that DAOs can deploy them and operate them without reintroducing that that financial kind of roadblock to a whole bunch of people potentially participating. So I think Gnosis chain for the time being is still probably the preferable place to run something like this other networks that might be similarly cost effective might be Polygon or, or, you know, other other, essentially side chains. I'm really keen to see ZK EVM start to come online because I think that'll probably try transaction prices on L2 considerably. But I know that they still we're still have a little bit of time to wait on those.

Anna Rose (01:15:00):
Very cool. So maybe as a last question tell us a little bit about what the future for Zodiac holds. What are you working on right now? What can we expect to see in the pipeline?

Nathan Ginnever (01:15:09):
So I would like this stuff to be useful and usable as soon as possible. And to get that done, I will have a Testnet version of being able to vote with different strategies, hooked into the Zodiac ecosystem ready by the time this airs. So it's already on Testnet you can out a large majority of the functionality, but by the time this airs, it should be the coin voting that you're all familiar with. And one member, one vote, which I think is really important to get equality into voting systems. And as already mentioned, we want to make sure that voting feels inclusive. And that's, I think a missing piece of a lot of on chain governance is this feeling that you must delegate, or, you know, that you have to sit on the sidelines and not be able to, to vote, or that there's some, a information asymmetry that you don't even feel qualified to vote. I want to try and break down all those barriers. So there's a, a testnet that you'll be able to sekerDAO.com. That's S E K E R DAO. And that will be using the Zodiac ecosystem to allow you to boot up different voting types and, and try out different strategies. And we're also going to have the layer two, to the Gnosis chain bridge ready by then.

Auryn Macmillan (01:16:29):
The other thing that I think we'll start to see, and I'd like to see is, is just more of the existing DAO tooling, starting to explicitly enable kind of Zodiac features in their own framework. So enabling organizations to essentially spin up an avatar, spin up a safe, or to bring an existing safe over to their DAO and, and enable that progressive decentralization pathways to kind of relatively seamlessly flow into and through kind of those ecosystems the DAO Haus guys have been kind of blazing that trail a little bit. And I think we'll start to see some of the other frameworks following suit.

Anna Rose (01:17:10):
Very cool. I wanna say thank you so much for coming on the show and kind of exploring the Zodiac landscape, all of the modules, how these pieces work together and also kind of how these different voting systems are, you know, enabling a lot of new ways for communities to interact.

Anna Rose (01:17:26):
Yeah. So thanks to both of you.

Auryn Macmillan (01:17:28):
Sure, thanks for having us. This was a lot of fun.

Nathan Ginnever (01:17:29):
Thank you very much. This is awesome.

Anna Rose (01:17:33):
I wanna say a big thank you to the podcast editor, Henrik, the podcast producer, Tanya, and to our listeners. Thanks for listening.