 I'm Isaac, I'm the co-summoner of the Logostow, and I'm also a research fellow at MetaGov. And today I'll be talking about some real-world examples of how DAOs have been exploited, one by me, based on proof of inattention and just generally lack of monitoring infrastructure. So I'll be detailing how I was able to steal some money from a DAO, how other people are attacking them even as much as like last night, and how you should be protecting your infrastructure from this type of vulnerability. So I've been referring to this as like proof of inattention. So inattention is really the most scarce resource in DAOs, and so governance tooling should be designed accordingly. There's all sorts of optimistic architectures out there that rely on people to actually pay attention, and that sounds pretty simple, but like people paying attention is not something that you can actually assume is happening. So SafeSnap is an example that I think is one of the most widely used optimistic architecture tools in DAOs, which uses Reality.East to bring off-chain, gasless votes on chain for execution. But MOLCDAOs also have a lazy or optimistic consensus mechanism where there's no minimum quorum for proposals to pass. Thankfully, they do require a sponsorship, but these are just two cases of things where people could very easily sneak proposals by into DAOs while people are not paying attention. So the main thing that I want to highlight today is about Reality.East. I'm called on to set up many DAOs, and often people are like, well, why can't we just have gasless voting and use Reality.East to execute our stuff? And I think the assumption is that it's this like magical thing that brings reality and truth on chain, but that's not inherent. And so the way that Reality.East works is that anybody can ask a question of the oracle that's like, hey, did this DAO vote to pay me $20,000? And then that goes in this really confusing format to Reality.East that you can see in the middle, which is almost impossible to decipher. And then if you put down yes and nobody says no, then that just happens. And so it's not anything that actually relies on a vote having to take place. Reality.East is a general-purpose oracle that you can use when attached to a noses safe to take money. So this is just a configuration of how that architecture usually works. Many DAOs have noses safe, which has multi-sig signers. Many DAOs, including things like one inch, I think shape shift. A lot of DAOs out there that use a lot of voting on Snapshot have added this Reality.East Zodiac module. When you add a Zodiac module to your noses safe, you're basically giving it super user privileges. It can shortcut all signatures. It can do anything with any assets in your safe. And so you have to be very confident in how you've configured that. So Reality.East is the separate application which brings the decisions on chain, which get executed on your safe. So anything in your safe, the NFTs, the assets, the interaction with other contracts, it can all be executed by the Reality module. And anybody in the world can ask questions of the Reality.East module. So when you're setting something like this up, there's a bunch of parameters that you can use to configure. And it's important to understand the impacts of every single one of these. Because if you misconfigure one of them, then you can make yourself significantly more vulnerable to an attack. So when you set up this Oracle, you want to set up a timeout. This is the duration during which people can answer questions. If it's 24 hours, then your question is live for 24 hours. And then whatever the answer is at the end of that period becomes the truth. If it's a week, then you have a week to answer the question. Cool Down is like a grace period after it, but after the truth comes on chain, but before it can actually be executed. Exploration is how long it stays valid. And Bond is how much you have to put down to make an answer. And there's other configurations, but I have some nice timelines that make this a little easier to understand. So the way that we intend for this to work, that a lot of DAOs intend for this to work, is that they host a vote on Snapshot. And then once that voting period is done, there's a little button on Snapshot which says, ask, like, execute this. And so that brings the, that asks Reality.East a question. And then it goes to the pool of people that sit on Reality.East and answer questions. Unfortunately, there's like three people that sit on Reality.East and answer questions. So usually it's the main person asked a question that also answers the oracle. And they tend to answer honestly and then execute. So this is the intended scenario where you've got, you've had your gas cells vote, you've minimized your on-chain transactions, and then everything executed according to plan. So there's also the dishonest oracle scenario where any attacker can pose a non-existent proposal to Reality.East and submit their own fraudulent answer. So you don't even have to go to Snapshot, you don't even have to make the vote, you can craft a transaction that's like, hey, did this Snapshot vote, which didn't really exist past? And then you put down a bond and say, yes, it did. And then you wait for that cooldown period, hoping that nobody's paying attention. And then congratulations, you've been able to steal money from the DAO. There's a few different ways that DAOs can protect against this. There's, of course, overriding the malicious answer. So Reality.East works in a way where you put down a bond to answer a question. You can put down double the previous person's bond to correct their answer, and that can kind of continue forever until it becomes not profitable to put down those bonds. So the best way to do, the easiest way to do it that Reality.East wants you to do is just correct malicious answers because you'll take the bond if your answer becomes the truth on chain. You can also request arbitration. So if a dishonest question is posed, anybody could trigger arbitration. But what I've found in surveying a lot of DAOs on Reality.East and Snapshot, most of them kind of skipped electing an arbitrator, or they set the arbitrator to themselves. And so these very simple misconfigurations can make it so it's like, well, now we don't have an arbitrator, so if we're not paying attention for a week, all of our money is at risk. There's also the opportunity to veto if there's a cool-down period. Surprisingly also, I found that a lot of the DAOs that I looked at in doing this research just skipped cool-down. They were like, now let's just execute this as fast as possible. So these are all things which may seem logical when you're setting up DAOs, assuming we're all gonna be paying attention for our NFT investing DAO all the time, but then people go on vacation, your multi-sig signers go to DevCon, they leave their ledgers at home, and now you're pretty vulnerable. So each one of these can be misconfigured and is often misconfigured. So if your timeout is too short, then it makes it too hard to catch a malicious transaction. If your cool-down is too short, you have no opportunity to veto. If you have a low bond, it's trivially inexpensive. Somebody could put down a $10 bond for a fraudulent answer. If you've no arbitrator, then you have no final safeguards against that, and an absent or negligent multi-sig signer removes the veto or opportunity. All of these are actively being exploited, even like yesterday, as I was saying, like this is a very much an ongoing issue. So first I'll detail how in the springtime, I noticed a vulnerable Honeypot, actually called like the image like HoneypotDAO.ETH or something, where I wanted to figure out how easy it was to actually exploit this. So a little over a year ago, Nose has put up this bounty. They were like, rally.ETH is this great new module. Let's put $50,000 in here and see if anybody steals it. If no one steals it, then we can feel confident that this is safe. But like so many things in crypto, it just kind of went under the radar and no one really noticed. So this thing's at dormant. I have the address here and I'll share this after. It's at dormant for a little over a year, no activity. And so I decided to try to exploit it, but I was doing it for research purposes. So I live tweeted the exploit to make it good and not illegal. So what I figured out is like how to craft the exploit using the add proposal feature on ether scan where you craft a transaction. And in this case, I was like, okay, I want this DAO to send me like 19,420 DAI. And so I crafted the transaction locally and then hashed it and included it on the ether scan link. Now a quirk of this is that you could looking at this proposal, you actually don't know what my transaction is because it's only a hash of the transactions that gets asked to the Oracle. So this is another scenario where like if you see a malicious proposal, you don't even know what the attacker's trying to do. They could be trying to take $1, they could be trying to drain the whole treasury, but all transactions are a hash so that you have absolutely no idea what's going on. So in this case, I submitted a fraudulent proposal and then I went on to reella.eth and I paid 0.1 eth as a bond to say, yes, this is true. It was fine for about 24 hours and then I saw a tweet from Oren. I cheekily called my proposal ID nothing to see here because I kind of wanted it to get detected. I could have put a proposal ID which blended in even better but I put like nothing to see here. Oren found that funny, I guess. And so Oren and some of the other folks from NOSIS were like, hey, it looks like somebody's actually trying to drain our NOSIS safe, we should veto this. But much like the NOSIS safe table earlier this morning, nobody was present to veto the transaction. So this is just, and being a honeypot Dow, they set this up as like 24 hour periods, whatever. It'll be fine. I'll go back to my funny slide, just for pictures, thank you. But it was too late. So at this point I was like on another call with another thing and people were like asking me questions. I was like, I can't talk right now, I need to finish stealing this money. So I went on and I executed it and I tweeted about that as well that I successfully drained 19,420 die from this NOSIS safe and nicely offered to give it back. They said, don't worry about it. So it was too late because arbitration could not be requested because their arbitrator was set to the zero address. The cooldown was too short and I think one person was on vacation. And nobody else on Reality.Earth was paying attention to refute my answer, like Orin refuted me once but then I refuted him and put a higher bond so I actually got his honest bond in addition to the exploit. And so like this system, yeah, it's not perfect. But then it was like quiet again for a while until like two weeks ago when people actually started using this to try to steal money. So some folks from the opium network thankfully had some monitoring infrastructure set up on one of their safes and noticed that somebody was submitting fraudulent proposals to try to drain their entire treasury. But being nice people that they are, they were like, is this attacker doing this to anybody else? And what they actually discovered was the attacker first went over, went after this really easy target. It's this DAO called Lolli DAO. It's never been used, it's like one person but there was seven and a half ether in the treasury and they had Reality.Earth configured. 24 hour voting periods, no arbitrator, no minimum bond. And so the attacker snuck some money into a fresh wallet. I think they withdrew from Aztec into a fresh wallet, put down a bond and within 24 hours had stolen seven and a half ether. So now they had seven and a half stolen ether that they could then use to put down bonds on other things. And so there's this NFT collecting DAO called, there's this NFT collecting framework called Seasons which uses DAOs that set this up. And some of them have hundreds of me bits or a bunch of stuff in their DAOs. And so the attacker started going after those. And so they used their ETH to place bonds on all of these other DAOs saying, did this pass, did this pass, did this pass? And at this point you could very easily flood the Reality.Earth UI because it's like Web3 UI and it takes 10 minutes to load when you go to the page and it's really frustrating to use. So they put these six proposals down. They put down, thankfully, the Seasons folks have done some really good configurations where they had a minimum one ETH bond, a seven day voting period. And so that gave us enough time to defend. And so some of this was going on in the ETH security telegram channel and chatting with the Seasons folks. I was able to actually go in and put down eight ETH in bonds to overcome the four ETH that they put for theirs. If they then came back and put down 16 being like, no, I really want to steal all these me bits, then I would have had to start calling up some friends. I mean, can you guys please donate some ETH so that I can defend these safes from this attack? Thankfully, they got scared and ran away and took their three ETH in profit and the attacker went away. But this is continuously happening. For the next week, I basically had this screen open on my computer refreshing like every hour to make sure that the attacker wasn't coming back. So it was a bit of a stressful time until they finally gave up and I was able to claim their ETH and make sure that the honest answer made its way on chain. So there's hundreds of millions of Dow Treasuries that are at risk of what I would say are inattention attacks. And in fact, reality.ETH is the one that I've been highlighting, but there is Malik Dows that are vulnerable to the same thing. And I want to include some links to, so Sky sent me from like a meta cartel, sent me a proof that he did of a Malik Dow inattention attack, where if you're in some Malik Dows, maybe you're in one, maybe you're 10, maybe you're in like 60 of them. And oftentimes, they go dormant for a while. There's no monitoring infrastructure in place. And so any member could be like sneakily submit a proposal while everyone's at a conference. And I'm saying this to try to scare you to like look at your DOWs and make sure no one's trying to take things from you while you're sitting here. I think that attacks like this are only going to start happening more and more frequently. So beyond smart contract audits, we need configuration audits. It's not just enough to have the core logic right. It's a matter of how you stitch together all of these composable pieces into something that is also audited and safe. And so configuration audits are something that I really want to see become more prevalent in DOWs, like whether it's the safe app, where it's like, hey, if you add these modules, you might be vulnerable here, or like, hey, you have like a green check mark, this configuration seems pretty safe for you. And I know it's early, but like these are things we should be adding before we have some sort of like trauma of like a bunch of safes getting drained. So I have some tips on how you can protect you and your DOWs from people like me and people that are worse. This is a bunch of text, but I made this to like kind of take pictures and then I'll post this out later. I think it's, as somebody that has went through like a SOC2 audit with a startup before crypto stuff, there's actually a lot of stuff from those processes that I think DOWs could adopt. They make you think about what's your resiliency plan? What's your continuity plan? Who has control over this administrative thing? Who like, is there some random multi-sig somewhere that actually holds veto power to the DOW that we're just too lazy to get rid of? There's a critical need for more monitoring infrastructure. So I know a lot of people are working on dashboards for individuals like tractor portfolios and stuff, but we really critically need more like monitoring infrastructure for DOW tooling that can like, you know, woof style, I don't know, ping you everywhere, every time there's like some sort of big transaction going on. There's cool automation tools that I think are underused as well. Open Zeppelin has a tool called Defender, which I really like for identifying dangerous scenarios, setting up alerts, and then actually submitting triggers to like pause contracts. You can create these like defender bots on that tool that look for like a malicious proposal or like maybe your DOW is going into sleep mode and you wanna set up something where it's like, okay, if anyone tries interacting with a smart contract, this pause transaction is gonna go out and you can like presign a transaction, preload it, and like have all these defense mechanisms ready to go for your communities. I think it's also really cool to see that simulation tools are getting more used, because I don't think I've seen an attack like this, but I wouldn't be surprised if somebody submitted a proposal at some point that was like, hey, we should submit my monthly payroll, but then they just add a zero to their paycheck. That would be pretty hard to detect and most people that are like on a bunch of multisig or like approve, approve, approve, approve, but thankfully, SAFE has added like tenderly simulations where you can just say like, okay, what would happen if I actually approve this and you can choose to say, okay, is that person getting paid $1,000 this month or $100,000 this month? Simulation tools in DOWs are critically needed as well. We need to conduct regular configuration audits and detect when configurations change. All of the things that in like legacy companies are really boring and they have entire departments of people for things like change management are actually needed in like composable governance settings. We should always minimize cross-chain communication. Anytime you're using a bridge, you're probably just waiting to get exploited. We need to implement spending limits and transaction guards. Everybody should use hardware while it's not back up their stuff in. And that is just like general purpose like housekeeping stuff, but like, but a last one that I think would be cool is if we could set up some sort of like on-call shifts and rotations for people that are on like 60 multisigs to make sure that they know that, hey, this person's on vacation. These six people are in Bogota. We need to like keep track of what's going on. So, I mean, in conclusion, composable governance tooling is why DOWs are going to be great and powerful and transformative, but we also need to be very careful about how we configure things or else we are just going to start seeing like floods of malicious proposals coming in and people are just gonna get overwhelmed. So, take care of your DOWs and protect them. Thank you. Thank you. Thank you, Isaac, for that inspiring talk. Are there any questions from the audience? Is it possible to set up prevention rather than monitoring? Cause I just see like, if you would have a lot of monitoring tools in your DOWs, then what makes it so different from the traditional financial system? Yeah. Does that make sense? It does make sense. And I was talking with some folks earlier about better architectures for this kind of stuff where proposals should actually be minimized in DOWs, where you can set up different governance architectures that are much more like set it and forget it. Like the folks at Protocol Guild, the way that they, and also like the Build Guild, the way that they have their payroll set up is like it's just streams which are set up until they're not. And so like, I think that more things like that where governance is a, you set it and you only have to do governance when you want to change things versus like constantly having to do proposals, makes it so that you could have like much longer voting periods, much more safety. And I think that like generally architectures that prioritize that over like active, like attention-based governance would be better. And then we're not just like flooded with notifications which is not necessarily better. Right. So that means that there's a huge opportunity for UX and designers in the space, right? For sure. Like the UX, and also like UX of like the UX of the governance itself and like thinking about things on time spans and cycles and attention and stuff. So for sure. Really interesting. Thanks. You mentioned sending out alerts when there was a possible attack going on. Have you thought about somebody trying to exploit those alerts and creating many, many false positives so that people stop paying attention to the alerts and then it allows somebody to start the attack? Notification fatigue is like, yeah, it would not necessarily be better because then we're just like, okay, which of these alerts is real, which is not? So yeah, it would be similarly bad. You've mentioned earlier about arbitration and that some of the DAOs are basically setting themselves as the arbitrator. What are the other options and how would that process work if like you get there and you need an arbitrator? Yeah. So some DAOs have like Claros court set up as arbitrators. Hello, which is cool. So that would be a great option or other systems that have a, or just any other system where somebody can be like, here's an independent board that, but your arbitrator also needs to be responsive. And so like, that's why it's kind of good to go with a protocol versus an individual because if you have like a one elected individual arbitrator, people go on vacation, people go away. So yeah, I would say like using like other consensus mechanisms like that would be ideal. This is what I enjoy helping with. So reach out. Oh, more questions? Thanks.