Zodiac: Modular principles for DAOs and avatar-based accounts

Transcript

hello everyone i'm peter and this is the ethereum engineering group meetup and today we've got oren from gnosis to give a talk so oren please introduce yourself hypnosis on a team called nurses guild um we built a whole bunch of i guess notices kind of more generally just builds uh all kinds of infrastructure for the ethereum ecosystem and then my team nurses guild we work on uh kind of dao specific infrastructure so mostly uh kind of needs driven development for the gnosis dell but we tend to uh build in such a way that kind of everything we build is kind of

generalizable and should be usable by by other projects uh and and nurses guild is is very much uh you know in the habit of and kind of advocating for a modular way of building uh all kinds of dow tools which is what we'll talk about today sounds awesome so please go ahead and share your slides and um so just so everyone knows oren said before that he's happy for us to hammer home questions at any and every moment yeah yeah feel free to interrupt me anytime i'm reasonably good at task flip string so we can we can dive into answering questions i can jump back into the presentation uh the the talk will probably go for 15 or so minutes uh and

then after that we can go into kind of heavier q a if folks have questions and if not then i'll probably just jump in and do a bit of an ad hoc demo of actually using uh some of the principles that we talked about uh and and using kind of the zodiac standard to build a module to control the dao with some very trivial functionality since it's uh we'd be building it live as we go uh but yeah we'll we'll go ahead and jump in and get to it um so all right so today i want to talk about this funny little concept called pipes pipeline programming is an approach

where one breaks a problem into a number of small steps each of which can then be performed by a simple program this type of componentization is sometimes called pipe think in which wherever possible a programmer relies on a pre-existing collection of useful stages so this methodology relies heavily on the reuse of a set of components rather than building monolithic applications so in unix-like environments pipes are represented by a vertical bar which lets you pipe the output of one command into the input of another and because each

process takes text as out input and provides text as output they can be chained together in arbitrarily complex combinations to create uh useful or fun in this example uh systems so this is just a silly kind of trivial example here where i'm kind of piping echo into another command to make a little cow say moo and then to make my cow colorful so fun systems here but in practice it's much more useful so similarly modern programming makes use of a ton of standardized protocols and interfaces to allow programmers to feed

one another's inputs and consume one another's outputs however these interfaces often become centralizing forces someone ultimately owns and controls the underlying data along with access to it and the bill for maintaining those resources and anything built on top of that access or data takes on some existential risk creating strong incentives for large monolithic ecosystems to be built around the choke points for control and access to that data so social networks like twitter instagram facebook et cetera are kind of canonical examples of this uh gargantuan walled gardens with

incredible inflows of data ready to be consumed by humans and machines but ultimately controlled by one entity these kind of represent an existential risk for anything built on top of them so for example if at any point twitter decides to change or restrict its api then the lovely command line interface for twitter that i have on screen here could immediately break and so unlike the pipes you might use on your local machine to make colorful ascii mooing cows and other more useful things the pipes to twitter are permissioned the justification for this essentially

boils down to the fact that someone has to own operate and pay for the infrastructure that it runs on and of course because controlling access to this data can be wildly profitable but for a growing number of use cases the relatively recent innovation of permissionless shared execution environments like the ethereum virtual machine provides an avenue to eliminating much of that existential risk that avenue is open access to data and communication sorry data and computation so because of the relatively strong guarantees around access and control the evm allows for permissionless pipe think

and as a result there's this emerging ecosystem of reusable components allowing for ever more complex and novel novel combinatorial systems rather than one of the best examples of this is the proliferation of the erc20 standard it's a standard interface for tokens in the ethereum virtual machine so by writing contracts that conform to the erc20 standard that take erc20 tokens as inputs that expose erc20 token uh interface so as their kind of output or that do both users are able to string together arbitrarily complex combinations of

systems to create useful or fun token derivatives a common and relatively simple example would be depositing eth into a maker volt which returns dye any rc20 token or depositing eth into a maker vault which returns dire depositing that die into a three curve pull returning that three curve token depositing that three curve token into a urine volt which gives you the y3 curve token and so the deeper into the kind of d5 ecosystem you go the more complex and convoluted these paths of chain systems become each system taking an erc20 token as an input and returning its own erc20 token uh representing the position in that

system as its output by breaking away from uh mono think the the inverse of pipe thing or the tendency towards monolithic systems is really hard it means thinking smaller and accepting that you what you're building will likely be used as just one part of a much larger whole it often means relinquishing some measure of control over the user experience it means embracing composability and it requires leaning into the fact that your things will be used in weird wonderful and entirely unexpected ways so in 2013 the thing that got me really

excited about crypto currencies uh and about the idea of ethereum in particular the thing that turned it from kind of an idle curiosity into an infatuation to something that i wanted to invest my money my time my effort into uh and the thing that has most radically kind of shaped the last decade of my life uh was the idea of dao's decentralized autonomous organizations so to me dao's have been this kind of beacon of hope illuminating a path toward a future where humans from any corner of the globe could freely choose to come together to collectively build the change they want to see in the world or like collect jpegs and all that kind of

stuff so without the need for anyone else's blessing or approval they can essentially rally around an idea and uh execute on it so to me dow's a foundational infrastructure for web3 for a web without walls but due in large part to how early they all were in ethereum's life cycle the lack of mature tooling and the lack of mature use cases when they started design and implementation all of the well-established evm-based dao frameworks uh to some extent fall victim to this mono think uh idea these frameworks from the dell to aragon

colony dastak governor moloch are all designed as monolithic systems built around their own core contracts to be fed they each implement their own version of modularity within their own walled gardens they have apps or extensions or modules or plugins which is still a vast improvement over the kind of permissioned access that's typical for more uh traditional web applications and apis but there's a little to no concept of composability between these various aside from what's baked into ethereum by default so each one of these systems was built as the center of its own universe with each app extension module a plugin

being built kind of bespoke for that ecosystem which essentially further raises the walls around its uh its garden in in web 2 some people might celebrate this and call it a moat in web 3 this is kind of an anti-pattern we can and we should do better so what does better look like we should be building our dow tooling with standard inputs and outputs so that users can compose them in whatever weird and wonderful combinations they like this doesn't mean tearing everything down and starting again from scratch but it does require a bit of a reorientation of what we consider the center of adele

so the key insight here is decoupling account from control mechanism decoupling the thing that represents your dell on chain it's avatar if you will um and the thing that that's the thing that kind of holds tokens control systems and is referenced by other decoupling that from the logic that makes it do things the logic that controls it so with this simple reorientation uh treating new and existing tools as pieces to be plugged into a much grander design we open up the possibility for permissionless pipe think in the context of dells and in doing so we open up the possibility for more flexible and resilient organizations that are much

more capable of adapting to changing environments so to this end we gnosis guild created zodiac an open standard for composable dow tooling along with a collection of tools that we've built to that standard zodiac enables dows to take full control of their composition to mix match stack new and existing tools and frameworks to find a combination that best suits their needs and to do so in a way that doesn't inhibit their future growth and evolution zodiac treats a programmable account like the gnosis safe as an avatar for the dow and then anything that can make

calls to the exact transaction from module function on that avatar can be enabled as a module modules would typically be contracts that implement some logic to extend the functionality of the dao's avatar adding voting mechanisms getting specific permissions to some users allowing members to exit or rage quit with their share of the daos assets and much much more and then modifiers contracts that would sit between an avatar and its modules to well modify their behavior this could be things like enforcing a time lock on proposals enforcing access control for specific addresses to be allowed to call

specific functions and so with these three primitives avatars modules and modifiers we're now able to use this concept of formationless pipe thing to build composable dow tooling and much more flexible and robust dowels so i've used a bunch of my time here today to talk about why uh how my composability is valuable in the context of d5 and dowels but this extends well beyond just d5 and dells i think for web3 to truly express itself pipes must be pervasive throughout the with everything we build in web3 we should be conscious of the design

decisions we make that might enable pipe think uh or conversely encourage walled gardens individually we might need to think a little bit smaller so that we can collectively think uh bigger allowing more complex systems to emerge organically but this is not prescriptions so much as it is a warning a warning to all of those who would seek to build and defend emote on our shared virtual machine to build systems incapable of composition to those people i would say this is a pattern of the past it's an anti-pattern in web 3 and it's a pattern enabled by permissioned access to in control of data

it's a pattern which has been made redundant to a certain extent uh in our version of the internet uh made redundant by our shared virtual machine and i think the future will be dominated by much more emergent systems organic compositions of many discrete and disparate components in combinations never dreamt of by their creators so rather than seeking to build wild gardens i'd say join us by adding to and building on this infinite garden join us by building uh and more importantly by using the pipes in this web without walls thanks that's a the the i guess end of the talk happy to jump into a

q a now if uh if anyone has any questions uh and i guess just chill if uh if you do want to connect after the talk then uh you can find me on twitter at ironmacmillan or you can buy notice guild nursesguild but yeah here now we can uh we can cut away and if once once we're done with questions if no one has any questions then we can dive into a quick tutorial on actually doing uh building a module for a nurse's safe that does something silly um so yeah i'll pause that for a second and just open up two questions yeah and like so thank you as a starting point um

and are there questions okay i've got one so is this so i assume it's i mean it feels like we're talking about interfaces but probably something more than just defining some interfaces is that a is that that's correct isn't it yeah i mean interfaces are one part of i think having having standard interfaces uh that you can use as a shelling point is pretty integral to composability

actually working but i think more than or kind of in addition to that there's the the mindset of the people that are actually building tools so like it's it's defining interfaces is is only the kind of first step towards it the the the other kind of really critical component is getting uh momentum behind getting kind of uh people who are building and using tools to actually understand the benefit of this type of composability both for their own systems but then also for the ecosystem as a whole i think that's probably the the more critical

phase of this uh is getting this kind of uh philosophy to be pervasive throughout the ecosystem making it be the the standard that people kind of expect when they are interacting with a tool uh or kind of building a new tool okay okay um i know i'm i'm thinking having any as you said right at the start having an example will make this so much crystal clear does anyone have any questions before oren dives into doing an example that helps crystallize it for us no okay over to you then let's see this

example and then we're gonna walk away knowing i mean i yeah i i sort of i sort of think i understand but i'm don't quite i'm not quite there i think but i think having a worked example is going to help a lot yeah no worries so uh this is a a tutorial that's up on our um on our wiki which is yet to be published i think it's actually posted on uh our old let's see track that down later but it's on our old uh docks as well but we are about to launch this zodiac dot wiki this is just a staging server for it right now um and here's a

tutorial we'll go through this live um and and hopefully it all works as intended uh it should uh but the idea here is basically to build a um a module and kind of control another safe uh via some additional logic that we implement as a module hopefully this helps to kind of crystallize uh some of the context some of the kind of concepts here in terms of permissionless kind of modularity this permissionless pipe thing so in this case we're just going to use remix this is a web-based ethereum ide um really really useful tool and what we're essentially going to do is just build a contract that

has a uh we're going to build a our own custom module that just pushes a button essentially so we have this gist here button.sol literally defines one function where uh where you can call it push button and it's just going to increment this uh button pushes variable and emit this little button was pushed event so trivial super silly little contract the the kind of catch here is that it can only be pushed by whoever the owner so when we deploy it uh it'll be the owner will be set to

whoever deployed the contract and then we're going to transfer it over to our mock safe in this example this is just a contract that exposes some modified versions of some of the core functions for the nosa safe and kind of demonstrate how we can then extend the safes logic with our own custom module so that we can change the ways in which we can trigger the safe to actually execute things and so in the context of adele we're essentially uh building this module to extend the functionality of our core uh dao the avatar to our dao so i'm going to grab

this gist i'm going to open it up in remix and you'll see that it gives us our three contracts it's going to compile them automatically as we uh go through and so what i'm going to do is we'll start off just working in the local virtual machine here in remix it's taking a little longer to compile than it normally would which is surprising let's try again this might be uh the live demo gods frowning on this presentation i'm gonna hit refresh and see if i can

get it to work as intended it might be because i had uh i had turned off my vpn earlier it might have broken something with my connection uh remix or it might be the other way it just doesn't like my australian ip address no okay cool so it's compiled now great so we're going to deploy our button uh our local evm environment hit the deploy button we see down the bottom here that [Music] deploy transaction went through and we can see here we now have a button deployed if i hit owner it's going to query the

owner variable and return my address in this local virtual machine if i hit pushes we'll see that it's currently set to zero so this is our pushes variable here and then if i push the button because i'm currently the owner our transaction will confirm and now if i hit pushes again we'll see that it's incremented to one so we have this very simple contract here which is essentially just a button that the owner can push whenever they like to increment at two one push it again and increment it to two so the next thing that we're going to do uh we'll open our mock safe we will

go ahead and deploy this mock safe um over here in our virtual machine if i wanted to try to trigger the mock safe to push the button uh i'm gonna jump back over to the tutorial here and scroll down a little bit and grab the function selector for the push button function so i could attempt to make my safe push the button and what we'll see is

when i do this the transaction is going to fail and it's basically just going to fail because uh my mock safe here is not the owner of the button so it cannot push it so we're going to transfer ownership of the button over to our mock safe just to make sure i got the address right there looks good so we'll transfer ownership now if i try to push the button we'll see that the transaction fails because i'm not the owner i'm just gonna query pushes again just to validate has not incremented beyond two so now if i hit transact down here

this transaction should succeed and i should be able to see up here that push this has incremented to three now our safe is the mock safe is the owner of our button contract and it can it can push the button this exact function here i've modified significantly from the the normal notice safe this is normally the entry point that would use we would use to do um the the multisig so it has a whole bunch of additional fields uh one of which is a field that includes all of the

signatures from the signers so you obviously need to have a threshold of signers in order to execute something in this case literally anyone can come along and hit uh this exec function to make this this mock safe do whatever you want so don't ever try to use this mock safe and anything valuable at all it's uh it's totally unsuitable for for anything in production but great for demos like this what uh we're gonna do now though is build a module that's going to interact with this exact transaction from module function and so this one does actually have some uh protections on it so if i wanted to or some

validation on it so if i wanted to try to call the same function using the exact transaction from module endpoint here or entry point then when i hit transact this one should fail and it's going to say unacceptable address or unaccepted address because my address here is not enabled as a module on this mock safe what we're going to do here is build one thing we could do is just enable my address as a as a module on the mock safe and then i'd be able to use this entry point

in in production kind of enabling an eoa as a module on a uh on a safe would just give the safe give that eoa unilateral control over the safe it means that basically that that eoa now controls the safe it doesn't need uh permission from other signers or anything it can make the safe do anything at once so it's pretty dangerous to enable an eoa as a module what you want to do is create a contract that implements some specific logic uh around when why uh and then kind of how a the the module is able to trigger the safe to do things so in our case uh it's gonna be really simple and it's

not gonna uh it's basically just gonna allow anyone to come along and trigger the safe to press the button so remember our button originally uh only the owner can press it and this will still be the case only the owner will actually be able to press the but the module that we're going to build will allow anyone to trigger the safe to press the button so the safe is still the thing pressing the button but anyone can tell the safe to press the button uh essentially so we're implementing some additional control logic that basically opens access to this push button function so i'm going to go over to our

tutorial here and actually before we go any further what you'll see here about this contract kind of where it starts is that we are importing module.com if i open up the zodiac repo here you'll see that module.sol basically implements a whole bunch of uh functions uh and variables that are essentially the the the standard that we are trying to kind of coalesce around for um for how composability can work in the

context of of dells it is actually also implemented as an eip that's that's the ip5005 so zodiac avatar accounts if anyone wants to go and check this out uh this is the kind of more formal definition of the standard so we have the i avatar interface which basically exposes enable module disable module uh exec transaction from module the the endpoint that we're using today and then from uh

implementation here we have our implementation of the standard is kind of opinionated about some of the variables and things that should be included with a uh with a module uh and essentially what our module.soul does is uh expose this internal function here that your module can use to trigger the safe or the avatar to do things so you create some logic around when why and how your your module calls exec to trigger the safe to do things in our case we are going to grab

some code here from the tutorial uh i'll just copy and paste it so that i don't fumble around with it live on the call here but we can walk through kind of what this is so we have one uh one variable button which is our the address of our button contract um we'll set that when we deploy when we deploy the button let's close out some of these folders there we go so we'll set that when we deploy our button contract and then we have this push button function and what this is going to do is just call

the exec function the internal exact function from that we've imported from module.sol it's going to set the two addresses in the address that the the safe or call to button the value as in the amount of ether to send with it to zero it's going to encode the push button function as the uh the push button function selector as the data and then it's gonna select call uh as in the the type of call that it's gonna make your options here are call or uh delegate call um but in our case call is what we want um because we want uh

safe to be message.sender when it calls to the outside function uh on on the button contract uh when it comes to the push button function on the button contract as opposed to it essentially doing a delegate call which means um kind of treating it using the logic from the button contract but treating it as if it's an internal function to the uh the contract to the safe so yeah really really simple module here um but hopefully illustrates uh the the kind of concept here where we can very easily kind of

implement additional logic to change how our avatar our mock safe in this example is controlled now what we're going to do is jump over to our local virtual machine again we'll deploy and now we won't oh right right i almost forgot i didn't forget so our compiler is complaining at us right now because it's saying they should be marked as abstract because there's a handful of uh functions that are required that have not been implemented yet so i'm going to scroll down a little bit here and grab some more code

we have a constructor and a setup and these are again kind of opinionated parts about this that we uh we add to our implementation this is not something that's required by the standards but it is something that makes it easier for for other users to go and deploy and it's essentially the pieces of this that make your factory friendly so if we go back to contracts here and jump into the factory folder we have this factory friendly.sol which is imported by it's imported by our

module.sol um and basically it just has this requirement to implement the setup function which initializes your uh contract so you see here that the way that we've implemented it we've got a constructor which is the function that's called when you first deploy a contract and all it's going to do is take the parameters api encode them and then pass them to a setup function then the setup function is going to decode those parameters and then use them to set a handful of variables uh we've been really lazy here and just set the avatar the target all to owner and then transferred

ownership to our owner variable as well uh in production you want to be able to define those things separately because there are a handful of cases where they are not the same thing and just to kind of disambiguate them avatar is the address that will ultimately execute the transaction so this is the mock safe in our example target is the next address in a chain of modules and modifiers that should ultimately lead to your avatar if you have uh so an example of this would be if you have a delay modifier which is a modifier that essentially enforces a time delay between when a module passes in a transaction to be

executed and when it can actually be sent to the avatar to be executed then from the point of view of the module has this time delay being enforced that the target is the delay modifier and then the avatar is the safe so it's important that those two things be able to be disambiguated uh or can be set to separate variables and then is the uh address that can control kind of permission functions usually to set different variables um and so uh it's again kind of important that be able to be

disambiguated from the avatar and the target because there's scenarios where you might want to have the owner be different from those things you might want to set the owner to the address zero so that you lock the state of the module or you might want to have some checks and balances between different components of your dell and so having the owner be something different from the avatar means that some other mechanism may be able to kind of be a kind of check on the power of the uh the avatar so again disambiguating those things in production is really important in the context of this it's not so uh we just are lazy and set them all to

the same thing now that we've put in our setup function and our constructor the compiler stopped complaining at us uh i guess the last thing here to quickly go through the kind of why of the setup function it's implemented as part of this factory-friendly uh contract and basically what this does is make it friendly for this module proxy factory and this module proxy factory essentially allows us to deploy a very very minimal proxy that is not upgradable you can use as an alternate to deploying the entire contract so

someone can deploy a master copy and then any number of people can deploy can deploy proxies that use the code from that master copy so it basically just radically reduces the deploy cost um with the trade-off of a slightly higher cost each time you call the in this case the the contract that actually gets deployed the proxy contract is tiny i believe that this is the smallest and most efficient proxy contract available it's based on another erp that i can't

remember the number of off the top of my head but this minimal proxy contract people might save me here uh 11 57 so it's based off of this uh 1167 uh minimal proxy contract although i believe ours is slightly more efficient because we changed one op code uh i can't remember exactly what it was now but um yeah ever so slightly more efficient than uh the minimal proxy contract just as a small brag anyway we'll get off of the factory friendly stuff for now and back into our module and

using it to control our safe so now that we've got our module compiling we'll jump in here go to the bottom select my module and we're going to deploy it and we're going to set our mock safe as the owner and we're going to set our button as the address we'll hit transact see that one has succeeded and so now we have our module deployed go back up here re-query owner so we can see owner is safe's address pushes it's still three but now i have this uh

additional module with a whole bunch of extra functions that were imported by the important one for us i guess we can query avatar just to confirm that the avatar is pointing to a mock safe the important one here is that i now have a push button function on my module that should be able to trigger the safe our avatar to push the button over here so i'm going to hit push button oh it's failed uh the reason that it's failed is that our mock safe needs to enable this module as a as a module before it gives it

permission to actually call this exact transaction from module function so i'm going to go ahead and drop in the address of our module into this enable module function we'll enable it as a module and now when we hit push button we should be able to see that our push counter has incremented to 4. i'll just push it again just for the fun of it and run it to 5. uh yeah using this this relatively simple uh kind of abstraction or this relatively simple kind of standard in terms of the entry point that we use to

control an avatar we are able to arbitrarily extend its logic and uh whatever way we like the really nice thing with this standard is that it doesn't doesn't invalidate any of the existing dow tools uh literally every dao framework uh has the ability uh or i should say every the vast majority of dal frameworks have the ability to make arbitrary function calls and so they can call this on on a safe so essentially for existing dial frameworks if you're wanting to kind of adopt

this as your default way of operating essentially what you do is say rather than the the kind of core contract in our dell framework being the avatar we're going to defer to a a notice safe or something else that can implement the same interface and have that be the the avatar for the organization have that be the thing that holds tokens control systems all that kind of stuff and then enable the the kind of core contract in our dell framework as a module on that save so kind of one one step removed enables this uh huge amount of flexibility in terms of how the organization is able to to grow and adapt uh over

time you know add and remove different uh control mechanisms to more complex and interesting systems so yeah i guess that's whole tutorial we've deployed a module that now can control our safe with admittedly very simple uh instructions but should kind of illustrate the concept we can go and do the same thing on on rinkerby if we want to um show it on a kind of public test map if other people want to be able to push the button or otherwise if we just want to open it up as another opportunity for questions then we can go ahead and do

um yeah so if you can hear the dogs in the background please ignore them um so look um i'm just thinking through so the gnosis save is a multi-sig wallet sort of thing where you know you get people to vote and then you execute a function call on yeah some other contract and then the um but then this pre module so that we were working on would be say used for working out kind of like voting rules i think so i think so the nurse's safe uh

at its core is essentially a programmable account right the default way of operating a nurse's safe is as a multi-sig and multiseek has this privilege in the current implementation of the nursesafe because it uses its own entry point uh it has this uh exact transaction function that you would use uh to trigger things with the the multisig unit has a whole bunch of additional parameters again one of which is the signatures that the exact function has to validate in order to actually trigger the safe to do things but again under the hood it's really just a programmable account and with this uh additional entry point exec transaction from module you can change it

arbitrarily and so like if you want to have a good kind of illustration of a progressive decentralization pathway here it might be that you uh originally spin up a safe as a multi-sick then uh maybe you think okay now we'd like to get community input on it but not kind of formal control so we'll go and spin up a snapshot instance where the community can get a vote on what we the multi-sig signers do but they don't have any kind of formal control and next step might be to add some measure of formal control in parallel with the multisig so you might deploy we have this reality module and safe snap plug into snapshot that allows via via the oracle reality.e allows you

to kind of bring the off chain voting from snapshot on chain and then autonomously trigger execution from the safe so you plug this reality module into the safe and this now becomes an additional control mechanism to the safe that can basically bypass the multiseek signals so any any module enabled on the safe does not have to get permission from the multi-designers to trigger the safe to do things it has unilateral control over the safe you can have as many modules enabled as you want and then you can have as many modules enabled in parallel with also having the multi-sig signers enabled and they all have independent control over the same uh over the same safe and so in this in this kind of third step there where

you've got safe snap and this reality module enabled uh in parallel with the multisig signers um either or both can can control the safe at the same time and so the the i'd argue that the the mechanism that ultimately controls it is the one that can act fastest uh which is probably the multi signers so what what you may want to do then uh later is restrict say what the multisig scanners can do you know the next step in this progressive decentralization journey might be to say okay we we trust these multi-sig signers but we don't want them to have unilateral control over the safe anymore we only want them to have access to specific functions

maybe we want them to have veto rights over the things that come through the the dow just in case there's a malicious proposal that makes its way through so we're going to put this scope card on limit the scope of what they can do so they can only call this uh this veto function and then maybe at some point in future the dow is comfortable and says okay we're ready to go no hands uh and we're just going to remove all the multiseek signers all together so now the only way to control it is via this uh this module that you've enabled um or via the kind of combination of modules that you've enabled yeah okay that makes sense so you could have it as a gradual progression

yeah sandra what are your questions i can see your your your thinking thing through there but what are your thoughts well not specific questions i just found the demo really helpful um aaron that was very enlightening um but i also noted i mean you mentioned early on about being involved in dao's uh very early on and um i was just interested to get your perspective on how things have changed where you think there's still room for improvement what the main challenges are and the main benefits for people who are not that familiar with jails i'll start with

room for improvement because that's something that i'm really opinionated about um so obviously one place where i think there's a ton of room for improvement is uh is in this kind of modularity and composability uh piece which is obviously what we've been talking about today uh that aside i think um one of the other kind of big limitations to how most styles operate right now is that they expect everyone to vote on everything uh you know you have uh some some voting mechanism you know all the token holders get one vote per token or something like that um and and every decision that dao makes uh is is basically a referendum uh on those token

holders um which is insanely inefficient um so like traditional firms kind of scale by delegating decision-making uh authority to uh to people at different levels in the organization giving giving people or kind of groups of people autonomy over some decisions uh within some limited scope i think uh probably adopting similar patterns in a lot of contexts is is going to be really critical for dao's being able to scale beyond uh beyond kind of their current scale but then also uh finding other mechanisms to allow things to uh to allow for the dow to execute on

things without having to go through this kind of referendum process um really kind of great examples of this are things like distributed consensus uh in terms of like the the ethereum network or the bitcoin blockchain uh where you could essentially see these as as large dells who have a very kind of tightly scoped role in terms of what the dao actually does the dow for the ethereum network is essentially that they the combination of miners or soon to be kind of validators that uh that monitor the kind of mempool and uh validate blocks and try to add new

blocks uh to to the the uh chain of blocks that that make up uh the the kind of history and the the kind of upcoming state transitions for uh for the chain um the so the dow is kind of really tightly scoped there but because of its kind of tight scope it's able to be totally permissionless like anyone can self-select as a minor or a validator and start participating in that uh that kind of game of consensus another really great example of this uh is mechanisms like quadratic funding where

um allocation of of budget comes from the the kind of independent uh inputs from a whole bunch of different folks uh essentially acting in their own mutual self-interest and i think that's the really kind of key piece to this is like enabling mechanisms where you get the desired result uh in the case of uh the ethereum network or the bitcoin network uh the desired result is this kind of secure highly available uh chain in the case of something like quadratic funding the desired result is a well-allocated budget towards kind of public goods but engineering mechanisms where you get a desired outcome from the uncoordinated inputs

of a kind of diverse and ideally permissionless set of from people essentially acting in their own mutual self-interest so as a as a minor or a validator i'm acting in my kind of self-interest in that i it's profitable for me to take on this activity but it's this kind of mutual self-interest because everyone who is doing it is is doing so for uh for a profit but then also to uh to kind of propagate this network and then similarly for kind of quadratic funding you're contributing to the projects that you value um

and kind of if if you're doing it according to the the kind of how the humorous algorithm or how kind of rational behavior predicts then you're kind of contributing to the projects uh in the amount of kind of utility that it provides to you or the utility that you get out of it um and then it um it's allocating the budget according to the kind of uh aggregate utility for for everyone uh who is contributing um yeah so i think though stepping back to the original question there is like finding ways to kind of create uh delegation of responsibilities and or finding ways to have kind of desired

results be emergent behaviors from uh people acting in their own kind of mutual self-interest two ways which does two kind of paths that those need to start exploring in terms of how they might scale their operations so they can move beyond a point where essentially everyone votes on everything thank you for your insight it's really interesting especially someone who's had your experiences you know like we wouldn't have that context and understanding of what some of those limitations are i think there's also a question there from uh kate yeah so kate said i'm curious how if the zodiac tools implement the use of

governance tokens uh and streamlining the process of token voting and delegating tokens the zodiac tools um we we haven't built anything for uh kind of creating governance tokens we have built integrations into uh or currently working on integrations into other platforms or with other platforms that do do kind of token-weighted voting so some examples of that are obviously the reality module and the safe snap plug-in that plugs into snapshot which is one place where a lot of dows do token weighted voting

in terms of delegating tokens uh snapshot uses this delegate registry that we built to enable delegations um if uh to optionally enable delegations as part of the uh the settings for any space we haven't done uh much outside of building that delegate registry in terms of streamlining the process of delegation but i think when i when i talk about delegation uh i think i'm less or less kind of delegating responsibilities i'm less thinking about uh how you might delegate your uh vote weight kind of at the root level

of an organization uh to to other people although i do think that's also a a scaling mechanism or sorry like an efficiency mechanism that's obviously the mechanism that compound uh the framework has used for or compound slash opens up one governor framework uses for making participation in dows more cost effective smaller users would presumably delegate to some larger user who can justify the gas cost of participating in governance um but when i talk about delegation i'm more thinking about uh

how you delegate around specific responsibilities so you're in a kind of more traditional organizational hierarchy you might have say multiple teams or departments each of which has a focus you might have an engineering team and a marketing team and an operations team and they kind of sub teams within that that all have kind of autonomy or relative autonomy over some subset of the activities that the organization as a whole takes part in and so that's the kind of delegation that i think is probably necessary in some dows in order to more efficiency so you may have still the top level of the dow operate as it

does currently maybe some subset of proposals still go straight to the top level uh when you're talking about really large budget allocations or uh perhaps uh the the proposals to delegate some authority to to a sub team uh at the kind of next level down but then ideal cases that the top level dell kind of does these relatively large proposals for treasury allocation enough for um delegating different permissions relatively infrequently and then you give those teams that you've delegated authority to autonomy over kind of decisions

at the lower level ideally with some kind of checks and balances if they start to misbehave um you know or you know some some leash that you can kind of reel back in if they uh if they start to misbehave or can about act outside of the interest of the uh of the dow as a whole um but yeah i think that's that's more what i'm talking about when i'm talking about delegation orca protocol is a really good example of this this is a relatively new uh dow framework that's built on top of the safe has created a kind of tiered structure of safes within safes within safes uh that all like those kind of sub groups or kind of pods within a

larger organization so i'm i guess looking forward to that becoming more uh pervasive because it's a um it's a really cool setup um and and i think very practical for the dows to to to scale beyond where they currently are sounds awesome so what i might do now so thank you very much for your talk um i think that was absolutely awesome yeah so i think everyone's doing their electronic clapping and all that business i'm going to share the um a slide of my own here which is the forthcoming talks

um there we all are i always find it disconcerting when zoom suddenly flips the video off screen um i find that really worrying but anyway um so um we have got a stack of talks booked and there are even some talks that aren't in this list yet um so next week i'm actually going to give a talk on smart contract and solidity security and um it's going to be one of those talks that might actually go for about an hour maybe an hour and a half including question time so um it's going to be um hopefully reasonably comprehensive on what to do harassio is going to talk about the ethereum reference tests and really talk drill

into what they're about how and why and really talk about his thoughts on them and how they could be improved burmese is planning to do a talk on cross chain transaction security and given the extremely recent nomad hack we've actually discussed maybe he should just talk about nomad and you know like how nomad worked what the uh what the problem was and but also the post i mean who exploited and how and you know try and track down those addresses and try and work out who's involved um and there's a lot of great information out there already but i think there's a lot of extra insights

could be done so anyway he is he might just do a general cross-chain security talk but he might focus on that nomad hack um and then we could have paul ashley talking about um dids and um then we've got the chief scientist of um chain alice's who's gonna come along and do a talk on that and then we've got lachlan and ming feng talking about their phds after that um socials so um if you're at the meetup you'll find this talk and all the others on youtube there's a slack workspace um if you're watching this on youtube and you're thinking it'd be great to go come turn

up live so i can ask tricky questions of the speakers then please um just you know click on that meetup link and join the meter every now and again there is example code and if you um want to get a copy of it just have a look there in that getup repo and of course as always there's a formal method reading group as well join the slack workspace and join the formal methods um channel within that and then you can find out about when the talks are and um review the papers where's the stop sharing all right and so that's um all from me and um so thank you again oren that was really interesting um and

um it'll be great to see the developments of this technology and the essentially that pipelining of um of technology it sounds really exciting so um cool thank you for giving a great tour yeah cheers thanks for having me it was a lot of fun yeah cool all right talk later everyone bye-bye thank you so much thank you