Security Lifecycle for DAO Proposals

Transcript

[Applause] all right thank you everyone um so these and the next few talks are going to be pretty quick these are 10 minutes so I'm going to just assume everyone in this room knows what a dow is and knows the basics um if you don't the basics are uh it's a thing on chain that governs what you do on chain whether that's user funds or protocol funds uh and more of them are coming online so we have to deal with them um specifically we are seeing them come out a lot uh when it comes to governing both defi protocols which has been very popular for governing a compound uh it even does some treasury management for UNIS swap uh among many other Dows um and then also especially L2 rollups um many of you have probably heard of this whole thing called stage one or bust uh

vitalic is not going to call anything a rollup unless it's stage one and typically that involves some level of decentralization which can typically be done through a dow that's not the only path but that's one major one uh we have major rollups such as arbitrum ZK sync and many others now moving towards a dow govern model for the protocol and how it manages upgrades in addition to a lot of Treasury funds that can be many millions if not billions of dollars so we have to deal with these and there's likely going to be more doubts in the future um but they add a lot of complexity this is no longer just one team trying to figure out how to deploy code securely which given a lot of the talks we've seen today are already very challenging now we have to deal with the fact that this

permissionless governance environment itself has increased the attack surface uh and we have to be very careful about how we manage it while still keeping some level of decentralization or some level of governance participation whatever the actual goal is um this is no not a theoretical risk we've already seen bean stock tornado cash and the compound Dow suffer some sort of impact from malicious proposals um anywhere from just having a misconfiguration that causes temporary downtime uh to having the entire protocol ultimately become compromised with funds stolen through upgradeable contracts so um this is a very real threat it's something we've already suffered losses from and if we want to actually secure the future of ethereum if we're going to actually govern all these rollups through Dows or something like a dow then we're going to

have to make sure that we're taking this very seriously so that's why we're talking to talk about Dow proposals uh and how you should protect against them um so I'm just going to start up front with here's the proposal life cycle very simply put uh I'm going to divide it into four categories that you can apply pretty broadly to any Dow uh no matter what framework you're using um eventually you're going to start with the creation process you have an idea for a proposal and you're going to implement it um this could be uh just a simple function that's going to allocate treasury funds to some account or multisig that's doing a grant committee or something like that it could be something as complex as doing a whole smart contract upgrade and changing the way the protocol works the way the governor contract itself Works which

actually involves new code and solidity code that might have to uh go through you know a rigorous development process and testing and things like that so we say that the creation process is then going to end when you've actually you know you finished defining the requirements you've hopefully identified some of those potential risks as you implement the code uh and you've eventually develop some sort of proposal payload uh that you're then going to want to be submitting onchain to the Dow before you actually submit that to the Dow you should ideally have a validation process which means that you're going to go through some sort of external review um and in the case of new code and audit uh that's going to end with validating that proposal uh once it's going to be submitted on chain and it's really important that not only are we auditing

any code changes you know if it's an upgradeable smart contract even if it's a small little change you know even a small little change can potentially cause a massive impact on a protocol um so everything and all of its impact should be updated or audited um and then you should be testing it ideally with live mainnet simulations I'll talk about why in a second but not just testing it in an isolated environment but doing it based on the Live code you're deploying it to uh because the Dow and the protocol itself are live on chain and you don't want to be making any incorrect assumptions about how that code is going to operate in production um and ideally you've then checked the proposal submitted on chain which says say even once you've submitted on chain you want to do some additional checks is this actually the same payload we were

looking at previously um were there any issues or changes introduced during the deployment um and so you want to have some general validation even once it's been submitted on chain ideally in the review phase finally the approval stage this is when everyone's actually going to show up and vote um in many cases this is token holders showing up to vote um there could be multiple stages it could be you know you could have some snapshot beforehand uh you could have a multisig that also has to provide additional approval checks um in addition to the Token holder vote so it could be a simple vote it could be multiple checks uh but with any case what you're doing in this case is ideally you're publishing everything you did in the validation stage to show hey it's been audited hey we've actually uh simulated it hey we've done testing

we've had several other people sign off on it ideally all of the QA processes have actually been published for people to verify on their own um you also need to make sure the decision makers are informed there's actually been some communication to token holders so that they know to show up to vote uh and then finally you're ideally monitoring activity on chain to watch how the vote is progressing uh how is the vote going uh do we anticipate any issues with the proposal as it moves through uh you know the uh protocol or the uh Dow and then finally execute you know once you've gotten approval it's officially been approved there's usually some sort of period uh it can be executed immediately but in a lot of cases and in best practices you have a time lock so there's several days where it's sitting before execution um and during that time

you know you should be watching that timeline watching for the exact time where that execution is going to occur um so that there's a team prepared to ensure that it goes smoothly and respond to any issues so you should have an instant response and Recovery uh plan in place if something goes wrong um and then of course you should be doing some health checks after you've executed it to be sure yes the impact has in fact uh you know done what we expected it to uh and there's no adverse effects that we have to respond to so in practice let's talk a bit about what we've learned uh working on compound because uh the open Zeppelin team has been doing uh security Audits and security work for the compound Dow for several years now uh working as a primary security partner I've been pretty involved at the high level a lot

of the Auditors that we have actually here today have also been working on that and just so you know the process is pretty simple you know you create a proposal it's sits there for 2 days you vote for 3 days it either succeeds or it fails and then you have a time lock that's CED in for two days and so these are the timelines in which we're typically working so the first incident that I want to talk about is proposal 117 which is a cth price incident uh this occurred on August 30th 2022 when we're basically uh upgrading the UAV system uh this was basically a system that was comparing unisoft prices to chain link prices uh that needed to be upgraded from Unos swap V2 to Unos swap V3 uh and the problem is ultimately there was a uh misconfiguration where even though it worked with erc20 tokens

there was actually a native ether eth function uh or Market in compound V2 uh and this Oracle didn't actually uh know how to cooperate with that market appropriately it was all the testing was only done with the erc20 market and this caused the denial service where the price could not be updated and the market was effectively Frozen because I Rec called to that market would fail when it called the Oracle um and that really sucked luckily um we were able to get a fixed proposal up very quickly um and then wait seven days going through the governance process uh to get it through and luckily the prices didn't go down in such a way that would have caused major issues um so frankly uh very lucky um and what ultimately went wrong was the validation process and I think this is probably one of the best

case studies to show that audits alone are not uh going to ensure safety because three independent audits from reputable firms were done on this code and the problem the reason that none of these Auditors caught it is because the bug wasn't in the code it was in the configur and how it would work with the onchain markets um the code made an assumption in the interface about it only needing to interact with erc20 not the native ether market and so none of the Auditors were able to catch it because it was not in scope um and so ultimately what would have caught this is if you did a maintenance simulation that would have obviously shown what honestly seemed like an obvious bug in retrospect that uh this Market would fail and you would not be able to actually do Oracle calls so what was changed a contribution policy was then

put in place that said anytime you doing a code upgrade you have to publish a mate simulation before you even put it through a vote um if there is no mate simulation that has been conducted that people can verify that everyone should basically automatically vote no because that should be a critical stage in the process um and then finally in addition to requiring the developers to be doing that stuff uh opens up when not as a security partner we're not just doing audits now but we're also doing onchain validation of that proposal and doing our own testings in a best case scenario or in a best case effort I should say because um at the end of the day we still want developers to have the ownership of making the code is secure while the security Partners or security Auditors are doing their best to uh

validate that and ensure that it's the case um the next incident is probably something that you have heard about recently if you're following any of the governance drama which was the humpy uh governance manipulation uh attempt uh so on July 26 28th 2024 uh a fellow named Humpty you can read more about him online he's got a history with Dows uh he was able to accumulate enough comp over time and spread them amongst many different accounts so it didn't look like this person had as much voting power as they did in order to then cast all their votes last minute to pass an unpopular proposal that would have given them a large portion of the compound Treasury and through that potentially control of the Dow itself because it is a voting token um and so this proposal

was passed you can see the timeline up there uh that shows that like if you can see the vote like it's clearly you know on the red line like well into like not passing and then suddenly you just see this in the last hour literally like Saturday midnight all these votes start coming in from all these random accounts that in hindsight are obviously all controlled by Humpty um that was able to pass a proposal last minute uh and so this is a problem because ultimately even though you could say well this is technically following the rules of governance uh it's actually uh you know really bad for government for someone to be able to do this because if all the token holders were aware this person had the special voting power more people would have showed up to vote and it wouldn't have passed so what was changed

a proposal Guardian uh multisig was put in place to ensure that in specific cases like this there's someone who has a check on token holders that can actually veto proposals in cases where uh some Community rule was violated um there's also an upgrade to introduce quum protection uh and there is a delegate program that is now trying to assign more comp to acted delegates that are aligned with the community um I'm almost out of time so I'm just going to run through this really quick uh this is ultimately the takeaways that I want you to have is documenting a proposal life cycle closing any QA gaps especially between the audit and then what you're actually submitting on chain so that you know what you're submitting on chain is still matching the audit uh monitoring all your proposals on chain and looking for any activity including suspicious

activity that might be coming from token holders uh as well as any issues that might lead to the proposal execution going poorly uh and then having checks on permissionless voting systems because ultimately these are permissionless systems so that means they have very large attack services and you consider having multisig or other things that have a check against them um and so the takeaway is ultimately without security these Dows are going to be more vulnerable to the very risks they are intended to avoid which is to have you know people that are able to then introduce things that affect user funds um and so to protect DS we need to have security safeguards embedded into the entire governance process both onchain and offchain we can't just rely on the code alone we also have to have the people that are running these Dows and participating in them to take security

seriously and implement it in everything they do so uh thank you for your time and uh on to the next person [Applause]