3 ms·
>There's probably things they could've done to reduce the likelihood of an event like this--e.g. requiring supermajority or unanimous voting for certain types o
by koboll 4y ago
>There's probably things they could've done to reduce the likelihood of an event like this--e.g. requiring supermajority or unanimous voting for certain types of changes, for example--but they didn't, so here we are. The system worked as intended.
A supermajority was required. The attacker purchased enough LP tokens to secure one. At the moment of the attack they held about 70% of voting power.
Unanimous voting wouldn't have been particularly useful because it would never be used. You can't ever convince every last investor to log in and pay gas to vote on a governance measure.
There was a protection in place, which was that the measure must be up for 24 hours before it can be passed. But the critical flaw was that the contents of a measure can be swapped out by a supermajority token holder, even after the 24 hour cooldown period. The attacker threw up 2 measures, one pointing to a nonexistent contract address, and another dummy measure as a diversion that would have transferred $250,000 to Ukraine and $10,000 to a wallet they owned. The diversion worked, and everyone spent the 24 hour period discussing why someone thought they could hoodwink the LP token holders into swindling $10,000 from them, and more or less ignored the second measure. Then, during the attack, the attacker deterministically created the treasury liquidation contract at the formerly blank address and used the flash loaned supermajority to pass it.
- deleted 4y ago[deleted]
- mrep 4y agoDo you have a link to where they normally discussed these things? I would love to read that.
- koboll 4y agoNot offhand, but if you want to find the discussions, you can go into the Beanstalk Discord and search "Ukraine" prior to the time of the attack, and you'll see people discussing the rogue measures.
- BaseballPhysics 4y agoObviously I don't understand the details of Beanstalk, and you clearly have a lot of expertise, here, so first, thank you for the details! Second, I am curious: > There was a protection in place, which was that the measure must be up for 24 hours before it can be passed. So what happens after that 24 hours? The way you've described it here, it sounds like there's an up/down voting system after the cooldown period to either confirm or block the proposed measure, but it's not clear to me how that works. Who has control over that final decision?
- koboll 4y agoI'm not a technical expert, just someone who lost a couple thousand bucks of expendable high-risk gambling money yesterday and wanted to dive deep to see why. >So what happens after that 24 hours? The way you've described it here, it sounds like there's an up/down voting system after the cooldown period to either confirm or block the proposed measure, but it's not clear to me how that works. Who has control over that final decision? Anyone with at least 0.15% (IIRC) of voting power could propose a measure, at which point it would show up on the web app frontend with every LP token holder's vote defaulting to "No". It would have to accrue "Yes" votes from holders of >50% of LP tokens within a certain time period to pass. Alternatively, holders of >2/3rds of LP token could force pass a measure immediately, though this wasn't implemented on the web app frontend. But each of these was subject to a 24 hour period -- no measure that hadn't been proposed at least 24 hours ago could pass, even by supermajority.
- BaseballPhysics 4y ago> It would have to accrue "Yes" votes from holders of >50% of LP tokens within a certain time period to pass. And I assume the decoy proposal was just a means to ensure no one realized what was going on and themselves use a flash loan to reduce the attacker's voting power below the 50% level needed to pass the proposal?