A collection of stories of exploited projects on Stacks, and the lessons learned from them
I'm keeping a log of project exploits on the Stacks blockchain in this repo. Where possible, there's also a detailed technical explanation of the exploit causes and some ideas on preventing similar issues from happening in the future.
The goal is to provide me and whoever would be interested with an educational resource they could leverage to decrease the likelihood of an exploit happening on the projects they're working on.
| Project | Website | Source | Details | Discussion |
|---|---|---|---|---|
| Lydian | lydian.xyz | x.com/Lydian_DAO | view | Go to discussion |
Designing decentralized governance protocols is a tricky problem. DAO protocols will often work by granting some extraordinary power to members based on one or many factors. Those special powers will necessarily be something of great value, or else the DAO wouldn't have a reason to exist in the first place. The members of the DAO, more often than not, are unknown players with different intentions. For a DAO to work, developers must encode in smart contracts the rules that will ensure the output of the DAO follows its members' agreed intent. This is a challenging task for developers for a few reasons:
- Smart contracts are rigid artefacts: they can't be changed once deployed.
- Theoretically, it would be best to consider every possible scenario that could play out in the DAO to encode all the necessary rules. Sometimes this includes things outside the DAO's control but still affects it.
- The language you express your rules in a blockchain differs from the language members discuss them. A lot can be lost in translation.
To mitigate the risks related to those challenges, anyone working on DAOs should consider the following:
- Dedicate time to the protocol design. Review it extensively, and look for as much high-quality feedback you can get as possible;
- Make sure that your smart contracts can be upgraded safely. You're most likely not going to get it right on the first try;
- Add kill switches: if something goes really bad, make sure you can pull the chord and stop malicious actions before they're definitive.
When making a contract upgradeable, ensure the old version can't be used anymore.