Skip to content

Latest commit

 

History

History
12 lines (11 loc) · 2.86 KB

pre-launch-security-checklist.md

File metadata and controls

12 lines (11 loc) · 2.86 KB
Raw

Pre-Launch Security Checklist

  • Have a security contact email displayed prominently in your GitHub README.md file. Make sure someone on your team actually receives those emails.
  • Make sure your GitHub repo lists the addresses where your contracts are deployed.
  • Make sure your UI links to your GitHub repo.
  • Respond to all recommended changes in your draft audit report and have the auditor publish the final version of the report including acknowledgement of your responses.
  • If you received a large number of recommended changes to your code during the audit, you should strongly consider getting a second audit after you make the changes, ideally from another auditor. Audits with long lists of issues often indicate that the auditors would have found even more issues given more time.
  • Verify your contracts on Etherscan. There are automated tools in Foundry or Hardhat that help verify for you.
  • Set up a bug bounty program. Immunefi or HackerOne can help coordinate it. Whatever you initially consider an appropriate an appropriate bounty for a High Severity issue should probably be increased by 2-10x (post-launch, the floor should be 1% of value at risk).
  • Set up monitoring and alerting. You want to be on top of what's happening with your project so you can respond quickly to security incidents. For example, you can have a script to monitor for new governance proposals and be alerted when they occur. Or, if you're using a TWAP, have a script that checks the TWAP every block, compares it against the price feed from a CEX, and alerts you if it's every different by more than 10%. Or an alert to let you know when more than 20% of the tokens in your contract have been removed in a single tx. There are a tools that you can use like Check the Chain + Grafana, or use an off-the-shelf monitoring tool like Tenderly or OpenZeppelin's Defender Sentinels.
  • Prepare emergency action scripts to pause contracts or take other defensive actions in the event of an exploit.
  • Create an incident response plan. In the event of a hack, you want to know ahead of time who will be in the war room, which platform(s) (e.g., Discord, Signal, etc) and which channels you'll use to communicate, and how to enact defensive actions. Having this all in a doc somewhere will be helpful so you can rely on it when the adrenaline is clouding your judgment. You can use this template to prepare.