# Improve ecosystem's security posture by organizing practice

**URL:** <https://forums.minaprotocol.com/t/improve-ecosystems-security-posture-by-organizing-practice/6253>\
**Category:** MIPs (Mina Improvement Proposals)\
**Created:** [April 10, 2024, 2:58pm UTC](https://forums.minaprotocol.com/t/improve-ecosystems-security-posture-by-organizing-practice/6253 "2024-04-10T14:58:10Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![emberian](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/emberian/32/2021_2.png) [@emberian](https://forums.minaprotocol.com/u/emberian)\
**Post date:** [April 10, 2024, 2:58pm UTC](https://forums.minaprotocol.com/t/improve-ecosystems-security-posture-by-organizing-practice/6253/1 "2024-04-10T14:58:10Z")

</div>

I would like to see an ecosystem wide agreement on some base rules like [Red Team Rules of Engagement | The GitLab Handbook](https://handbook.gitlab.com/handbook/security/threat-management/red-team/red-team-roe/).

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](https://handbook.gitlab.com/handbook/security/) is fantastic reading.

---

<div class="post-metadata">

**Author:** ![emberian](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/emberian/32/2021_2.png) [@emberian](https://forums.minaprotocol.com/u/emberian)\
**Post date:** [April 10, 2024, 4:38pm UTC](https://forums.minaprotocol.com/t/improve-ecosystems-security-posture-by-organizing-practice/6253/2 "2024-04-10T16:38:03Z")

</div>

**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.