Hacker News Reader

Comment by bastawhiz | Hacker News Reader

> A still-unidentified attacker had borrowed $80m in cryptocurrency and deposited it in the project’s silo, gaining enough voting rights in exchange to be able to pass any proposal instantly. With that power, they voted to transfer the contents of the treasury to themselves, then returned the voting rights, withdrew their money, and repaid the loan – all in a matter of seconds.

Sounds like when I was a kid and my brother would make up a game with vague rules, but when I'd pay it in a way he didn't expect, he'd say, "no not like that!" and call our mom.

Congrats to whoever found the loophole and made nine figures!

View on HN

This isn't even a loophole.

Beanstalk apparently set up what amounts to staking system for votes. More money == more votes. Have enough money? Well, then you have the majority of votes and can do whatever you want.

This is precisely how the system was designed to work. They just didn't foresee someone building up a large enough stake to amass the voting power needed to undermine the system. And that is simply a failure of imagination and goes to show how naive these folks were.

The way this works in the real world is you have a limited number of shares that give individuals some number of votes, and those shares change hands. In order to build up a large enough position to control a company, you have to convince existing owners to give up their stake or vote with you.

But if every dollar contributed to a "silo" creates a new vote, then yeah, you're basically saying: If you're rich enough you can take control of the project by simply amassing a large enough fortune in the project.

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.

And yes, I really mean "intended". They intended for people with more money to have more of a voice. And this is the (extremely obvious) consequence of that choice.

The thing about a flash attack is that you don't need to be rich to buy that many tokens. You can borrow funds, buy the tokens with borrowed funds, execute your vote, sell the tokens, and then return the funds all in the same transaction.

The only money you would need is the cost of gas.

Absolutely, the mixing of flash loans in all this is a fascinating little "innovation" that made this transaction that much easier. But there's certainly crypto whales out there with enough funds that could've done this if they felt like it. A 2x return on an 80M investment is a pretty darn juicy opportunity for someone with a sufficient lack of scruples. TBH, the more I think about it, the more surprised I am that it took this long for someone to take advantage of this weakness...

Can you elaborate on what a flash loan is? I don't understand how someone can anonymously borrow $80M worth of anything.

A flash loan is a risk free crypto loan. It works by releasing the money only on the condition that it is returned before the end of the block. If it is not returned by the end of a block, the block is invalid and can not be added to the blockchain (provided the majority follows the block chain rules). Any block that is added to the blockchain has an exclusive lock to the entire block chain (no two blocks can "happen" at the same "time") meaning this guarantees atomicity of what happens in a block.

This but it's transactions, not blocks.

But then how are the funds used? Why is somebody able to transact with funds that they will receive in a block that hasn’t yet been added to the chain?

The transaction is basically a function call like this:

flash_loan(int amount_borrowed, func arbitrary_trades)

1. give LOANEE_ADDRESS amount_borrowed

2. call arbitrary_trades()

3. give LOANER_ADDRESS (amount_borrowed + interest)

When 2. is executed, the loanee has the money. When 3. is complete, the loaner has the money back. If the loanee doesn't have the money to give, 3rd step fails. And since its atomic, the whole transaction fails.

It's a loan with a guaranteed atomicity in repaying.

A single atomic transaction does:

1) Borrow $80M 2) Use $80M however you want 3) Return $80M + loan fees (e.g. on Aave this would be 0.09%)

The lender is algorithmically guaranteed to get the money back and the borrower can potentially take advantage of large scale transient opportunities, or...just wreak havoc on a poorly secured system.

More info here: https://docs.aave.com/developers/guides/flash-loans

And if you're wondering "but why??", if I'm not mistaken, one of the initial use cases for flash loans was in exploiting arbitrage opportunities, which tend to be transient with fairly low returns, which means you need access to large amounts of funds fairly quickly in order to take advantage of them.

They’re used a lot to maintain uniform exchange rates across Defi projects etc. In theory allowing anybody to borrow a lot of tokens to exploit arbitrage opportunities means that the rates will converge simply due to market forces (because if one project offers a better rate than another it will quickly be arbitraged away).

So it is purely a tool for speculative trading? There is no connection to the "currency" part of "cryptocurrency"?

It's a tool for...atomically loaning and repaying large amounts of money. You can use that however you want, most typically for arbitrage to bring markets into equilibrium while earning a profit. The arbitrage isn't fundamentally different from what happens in traditional markets and flash-loan-like primitives are being developed outside of crypto.

(I don't know what the second question means or what your mental model of a "real" currency is)

Structured like that, it honestly sounds like the only thing that "went wrong" is that an unplanned third party end ran their "technically this is completely by the book" rug pull.

Why are we assuming that the "unidentified" attacker isn't one of the promoters themselves?

The only bit of information I’ve found in support of their credibility is their willful “self-doxxing” in the announcement they made post-attack on their discord. Mind you, the names they gave for themselves could be completely false, they did not follow it up with any more identity proofing, but if the projects’ founders identities are what they say they are (and there is no cofounder/person involved with the project), logic dictates that save for some 4D-chess level scheme, no attacker would identify themselves immediately after the attack.

> They just didn't foresee

You're assuming that it wasn't intentionally designed that way.

The regularity of these events should makes it impossible to believe that they're all accidents... it's also not possible to figure out exactly which ones are and which aren't, which is itself no accident. (Or in which cases a third party exploited the vulnerability prematurely...)

Particularly so in that the advertised functionality of the system was obviously a non-sustatinable ponzi scheme... It was always going to explode, the only uncertainty would be how.

The counterbalance is that this is like a game of hot potato. You set up your platform with known flaw, and you wait around trying to hit max locked funds. But the whole time you're nervous someone else is going to spot the issue and take it before you do.

If that happens, and you used some kind of personal credibility to set it up, you've missed your shot.

And even if you succeed, the funds are still "dirty".

This is why you have things like quadratic voting to e the votes you have from your net worth - it’s cheap to vote once, it’s cheap to vote for two different things, but it’s very expensive to vote for the same thing repeatedly

But it's cryptocoin, so you can automatically make wallets and automatically transfer money to them rather easily.

Just a python script to avoid that artificial inefficiency entirely.

Wouldn't this be hindered a bit by the gas prices?

There are ways to reduce this issue but yeah you are right. For example, you could require people to be staking X for Y period of time in order to vote. You could have a voting system that picks voters in advance so you can't suddenly generate accounts before the vote you want to abuse is called. You could analyse accounts and not allow 'fake looking' accounts much in the same way you can spot fakes on Twitter. In fact I'm currently building such a tool for NFT collections to try help people avoid ones with dodgy buyer behaviours.

Also as the other user posted, gas fees would cripple you on Ethereum. Pretty sure I spent $50 sending some money somewhere earlier.

Quadratic voting isn't all that different from one-person, one vote, because it assumes it's difficult to create new accounts. Otherwise you could just create a new account for each vote.

So then you need an identity verification system, or at least some practical difficulty in creating many accounts without getting caught.

Quadratic voting only works in a case where it’s not trivial to create unlimited new identities that can work together.

Yes but it’s equally trivial to prevent that

>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.

Obviously 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?

I'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.

> 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?

Do you have a link to where they normally discussed these things? I would love to read that.

Not 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.

>This is precisely how the system was designed to work. They just didn't foresee someone building up a large enough stake to amass the voting power needed to undermine the system. And that is simply a failure of imagination and goes to show how naive these folks were.

My favorite take on crypto commodity is that “They’re recreating and failing to solve problems that have been solved in traditional banking for hundreds of years”.

Maybe there is some upside where this is just all growing pains, or maybe it’s all garbage all the way through, I don’t know.

But it’s clear to me that technically smart does not mean economically wise.

I believe the term is "Speedrunning every financial crisis"

Epistemic status: mostly joking:

So how long until the crypto speedrun of financial crises reaches, and then surpasses, the regular financial system and we see financial crises that haven't even happened yet in the regular financial system (but are likely to happen at some point in the future)?

This happened at the point where a significant portion of the entire earth’s energy output was consumed just to maintain the financial system.

> This is precisely how the system was designed to work. They just didn't foresee someone building up a large enough stake to amass the voting power needed to undermine the system. And that is simply a failure of imagination and goes to show how naive these folks were.

They also didn't do any research on why a mountain of legislature, regulation, and case law that protects minority shareholders exists.

By the time you're playing with nine figure sums, one would expect that to be something they should have looked into!

> They also didn't do any research on why a mountain of legislature, regulation, and case law that protects minority shareholders exists.

Well, no, because the assumption among crypto libertarians is those laws and regulations are a product of a government that's a) incompetent and/or b) corrupt.

If you take it as a first principle that the current system is the one that's broken and that you're part of a grand mission to reinvent it, of course you're not going to waste your time trying to learn from it.

And now people are learning the practical reality of what can happen to their investments when there is no mom and the dad is MIA.

The sad thing: These aren't just anonymous crypto bros on a beach losing their tokens through theft, rugpulls, crashes, or other vulnerabilities. A lot of ordinary people are burning up their savings on these schemes (enabled by platforms like Coinbase and OpenSea and even Venmo) even as they urge other suckers and family members to get in on it.

This sounds something like an insider would know and do.

Is this even illegal?

What basis would they have for calling this theft?

Reply on news.ycombinator.com