Governance ZIP v1 — tl;dr and What Changed

ZIPs
1

Governance ZIP v1 — tl;dr and What Changed

I’ve posted Governance ZIP v1 for comment. This post is the short version: what the ZIP does, and what changed.

tl;dr

  • Adds GovernanceContract: Pillars propose, Pillars vote, anyone executes approved actions on-chain.

  • Scope is sporks only — CreateSpork and ActivateSpork — plus one escape hatch: rotating the signer set of the admin Multisig (a separate companion ZIP that will hold all Bridge/Liquidity operational controls). New in v1: both ZIPs activate at the same fork height, so governance never exists without its rotation target.

  • From the fork, GovernanceContract is the sole spork authority. The legacy spork-signer and CommunitySporkAddress paths are deleted from the Spork contract.

  • New in v1: an emergency spork track (Type-1E). Single 7-day round, approval only by Yes votes from >66% of all active Pillars (absolute — silence counts against), immediate execution. Because the fork removes the legacy authorities, governance’s slowest path must not be its only path: consensus bugs and live exploits can’t wait ~50 days. The bar is strictly harder than the standard track, so it works only when the whole network is paying attention.

  • Proposals must come from a registered Pillar owner address and carry a refundable 100 ZNN deposit — a fixed protocol constant, identical for every action type: returned if the vote passes or expires without decision, donated to Accelerator-Z only if Pillars actively vote it down (v1 change: NoDecision now refunds — proposers can’t compel turnout). No setter exists; changing the amount requires a Pillar-approved protocol upgrade via the ordinary Type-1 track.

  • Voting keeps the low-turnout ratchet (Type 1: 66%->55%->45%->40% participation, 50%->55%->60%->66% majority), and spork votes keep the mandatory deliberation window. v1 tightens Type-2: the floor rises from >25% to >33% participation (three rounds, not four), and rotations approved in low-turnout ratchet rounds execute only after a 72-hour delay — round-0 rotations stay immediate so a compromised signer set can still be replaced fast.

  • Activation is a hard fork at a fixed height with no adoption threshold. New in v1: the height is scheduled only after ≥66% of active Pillars signal the upgraded binary (version signaling in produced momentums) — a measurable readiness criterion that gates the scheduling, not the fork, so inaction still can’t veto it. Nodes on the old binary halt and must update and re-sync.

  • Bridge, Liquidity, and Token contracts are completely untouched.

What changed

1. Multisig dependency pinned. v0 referenced the companion Multisig ZIP without binding it. v1 requires both ZIPs to activate at the same fork height, which cannot be scheduled until the Multisig ZIP is accepted; the required interface (ChangeSignerSet callable by governance) and the initial signer-set bootstrap are stated normatively. The Multisig ZIP is now the explicit critical path.

2. Deposit fixed at 100 ZNN (closes v0 open question #2*)*. The deposit is a protocol constant for all action types — SetProposalDeposit and its bounds are removed entirely. Spam is already structurally bounded by Pillar-only proposing and the 2-open-actions cap, so an adjustment lever added attack surface (a deposit-as-censorship vector, and the only authorization edge from the Multisig into governance) without benefit. The capture loop (hostile Multisig raises the deposit to block its own removal) doesn’t need mitigating anymore — the lever no longer exists. If the amount ever drifts badly with price, Pillars change the constant through the ordinary Type-1 track.

3. Emergency spork track added. Type-1E, as above. An expired Type-1E refunds its deposit and may be re-proposed as ordinary Type-1.

4. Type-2 tightened (closes v0 open question #1 with a middle ground). Immediate finalization survives where it matters — a full-attention round-0 vote — while low-turnout ratchet approvals get a 72h public review window before taking effect. v0’s floor let ~16.5% of Pillars install a signer set instantly; v1’s minimum is ~21.8% plus the delay. The Multisig ZIP is also normatively barred from fund custody and from un-timelocked TSS-key replacement (e.g. ChangeTssECDSAPubKey), since TSS keys are de facto control of bridge funds.

5. NoDecision refunds the deposit. Forfeiture to AZ now applies only to proposals Pillars actively rejected. Spam stays bounded by Pillar-only proposing, a new cap of 2 open actions per Pillar owner, and Rejected-forfeiture.

6. Mechanics specified (closes v0 open question #3*)*. The active-Pillar count is snapshotted at round start (registry churn can’t move a live round’s thresholds); Pillars can change their vote until a round closes and votes never carry across rounds; ~60-day lead time is kept but now anchored to the ≥66% signaling criterion before the height is set.

7. Signer nomination resolved. A Type-2 proposal publishes its complete signer set + threshold, and the Pillar vote — not a nomination filter — is what legitimizes it. The Multisig ZIP must define objective eligibility criteria and may not exclude candidates by delegation status.

Unchanged from v0: the governance/operations split, Pillar-only proposing, permissionless execution, hard-fork activation with legacy-path removal, the Type-1 ratchet schedule and deliberation window, the two-threshold approval math, abstention handling, and the contract address.

Open questions for comment

  1. Type-1E parameters: is 7 days / >66% absolute the right shape? Should an expired Type-1E auto-defer into a Type-1 round 0, or require re-proposing (current design: re-propose, since votes don’t carry anyway)?

  2. Rotation delay: is 72 hours enough time for Pillars to see and contest a hostile low-turnout signer rotation before it lands?

Full spec: DRAFT Governance ZIP v1 for Comment

2

[1, 100] bounds

1 ZNN will work in proportion to the dollar amount stakes, if we achieve the vision

1,000 would be disproportionate to network tokenomics

1 Like
3

Explanation of the Rotation Delay

4

I agree. I removed it and left at 100 ZNN (for now) fixed. The proposal limits each pillar to 2 simultaneous proposals, so that alone should be enough spam prevention. Remember Chadass spamming the AZ because it was only 1 ZNN.

Do you still think we should reduce to 1 ZNN? Maybe 100 ZNN will get the pillar to really think about the proposal.

5

Follow-up Q&A

Q: What is the 72-hour delay for, and when does it kick in?

A: It applies in exactly one case: a Type-2 signer rotation approved in a ratchet round (round 1 or 2 — the low-turnout rounds). A rotation approved in round 0 executes immediately, no delay. The reasoning: round 0 requires >50% of all active Pillars to show up, so an approval there reflects broad, real-time attention — and speed matters, because round-0 rotation is the recovery path when the signer set is compromised. A ratchet-round approval can pass with as little as ~21.8% of Pillars assenting (33% turnout × 66% majority), so instead of taking effect instantly it sits on-chain as Approved but not Executed for 72 hours — publicly visible, giving everyone time to see and react before the new signer set takes control. The delay never applies to sporks: Type-1 has its own deliberation window and Type-1E’s threshold already requires network-wide attention.

Q: Do votes always run the full period, or can they finalize early once a threshold is met?

A: Depends on the type:

  • Type-1 (standard spork): always the full period. Even if the approve or reject threshold is crossed on day 2 of a 45-day round, nothing finalizes until the round elapses. This is the mandatory deliberation window — Pillars can change their vote until the round closes, so an early lead is not a decision.
  • Type-1E (emergency spork): finalizes the moment a threshold is met. Approved the instant Yes exceeds 66% of all active Pillars; rejected the instant No reaches 34% (approval has become mathematically impossible). No waiting — speed is the point.
  • Type-2 (signer rotation): finalizes the moment a threshold is met, whether approving or rejecting. The only thing that ever waits is the execution of a ratchet-round approval (the 72h above); the decision itself is immediate.

Q: What happens to a Type-1E that isn’t approved within 7 days?

A: It expires as NoDecision: the deposit is refunded and the action is terminal — it does not automatically roll into a Type-1. The proposer can re-propose the same spork as an ordinary Type-1 (votes never carry between rounds anyway, so an auto-conversion would start from zero exactly like a fresh proposal). Whether this should auto-defer instead is open question #1 above.

Q: What exactly happens to the 100 ZNN deposit?

A: Same rule for every action type:

Outcome Deposit
Approved refunded to proposer
Rejected by vote donated to Accelerator-Z
NoDecision / expired refunded to proposer

Only an active No vote forfeits it. The amount is a fixed protocol constant — no setter exists; changing it requires a Pillar-approved protocol upgrade.

Q: Who executes an approved action? What if nobody does?

A: Anyone. ExecuteAction is permissionless and costs only plasma, so a decided action can never be censored by inaction — the proposer, any Pillar, or any community member can trigger finalization. A delayed Type-2 rotation just needs one more ExecuteAction call after the 72h passes, again from any address.

Q: Why does a decided vote need an ExecuteAction call? Can’t it execute automatically?

A: NoM embedded contracts are reactive — they only run while processing a transaction, and they can only read the clock inside one. “Automatic” execution would require every node to scan all open actions every momentum and synthesize sender-less, plasma-less state transitions: new consensus-layer machinery (and consensus-layer risk) for events that occur a few times a year. Instead, execution is a normal, permissionless, plasma-only transaction: the proposer, any Pillar, any community member, or a simple bot can send it, so it cannot be censored or stalled — blocking it would mean censoring the whole network. This matches how the other embedded contracts (e.g. Accelerator-Z) already settle time-dependent state, and it makes every execution an ordinary auditable account block. Wallets can reduce it to a one-click “finalize” button.

Q: Can a Pillar change its vote mid-round? Do votes carry into the next round?

A: Yes, and no. A Pillar can change its vote any time before the round closes; the last vote counts. If a round ends undecided and the ratchet opens a new round, every round is a fresh tally — prior votes remain visible for audit but count for nothing. Pillars must show up again each round.

Q: What can governance NOT do?

A: Almost everything. Exactly two destinations and three methods are proposable: CreateSpork/ActivateSpork on the Spork contract, and ChangeSignerSet on the Multisig. Bridge, Liquidity, and Token contracts are untouchable through governance — no parameter changes, no fund access, no token issuance. Everything operational belongs to the Multisig (companion ZIP), which Pillars can always vote out via Type-2.

Q: What happens if the Multisig ZIP isn’t ready when this one is?

A: Nothing activates. Both ZIPs share one fork height, and that height cannot be scheduled until the Multisig ZIP is accepted — the companion spec is the explicit critical path. As defense in depth, even a mis-sequenced release rejects Type-2 proposals at propose time while the Multisig contract is inactive.

6

Will it require a non-governance hard fork to change the proposal stake bounds in the future?

If I understand the rate limiting mechanism, the spam would be limited to two bad jokes every 58 days or until disapproved?

7

Maybe that is configurable with the multisig with a proposed range of [1, 100]?

The duration is different for the two types.

Type 1: 108 days
Type 2: 58 days

Source: DRAFT Governance ZIP v1 for Comment