This is a discussion post to remind and reflect on Protocol design, to avoid catastrophic failure due to exploits.
On October 27, 2021 CREAM (https://app.cream.finance/), a borrow/lending Protocol on Ethereum was hacked for ~$130M.
Collateral Quality matters a lot, as the weakest asset defines the Protocol risk.
Summary of main concerns:
There are 2 main worries with these linked systems:
One of the tokens supported has an unlimited minting event.
One of the oracles has a significantly wrong price.
This can lead to depletion of all TVL as follows:
First the free/cheap asset is supplied and more of any other asset is borrowed against it (the exploit).
Second, anyone with any assets left will try to withdraw/borrow any assets they can get their hands on. This puts the protocol in a full failed state.
This is why it’s so critical to carefully vet every asset before adding it. We could add some assets for lending and borrowing, but prohibit their use as collateral. We may also want to split off some riskier assets into separate lending markets where they cannot affect the primary lending market. Maybe we can brainstorm some ways to automate middlemen between lending markets to make the experience more seamless (sort of like how raydium will chain together multiple swaps to execute the swap you want).
I would suggest to look at other projects creating tools that can help mitigate the risk - the obvious ones would be insurance projects like Nexus Mutual (although I’m pretty sure they’re not yet insuring Solana projects). Another direction would be projects like Hats.finance that encourage white hat hacking and responsible disclosure, enabling hackers to earn money in a legitimate and constructive manner rather than a destructive one. Again, pretty sure they don’t do Solana yet, but it might be worthwhile to start a discussion with them.
Hello.
I’d suggest talking to Lossless. https://lossless.cash/
They helped cream recover funds…but most importantly , they are/have build a technology to freeze and reverse hacks.
Some more thoughts on this topic:
We can (and probably should) learn from the way insurance companies are managing and mitigating their risks. Now I’m not talking about the CeFi dinosaurs (as their time has already passed), but about the DeFi ones, so let’s have a look at Nexus Mutual (NXM) in particular - they’re basically creating a cap for every protocol (in fact for every version of it) they’re willing to cover in order to limit the risk to the stability of their platform in case one of these protocols actually gets hacked and they need to pay out the insurance claims.
Obviously, I wouldn’t accept any assets as a collateral that has unlimited supply, exactly for the same reason I wouldn’t take fiat as a collateral - someone can just print more of it, sometimes heaps more.
But this risk is pretty clear (the things we know), although apparently can still be mismanaged or ignored…
We should be cautious of the risks that are not clear (the things we know that we don’t know) and the “black swan” events (the things we don’t know that we don’t know or even more dangerously - the things that we think we know, but just ain’t so).
As the topic of this thread says - “the weakest asset defines the protocol risk”, I would suggest making sure that this weakest link is both limited in size and backed up by other links, so that even if it snaps - it doesn’t cause the chain to break up.
One particular idea, that could also give a very significant utility for the $JET token is to get the projects that want their tokens to be considered as collateral on the platform - to stake/lock a significant amount of JET, to make sure there’s no economical benefit in being a bad (or negligent) actor.
This way, even if a breach occurs and the value of that token collateral becomes 0 or close to it - we’ll still have JET tokens that will be slashed and could be used as the first response insurance fund to recapitalize the missing collateral or at least part of it.
It’s actually a non-trivial task to “disable” flash-loans. For example, in one of my projects, we’ve spent a few good months developing the mechanism to do it, only to throw it all in the bin, as the auditors were unhappy about the way we did it. For every defensive action - there’s an offensive counter action, so the best way to mitigate it is to build a system of checks and balances in place that would ensure the protocol is stable, such as what I proposed above. BTW - Oracles are another weak link, which needs to have redundancy and not to rely on a single source.
all these suggestions are great. particularly the suggestion to get other projects proposing their token as collateral on Jet to have locked up JET as a sort of failsafe