Don_G_Lover what does investment look like? Is it active (I'm mostly naive to the Bean mechanics)?
Prior to the exploit, we were seeing a significant uptick in the last month, with a number of seven figure entries into both the silo (A description below) and pod line (the facility where external investors lend to the protocol in return for zero-coupon bonds). This resulted in a significant growth in returns on silo deposits, and a significant acceleration of pod clearance (i.e. the protocol was paying down it's debt at an accelerating rate) - by all measures, the project was entering a significant growth phase.
Description of the "Silo"
The Silo is the facility wherein one provides LP deposit tokens and collects a proportional share of half the new issuance (the other half goes to the pod line) of beans (bean being the stabletoken) and accrues "seeds" and "stalk"; the former being largely an internal accounting mechanism, the latter being the governance asset of the protocol (which is presently not a transferrable token, but is intended to become a standard ERC-20 token in the future). To create an opportunity cost to withdrawing one's deposit, if one withdraws their original deposit, while they retain any beans they've earned, they burn any accrued seeds & stalk (and in the future, when stalk becomes transferable, they will need to hold the requisite amount (that'll be burnt) to redeem their deposit.
Regarding the fundraiser, which the project team are branding as the "Barn Raise", the specifics are still being finalised, but the plan communicated thus far is as follows:
- The asset to be raised is yet to be determined. Last discussions were considering USDC or 3CRV.
- The asset purchased by investors will be pods, in a separate pod line used only for funds raised during this event. Critically, this means they will begin being repaid once the protocol is unpaused - new investors will not have to wait for old debt to be repaid first.
- After the fundraiser concludes and the protocol is unpaused, new issuance will be split equally (i.e. 33% each) between the fundraiser pod line, old/main pod line and the silo. There is discussion around the first 20M of new issuance going exclusively to the new pod line.
- An initial auction phase will run for one week, followed by the sowing phase.
- The sowing phase will run for three days. During this phase the "weather" (the discount on the sold pods) will begin at 0% and rise by 1% every 10 minutes.
- The total raise is capped at 76M USD-equivalent.
- In the event that the target amount is not raised, all pre-existing holders will have their holdings in the protocol (pods, stalk, seeds and LP tokens) slashed proportionally (e.g. if only 10% of the target is raised, pre-existing holders take a 90% haircut). New investors are not subject to this (i.e. regardless of whether or not the target amount is raised, new investors will receive the full amount of pods they purchased)
shadow I cannot support Olympus deploying assets there. It is just not something we do, investing in this kind of risk for whatever reason.
Completely understandable, however I would still like to clarify upon something else you mentioned here:
shadow What makes it a bit worse is also that this isn't really a "new protocol" as you say, it is a protocol with plenty of scared liquidity waiting to exit
When the protocol resumes, all pre-exploit silo deposits will be locked until the fundraiser podline has cleared (i.e. until all new investors, such as potentially Olympus, have seen their pods mature). Pre-exploit silo deposit holders can exit early, but will forfeit a portion of their deposit (post potential haircut depending on how much of the target capital is raised) inversely proportional to how much of the fundraiser pod line has cleared; if the fundraiser pod line has only cleared 1%, then any pre-exploit holders exiting at this point forfeit 99% of their deposited/accrued assets, if the fundraiser podline has cleared 50%, then any pre-exploit holders forfeit 50%.
Other potential concerns and mitigation
"Bean could depeg when new investor pods mature"
Pods only mature when the TWAP of bean over one season (one hour epoch) is above peg, pod holders selling the beans they acquire at maturity is an intended part of peg maintenance and has historically functioned as designed; oscillations around peg growing in frequency and lessening in amplitude.
Additionally, a block of pods (a set of pods purchased in a single transaction, referred to as a "plot") do not mature atomically; the amount of pods that mature per eligible season depends on how much new issuance there is, which in turn depends on the calculated supply shortage over this period (exact calculations are in the previously linked whitepaper).
This means that a large plot, perhaps considering of millions of pods, will not all become liquid in a single epoch; the selling pressure will be amortised over some time, and should the price dip below peg, new issuance ceases until the next peg cross - which occurs based on beans being burnt to purchase pods in the main podline (this mechanism has a demonstrated history of functioning as intended prior to the governance exploit).
shadow as well as a history of suffering an exploit that was preventable.
Absolutely, mistakes were made, but as detailed in the opening post of this topic, significant steps are being taken to address this going forward. I still feel the attempt at pure on-chain governance was an admirable level of commitment to decentralisation, but admittedly premature; true on-chain governance is an as-yet unsolved problem, and prominent voices in the space (including Vitalik) have expressed doubts to it being attainable.
While it does not change what has happened (and this is not an attempt to shift blame for the exploit), it should be noticed, Omniscia, an auditor Olympus itself has used in the past, failed to note the flash-loan vulnerability in the emergencyCommit
function within the governance facet (which, contrary to their public statements since was part of the code their audit covered).
This attack was not as trivial as some are suggesting. It has been pointed out that the governance proposals (BIPs) involved in executing the exploit were drawn to the attention of the team prior to the exploit occurring. They were judged as benign, which hindsight has proven incorrect.
A major factor that lead to this incorrect assessment, was that an address involved in this proposal was incorrectly assumed to be an externally-owned-account due to it's past transaction history. This account contained no code at the time - the actual payload of the exploit was not present at the time of the review, and was only deployed on-chain at this predetermined address via a CREATE2
helper shortly before the exploit was executed.