# Request for Comments: Aztec Governance **URL:** \ **Category:** Aztec\ **Tags:** rfc\ **Created:** [January 17, 2025, 8:17am UTC](https://forum.aztec.network/t/request-for-comments-aztec-governance/7413 "2025-01-17T08:17:56Z")\ **Posts on this page:** 1\ **Showing post:** 7
**Author:** ![Anon](https://avatars.discourse-cdn.com/v4/letter/a/47e85d/32.png) [@Anon](https://forum.aztec.network/u/Anon)\ **Post date:** [January 20, 2025, 10:27pm UTC](https://forum.aztec.network/t/request-for-comments-aztec-governance/7413/7 "2025-01-20T22:27:05Z")
> [@amin](#): > > Aztec Governance can vote on a proposal to deploy a new Issuer smart contract that contains a new `RATE`. Ossify RATE (e.g. incrementally over 1-5yr) to prevent future malicious governance from collapsing the token. As validators leave non-reward-rollups, the rollup becomes increasingly vulnerable to censorship attacks. I suggest either defaulting to based-sequencing, or triggering permanent based-sequencing based on L1 forced-inclusion usage (for non-reward-rollups). I suggest a delay period after a vote has passed during which it can be aborted by a re-vote. > [@amin](#): > > Locked Hypothetical Assets used to vote on a proposal must wait a delay before being withdrawn to prevent malicious governance attacks. Is this just to prevent double-voting? Liquid derivative contracts otherwise obviate delay protections. > [@amin](#): > > burn a large quantity of Hypothetical Asset to trigger a vote Refund the burn if the vote succeeds. To fund future protocol development an additional UPGRADE\_REWARD could be paid out if successful (only for burn-upgrades) (like a dominant-assurance contract). > [@amin](#): > > L1 congestion has made it impossible for provers to land proofs on time Provers are sophisticated actors and can purchase L1 congestion insurance out-of-band. All vote-to-slash mechanisms are vulnerable to collusion. e.g. an L1 contract which pays out if targeted validators are slashed or if a prover is not slashed. My largest concern is governance incompetence leading to a security vulnerability in the rollup. > [@\[Upgrade Proposal\] - Prediction-marketed non-governance](https://forum.aztec.network/t/upgrade-proposal-prediction-marketed-non-governance/627/3): > > I bet that most long-term upgrade proposals eventually fall prey to a critical security vulnerability. > Therefore upgrades should be avoided in favor of ossification. I’d like to see: - First class community support for non-reward-rollups - Avoid ‘canonical’ terminology in favor of V1, V2, etc. - [Unified Address Standardization](https://forum.aztec.network/t/proposal-standard-address-upgrades/2353) - Economically incentivized security information - A reward-subsidized [security prediction market](https://forum.aztec.network/t/upgrade-proposal-prediction-marketed-non-governance/627) (perhaps with trustless settlement via an impossible-to-call function) - SECURITY\_AUDIT\_REWARD, assigned to N addresses at proposal time, requiring majority sign-off - Eventual ossification of all contracts --- _[View the full topic](https://forum.aztec.network/t/request-for-comments-aztec-governance/7413)._