I would like to see an ecosystem wide agreement on some base rules like Red Team Rules of Engagement | The GitLab Handbook.
The more we practice incident response, the more we will be prepared to dance agilely among the other chains. The entire subtree rooted at Security at GitLab | The GitLab Handbook is fantastic reading.
Soundness catastrophes are a unique problem to zkp-based technology and is something we should really focus on here. Unlike many other blockchains, Mina relies fundamentally on the soundness of its zk-SNARK circuits for its security model, and all zkApps inherit this. A vulnerability at the circuit/proof system/hardness-assumptions level could potentially invalidate all past and future proofs generated with the vulnerable system. This means all rolled-up state would need to be re-derived from the original inputs to generate new, trustworthy proofs under the patched circuit and verification keys. For applications using private inputs, this could even require a complete reset and loss of private state.
Governance and the ability to push emergency upgrades are important, but don’t fully solve the problem of needing to reconstitute state. We need robust processes in place to handle these scenarios.