ConfusedResident (???, ???)

What's this?

[ConfusedResident (???, ???) @confusedres]

Algorithmic or not, the more important thing that matters when assessing the stability of a stablecoin is the underlying asset that "backs" (either financially, or even socially) its value. Similar to corporate/government debt and national currencies

[ConfusedResident (???, ???) @confusedres]

Why was there ever a distinction between algorithmic vs non-algorithmic stablecoins? All stablecoins ARE algorithmic by virtue of the definition of algorithm: A set of instructions and procedures to be run, often by a computer (though it also applies to humans)

[ConfusedResident (???, ???) @confusedres]

4) Or perhaps I'm just thinking about @BeanstalkFarms too much recently, and this is all just nothing

@terra_money

[ConfusedResident (???, ???) @confusedres]

1) Thinking about it, if we consider $LUNA as the equity side of $UST, and that we assign theoretical asset pricing model based on discount rates and expected returns, then the market cap of $LUNA can be seen as the expected market cap of $UST

[ConfusedResident (???, ???) @confusedres]

3) If it all just boils down to pulling future expectation into the present (debt), it would be simpler for market participants and the system (economical and technical) to have a single asset ($UST in this case) and directly build a debt/loan system with pricing

[ConfusedResident (???, ???) @confusedres]

17) I'm ending this just by saying I do think @BeanstalkFarms is really cool, and the use of a credit system is a great alternative to collateralized ones that do have its setbacks

I'll continue to have my eyes on $BEAN to see when it will rise up again

[ConfusedResident (???, ???) @confusedres]

But I feel like DeFi development as is, is not conducive for that. Not just due to technical constraints and design choices, but also due to the mental burden of what is at stake along with the voices of the angry masses (or angry few)

[ConfusedResident (???, ???) @confusedres]

16) But adoption alone does not fully signal it is wise to adopt it yourself. If this were a normal web app, it would be akin to allowing users to give input to a form and not sanitize for XSS (cross-site scripting) which would be unadvised😱😱😱

[ConfusedResident (???, ???) @confusedres]

14) I sympathize with the developers of @BeanstalkFarms . The tradition of software is littered with bugs and exploitable code, but traditionally we have worked with the desire to enable incremental change

[ConfusedResident (???, ???) @confusedres]

With the recent @BeanstalkFarms hack I was also negatively impacted. Not by a large amount, but money lost is still money. But this hack episode have made me digging a bit more on the sequence of transactions

So let's start a technical 🧵on what I found out (and more)

[ConfusedResident (???, ???) @confusedres]

13) Now, beyond my fascination on the technical details my 2 beans are:

- As a software engineer that does not work with Solidity, this is definitely complex to piece together even if it doesn't seem like it is

[ConfusedResident (???, ???) @confusedres]

12) After the above transactions and for some reason transferring 0.25 ETH to the Sus Contract that is still there (I have no idea why), the exploiter initiated the flashloan attack https://t.co/zgIf6bOaji

Sus Contract invoked and the rest is history as we know it

[ConfusedResident (???, ???) @confusedres]

11) Though @etherscan does have a functionality called ReInit that highlights redeployment of contracts under the same address but with different functionalities. Example:
https://t.co/bboRmMH7l6

So not sure if it was actually a redeployment, or that everyone just missed this

[ConfusedResident (???, ???) @confusedres]

10) One possibility is that there was an existing contract but then the exploiter re-deployed a DIFFERENT contract under the same address which is apparently possible with the help of create2 and some other operations

https://t.co/J5ibKyC550

[ConfusedResident (???, ???) @confusedres]

9) It is unclear how exactly this particular issue of a lack of an actual existing contract at the address was not picked up as people were asking about the existence of BIP-18 (and then BIP-19) prior to the exploit

[ConfusedResident (???, ???) @confusedres]

8) https://t.co/mIIP54RDId

TL;DR it allows pre-emptively giving an address to a contract given a known set of values. And if we check the transaction that created Sus Contract it involves the use of the create2 opcode

[ConfusedResident (???, ???) @confusedres]

7) This would only mean that the exploiter used a specific address that did not yet (likely) exist at the time of the proposal. Is it possible for someone to pre-assign a contract's address before it's creation?

YES! Today I learned about the create2 opcode

[ConfusedResident (???, ???) @confusedres]

6) What is more interesting however is the time when the Sus Contract is created. The transaction that created it is https://t.co/4D9I2ceFwD

And notice the time of creation is at April 17 12:24 PM UTC. This is LATER than the creation of BIP-19 which was at Apr 16 11:05 UTC

[ConfusedResident (???, ???) @confusedres]

5) Some have taken note that the same address of the Sus Contract is used as the proposer's wallet in InitBip18. Though I do not believe that this matters in the end

Unfortunately, I have no idea why the exploiter decided to make InitBip18. Warning/obfuscation?

[ConfusedResident (???, ???) @confusedres]

4) If you check the address you will get this contract: https://t.co/DcIq4MAIlY

And some cursory look and checking of the decompiled bytecode tells you that this is a contract to move the hacked assets from some address to another address (eventually Beanstalk's to expoloiter's)