DRAFT Governance ZIP v1 for Comment

0x3639 · July 5, 2026, 10:46am

DRAFT Governance ZIP v1 for Comment

Field	Description
zip	ZIP:-XXXX (to be assigned by sponsoring Pillar)
title	Pillar-Governed Embedded Governance Contract (Spork-Scoped)
author	0x3639
status	Draft
type	Hard Fork
acceptance	Community review; the fork proceeds at the enforcement height regardless of adoption (§11).
activation	Hard-coded enforcement at a fixed momentum height (TBD), scheduled per §11 with the Multisig ZIP.
created	2026-05-31
updated	2026-07-05
requires	Multisig Embedded Contract ZIP (TBD). Both activate at the same fork height (§2, §11), which MUST NOT be scheduled until the Multisig ZIP is accepted.
license	GNU General Public License v3.0
link	TBD — upstream PR to `zenon-network/go-zenon`
branch	0x3639/go-zenon@codex/governance-ratchet (`81c2474`), pending updates below
original	sumoshi21, go-zenon PR #47

Abstract

This ZIP adds GovernanceContract, an embedded contract letting registered Pillars propose, and active Pillars vote on and execute, exactly two classes of action: (1) creating and activating Sporks — via a deliberate standard track or a supermajority emergency track; and (2) rotating the signer set of the admin Multisig defined in the companion Multisig ZIP. Proposals require a Pillar’s registered owner address and a refundable 100 ZNN deposit: returned if the proposal passes or expires without decision, donated to Accelerator-Z if rejected.

Activation is a coordinated hard fork at a fixed momentum height (TBD), shared with the Multisig ZIP and proceeding regardless of adoption once scheduled. At that height, the legacy spork-signer and CommunitySporkAddress paths are removed, making GovernanceContract the sole spork authority. Operational admin moves to a community-nominated Multisig (separate ZIP), per Forks, Sporks, Governance and Admin.

Motivation

Governance decisions and operational decisions are not the same thing. Sporks are consensus changes: they affect every node operator, require a network fork, and warrant a deliberate Pillar vote. Bridge halts, keygens, token pairs, and liquidity parameters are operational controls needing responses in hours, not weeks. Testnet implementation of a broadly-scoped governance contract (the PR #47 lineage) made this concrete: Pillars will not vote on trivial operational changes — a bridge keygen alone could take 90 days to start and 90 more to enable. The split:

Governance (this ZIP). Spork creation and activation, plus one escape hatch: rotating the admin Multisig signer set, so Pillars retain ultimate authority over who holds operational control.
Operations (companion Multisig ZIP). All admin methods on Bridge, Liquidity, and future embedded contracts move to a Multisig with active, community-nominated signers that can act in hours and cannot access embedded contract funds.

Today the Spork contract restricts CreateSpork/ActivateSpork to a hardcoded spork-signer, with a time-bounded CommunitySporkAddress path. This is no longer theoretical: the signer’s whereabouts are unknown, so the network has no reachable spork-activation authority at all. Hence hard-fork activation (§11), outright removal of the defunct paths (§6), and the urgency of on-chain spork governance. And because the fork makes GovernanceContract the sole spork authority, its slowest path must not be its only path: the Type-1E emergency track (§4) covers consensus bugs and live exploits.

Specification

1. New Embedded Contract

z1qxemdeddedxg0vernancexxxxxxxxxxxklyh23   // GovernanceContract

Added to common/types.EmbeddedContracts; callable only from GovernanceForkHeight (§2).

2. Activation by Hard Fork

Constant:     GovernanceForkHeight (TBD — set per §11 readiness criterion)
Enforcement:  IsGovernanceForkEnforced() == true for height >= GovernanceForkHeight
Coupling:     GovernanceForkHeight == MultisigForkHeight (companion ZIP);
              MUST NOT be scheduled until the Multisig ZIP is accepted
Prerequisite: None at the height; once scheduled, the fork proceeds
              regardless of Pillar adoption (§11)

Spork-based activation is not available: it would require the legacy spork-signer, whose whereabouts are unknown. Implementations MUST NOT condition enforcement on any on-chain spork object. Before GovernanceForkHeight, GovernanceContract is absent from the embedded-contracts map; from that height, GetEmbeddedMethod resolves to the governance-aware map and the §6 changes take effect.

Same-height activation with the Multisig ZIP guarantees no window in which governance exists but its Type-2 destination does not, and none in which the legacy spork paths are gone while admin migration is pending. Legacy Bridge/Liquidity administrators remain authoritative until that height. As defense in depth, proposals with Destination == MultisigContract are rejected at propose time if the Multisig contract is not active.

3. Contract ABI

function ProposeAction(
    string  name,
    string  description,
    string  url,
    address destination,
    string  data,
    bool    emergency     // valid only when destination == SporkContract (§4)
)

function ExecuteAction(hash id)

function VoteByName(hash id, string name, uint8 vote)
function VoteByProdAddress(hash id, uint8 vote)

variable action(
    address owner,
    string  name,
    string  description,
    string  url,
    address destination,
    string  data,
    int64   creationTimestamp,
    uint8   type,
    uint8   round,
    hash    currentVoteId,
    int64   roundStartTimestamp,
    uint32  activePillarSnapshot,   // active-Pillar count fixed at round start (§4)
    int64   approvalTimestamp,      // set on approval; drives Type-2 ratchet delay (§5)
    uint8   status,
    bool    executed,
    uint256 deposit
)

vote = 0 is Yes, vote = 1 is No (matching definition.VoteYes/VoteNo).

4. Action Types, Rounds, and Thresholds

Three action types. Type is derived from destination plus the emergency flag; SporkContract and MultisigContract are the only permitted destinations. emergency == true is valid only with SporkContract (ErrInvalidEmergencyFlag otherwise).

Type	Destination	Allowed methods	Track
1	`SporkContract`	`CreateSpork`, `ActivateSpork`	Standard; ratcheted rounds below
1E	`SporkContract`	`CreateSpork`, `ActivateSpork`	Emergency; single 7-day round, Yes from >66% of all active Pillars
2	`MultisigContract`	`ChangeSignerSet`	Signer rotation; ratcheted rounds below

Type-1 actions are consensus-authority changes on a deliberate timeline. Type-1E is the emergency track for the same methods: it trades the ratchet and deliberation window for an absolute supermajority — abstentions and non-votes count against approval. Strictly harder than Type-1 at every realistic turnout, the flag enables no threshold-shopping: it buys speed only when support is overwhelming. Type-2 rotates the admin Multisig signer set — the “overthrow” mechanism. The decoded calldata’s method selector is validated against the allowlist at propose time.

If the initial round of a Type-1 or Type-2 action ends undecided, the action enters a bounded low-turnout ratchet: each round lowers the participation requirement but raises the directional (Yes+No, excluding abstentions) percentage required to win.

Type	Round	Active-Pillar threshold	Directional threshold	Period
1	0	>66%	>50%	45 days
1	1	>55%	>55%	21 days
1	2	>45%	>60%	21 days
1	3	>40% floor	>66%	21 days
2	0	>50%	>50%	30 days
2	1	>40%	>60%	14 days
2	2	>33% floor	>66%	14 days

activePillars below is the activePillarSnapshot recorded at round start (§5) — registry churn during a round cannot move the round’s thresholds. A round approves when:

(yes + no) * 100 > activePillars * activePillarThreshold
yes * 100 > (yes + no) * directionalThreshold

A round rejects when the same participation condition holds and no * 100 > (yes + no) * directionalThreshold.

A Type-1E action approves the moment yes * 100 > activePillars * 66, and rejects the moment no * 100 >= activePillars * 34 (approval has become mathematically impossible). If the 7-day window elapses with neither met, the action expires as NoDecision; it MAY be re-proposed as ordinary Type-1.

Abstentions count toward VoteBreakdown.Total for audit visibility but not toward either threshold — abstaining equals not voting (for Type-1E, effectively voting against). A Pillar MAY change its vote until the round closes; the last vote counts. Votes do not carry across rounds — each ratchet round is a fresh tally under a fresh vote id; old votes remain queryable. After the final round with no decision, the action expires as NoDecision.

5. Proposal Lifecycle

Propose. ProposeAction MUST be sent from the registered owner address of an active Pillar (not producer or reward address); otherwise ErrNotPillarOwner. An owner MAY have at most 2 (MaxOpenActionsPerPillar) actions in Voting status; further proposals get ErrTooManyOpenActions. The send must carry exactly ProposalDeposit (100 ZNN) in ZnnTokenStandard — a fixed protocol constant, identical for all action types (§9); changing it requires a protocol upgrade via the ordinary Type-1 track. The deposit is escrowed and settled at finalization. The contract:

Verifies the sender is a registered, active Pillar’s owner address at the frontier momentum and under the open-action cap.
Validates Name/Description lengths, Url against the project-URL regex, Data is valid base64, Destination and decoded method are on the §4 allowlist, and emergency is false unless Destination == SporkContract.
Assigns Id = sendBlock.Hash, Owner, CreationTimestamp, Type, Round = 0, CurrentVoteId = Id, RoundStartTimestamp, ActivePillarSnapshot from MomentumStore.GetActivePillars(), ApprovalTimestamp = 0, Status = Voting, Deposit = sendBlock.Amount; writes an ActionVariable under key 0x00 || id.
Writes VotableHash{Id: CurrentVoteId} so existing pillar-voting machinery is reused.

Vote. Each active Pillar casts one standing vote per round via VoteByName/VoteByProdAddress, changeable until the round closes. The id MUST be the action’s CurrentVoteId (differs from Id after round 0).

Finalize / Execute. Any address MAY call ExecuteAction(id). The contract:

Returns ErrDataNonExistent if the action does not exist; returns silently if already executed or terminal with no pending delayed send.
Loads the round schedule, the VoteBreakdown for CurrentVoteId, and the round’s recorded ActivePillarSnapshot (never the live Pillar count).
Computes directionalVotes = yes + no; abstentions are excluded from thresholds.
Type-1 cannot finalize until the round’s period elapses — a minimum deliberation window. Type-1E and Type-2 may finalize as soon as thresholds are crossed — Type-1E for emergencies, Type-2 so a compromised signer set can be replaced without waiting out the round.
On approval: sets Status = Approved and ApprovalTimestamp, refunds Deposit to Owner. The contract-send to Destination (decoded Data, Amount = 0, ZNN) is emitted immediately for Type-1, Type-1E, and round-0 Type-2 (sets Executed = true); for Type-2 approved in a ratchet round, only by a later ExecuteAction at or after ApprovalTimestamp + Type2ExecutionDelay (72h) — until then the pending rotation is visible on-chain.
On rejection: sets Status = Rejected, closes the VotableHash, emits nothing, donates Deposit to Accelerator-Z.
If the round is open with no decision, returns without effect.
If the round elapsed undecided and another ratchet round exists: closes the VotableHash, increments Round, derives a fresh CurrentVoteId from (id, round), resets RoundStartTimestamp, re-records ActivePillarSnapshot, writes the new VotableHash.
If the final round elapsed undecided (or a Type-1E window expired): sets Status = NoDecision, closes the VotableHash, refunds Deposit to Owner.

6. Authorization Changes to Existing Contracts

Spork contract: from GovernanceForkHeight, CreateSpork/ActivateSpork are callable only by GovernanceContract. The legacy spork-signer and CommunitySporkAddress paths — and all supporting code — are removed at the fork. No hardcoded address retains spork authority.
Multisig contract (companion ZIP): ChangeSignerSet MUST accept GovernanceContract as an authorized caller alongside the internal M-of-N path, so an approved Type-2 action can install a new signer set unilaterally. The Multisig ZIP MUST also satisfy: (1) no Multisig-controlled method may hold direct custody of embedded-contract funds; (2) methods equivalent to fund custody — notably TSS-key replacement such as ChangeTssECDSAPubKey — MUST carry their own timelock or remain outside Multisig scope; (3) signer eligibility criteria MUST be objective, published, and free of delegation-status exclusions; the initial signer set and threshold are hardcoded fork parameters published before the shared height is scheduled. This ZIP treats any well-formed Type-2 payload (complete signer set + threshold, published in the proposal’s url/description) as valid — legitimacy comes from the Pillar vote, not from gatekeeping nominations.

Bridge, Liquidity, and Token contracts are untouched by this ZIP. Bridge/Liquidity admin migration and guardian removal are specified in the Multisig ZIP and activate at the same fork height (§2).

7. Plasma and Fees

ProposeAction: EmbeddedWDoubleWithdraw plasma. ExecuteAction: EmbeddedSimple. Votes inherit pillar-voting pricing. The deposit (§5) is a fixed protocol constant — 100 ZNN for every action type — and settles at finalization: refunded on Approved and NoDecision, donated to AZ on Rejected. It is not a fee — a proposal not actively voted down costs only plasma.

8. RPC

New public namespace embedded.governance:

GetActionById(id hash) -> Action
GetAllActions(pageIndex uint32, pageSize uint32) -> ActionList (Count int, List []Action)
GetPillarVotes(name string, ids []hash) -> []*PillarVote — the named Pillar’s vote per action-round vote id (nil if not voted); enables per-Pillar “governance action required” indicators.

Action wraps ActionVariable with computed fields:

Expired               bool    // Current round has elapsed
Round                 uint8
Status                uint8   // Voting, Approved, Rejected, NoDecision
CurrentVoteId         hash
ActivePillarThreshold uint32
DirectionalThreshold  uint32
VotingPeriod          int64
ExecutableAt          int64   // 0, or ApprovalTimestamp + Type2ExecutionDelay (§5)
Votes                 *definition.VoteBreakdown

IsGovernanceForkEnforced() bool is added to AccountVmContext.

9. Constants Introduced

Type1Action                       = uint8(1)   // Spork actions (standard track)
Type2Action                       = uint8(2)   // Multisig signer-set rotation
Type1EAction                      = uint8(3)   // Spork actions (emergency track)
ActionStatusVoting                = uint8(0)
ActionStatusApproved              = uint8(1)
ActionStatusRejected              = uint8(2)
ActionStatusNoDecision            = uint8(3)
Type1ActionActivePillarThresholds = []uint32{66, 55, 45, 40}
Type1ActionDirectionalThresholds  = []uint32{50, 55, 60, 66}
Type1ActionVotingPeriods          = []int64{45, 21, 21, 21} // * PhaseTimeUnit
Type2ActionActivePillarThresholds = []uint32{50, 40, 33}
Type2ActionDirectionalThresholds  = []uint32{50, 60, 66}
Type2ActionVotingPeriods          = []int64{30, 14, 14}     // * PhaseTimeUnit
Type1EPillarYesThreshold          = uint32(66)  // absolute: yes vs all active Pillars
Type1EVotingPeriod                = int64(7 * PhaseTimeUnit)
Type2ExecutionDelay               = int64(72 * 60 * 60)     // 72h; ratchet rounds only
MaxOpenActionsPerPillar           = uint8(2)
GovernanceForkHeight              = uint64(TBD)   // == MultisigForkHeight; set per §11
ProposalDeposit                   = 100 * g.Zexp  // all action types; changeable only by protocol upgrade
GovernanceActionDataMaxLength     = MaxDataLength

New errors: ErrUnkownActionType, ErrInvalidActionRound, ErrForbiddenDestination, ErrForbiddenMethod, ErrNotPillarOwner, ErrInvalidEmergencyFlag, ErrTooManyOpenActions.

10. Fork Classification

This ZIP is a Hard Fork, hard-coded at GovernanceForkHeight. From that height, non-upgraded nodes cannot validate governance transactions and stop following the canonical chain — the chain followed by upgraded nodes is canonical. There is no adoption threshold at the height itself.

11. Activation

This ZIP and the Multisig ZIP are finalized after community review. GovernanceForkHeight MUST NOT be scheduled before both are accepted, and MUST equal MultisigForkHeight.
Implementations merged; a release is cut with version signaling enabled but no height set, making adoption publicly measurable from produced momentums.
Readiness criterion. When ≥66% of active Pillars have signaled the upgraded binary over a sustained window (suggested: 7 consecutive days), a point release sets GovernanceForkHeight at least 60 days of momentums ahead. The criterion gates the scheduling of the height, not the fork itself, so it cannot recreate paralysis-by-absence.
The fork proceeds at GovernanceForkHeight regardless of adoption. From that height, GovernanceContract is callable, the §6 changes take effect (in both ZIPs), and the legacy spork paths cease to exist. Legacy nodes halt and must re-sync on the new znnd.

Rationale

Why scope governance to sporks only? Sporks warrant deliberate, high-threshold votes; bridge halts, keygens, and liquidity parameters need hour-level response, and Pillars won’t reliably vote on them. Operations move to the Multisig, which holds no treasury power.

Why same-height activation with the Multisig ZIP? Governance alone would leave Type-2 without a destination and any weakness in legacy Bridge/Liquidity admin keys without an on-chain fix; coupling the heights makes the companion ZIP the explicit critical path.

Why Pillar-only proposing? Requiring the owner address (not producer/reward, which may be changed) binds each proposal to the entity with registered stake; anyone else can lobby a Pillar to sponsor. With the deposit and open-action cap, spam requires registration and capital at risk.

Why hard fork activation, no adoption threshold, and full removal of the legacy authorities? Spork activation requires the legacy signer, whose whereabouts are unknown — the inability to activate sporks is the problem this ZIP fixes. An adoption gate would hand a de facto veto to inaction; the §11 criterion governs only when the height is set. And keeping either legacy path as a parallel authority would leave the spork security model as weak as its weakest key — one that cannot be rotated, audited, or revoked.

Why an emergency track, and why may the proposer select it? Once governance is the only spork path, its slowest path must not be its only path: a consensus bug or live exploit cannot wait out a 45-day round plus ratchet. Type-1E requires Yes from >66% of all active Pillars, so silence blocks it — it functions only in the attention-saturated conditions a genuine emergency creates; an attacker who can clear that bar at will already controls the network. Being strictly harder than Type-1, the flag enables no threshold-shopping. If the bar isn’t reached in 7 days, the action degrades to re-proposing as Type-1 — the v1 status quo.

Why a fixed 100 ZNN deposit, refunded on NoDecision? A trivial fee is too cheap to keep noise out; 100 ZNN is skin in the game but not a fee — a proposal that convinces Pillars costs nothing, and rejected deposits fund AZ so nobody profits from failure. The amount is a protocol constant with no setter: spam is already structurally bounded by Pillar-only proposing and the open-action cap, so an adjustment lever would add attack surface (a deposit-as-censorship vector, and the only authorization edge from the Multisig into governance) without buying anything. If the amount ever drifts badly with price, Pillars change the constant through the ordinary Type-1 track — “the deposit can only change by Pillar vote” is the stronger property. NoDecision refunds because a proposer cannot compel turnout; forfeiture is reserved for proposals Pillars actively voted down.

Why the Type-2 ChangeSignerSet action, open to any well-formed signer set? Moving operations to a Multisig raises the question of who controls the Multisig; governance-controlled rotation gives Pillars a permanent on-chain overthrow path. An eligibility filter would recreate the governance question one level down, and exclusion rules can function as censorship — so the vote is the filter; criteria for the initial set belong to the Multisig ZIP (§6).

Why these thresholds and windows? Sporks alter protocol rules and start at 66%, with a deliberation window so early crossing doesn’t instantly execute. Rotation starts at 50% so a compromised signer set can be replaced without a supermajority hurdle, executing immediately in round 0 because replacement may be an emergency; Type-1E executes immediately because its absolute supermajority already embeds network-wide attention. The ratchet keeps low turnout from permanently blocking governance while later rounds demand stronger agreement — but the v1 Type-2 floor let ~16.5% of Pillars (25% turnout × 66%) install a signer set instantly; v2 requires ~21.8% minimum assent and holds ratchet-round rotations 72 hours, keeping round-0 recovery instant while a quiet capture becomes publicly contestable.

Other design choices. ExecuteAction is permissionless so execution cannot be censored; other destinations are out of scope by design; abstentions are visible but non-binding. Rejected alternatives: one contract for governance and operations; an “Operational” action class inside governance; security councils; proposer-specified types; unbounded threshold decay; vote carryover; deleting action history.

Backward Compatibility

Before GovernanceForkHeight, governance transactions are universally rejected and behaviour is unchanged. From that height, non-upgraded nodes halt and must upgrade and re-sync. Enforcement comes solely from the release binary; the version signal (§11) informs scheduling only. Chain-split risk is accepted and mitigated by the readiness criterion, lead time, and public tracking.

Address state, plasma rules, token issuance, momentum/account-block formats, and the Accelerator-Z, Pillar, Sentinel, Stake, HTLC, Token, Bridge, and Liquidity contracts are unchanged by this ZIP (Bridge/Liquidity admin migration occurs in the Multisig ZIP at the same height). The Spork contract gains GovernanceContract as sole authorized caller and loses the legacy paths — by design, as neither has a reachable, accountable keyholder.

Reference Implementation

Original: zenon-network/go-zenon#47 by sumoshi21. This ZIP’s branch: 0x3639/go-zenon@codex/governance-ratchet at 81c2474. Required pre-merge updates (each with tests):

Fork-height activation via GovernanceForkHeight/IsGovernanceForkEnforced(); nothing conditioned on an on-chain spork object.
Remove augmented admin checks on Bridge/Liquidity methods and the Bridge time-challenge tests.
Pillar-owner-only ProposeAction; enforce MaxOpenActionsPerPillar.
Propose-time destination/method allowlist and emergency-flag validation.
Remove legacy spork-signer and CommunitySporkAddress paths at the fork; only GovernanceContract can call CreateSpork/ActivateSpork post-fork.
Deposit escrow: exact-amount validation against the fixed ProposalDeposit constant (no setter, no stored deposit state), refund on Approved/NoDecision, AZ donation on Rejected.
Type-1E track: absolute yes/no conditions, immediate execution, early-reject, expiry to NoDecision.
Per-round ActivePillarSnapshot, never read live at execution.
Type2ExecutionDelay: immediate round-0 execution, delayed ratchet-round sends; ExecutableAt RPC field.
Version signaling in produced momentums backing §11’s readiness metric.
GetPillarVotes RPC.
Coordinate with the Multisig ZIP: contract address, ChangeSignerSet ABI, governance-caller authorization, shared fork height, §6 requirements.
Open as an upstream PR; independent review confirming no Bridge/Liquidity authorization change survives.

Security Considerations

Narrow attack surface. Governance cannot touch Bridge, Liquidity, or Token state. A captured vote can at worst create/activate a spork (which still requires Pillars to run matching binaries) or rotate the Multisig signer set (visible from propose time).
Sole spork authority. A defect in GovernanceContract could stall future upgrades. Mitigations: battle-tested pillar-voting machinery, lifecycle tests, and a coordinated hard fork as the last-resort recovery path.
Emergency-track abuse. Type-1E’s absolute threshold cannot pass quietly. Residual risk is panic rubber-stamping; the 7-day window and early-reject condition give the No side a real veto path.
Malicious signer rotation. A >50% coalition could install a hostile signer set in round 0. Mitigations: the Multisig holds no funds and no un-timelocked fund-equivalent methods (§6), rotation is visible from propose time, and the same path rotates signers back. Low-turnout capture is bounded by the >33% floor and the 72h ratchet-round delay.
Hard-fork coordination risk. No adoption threshold at the height means chain-split risk — deliberate, since a gate recreates paralysis-by-absence. The height is only scheduled after the ≥66% signaling criterion (§11); worst case, non-upgraded nodes continue a minority chain until upgrading.
Proposer gating. Pillar-only proposing concentrates agenda-setting in Pillar owners — intentional, as the network’s accountable identities; anyone can route a proposal through a willing Pillar. The registry check uses the frontier momentum, so a Pillar disbanding mid-vote does not invalidate its in-flight action. The open-action cap bounds vote-fatigue spam.
Deposit as censorship lever. Eliminated: the deposit is a protocol constant with no setter — no party can reprice proposing, including the Multisig repricing its own removal. Changing the constant requires a Pillar-approved protocol upgrade.
Registry churn / late-round capture. Thresholds use the round-start ActivePillarSnapshot, so churn cannot move a live round’s bar. Late-round minority capture is mitigated by floors, rising directional thresholds, fresh vote ids per round, the ratchet-round delay, and terminal NoDecision instead of unbounded decay.
Replay / idle execution / storage. Id = sendBlock.Hash binds actions to a momentum chain. ExecuteAction is permissionless, so stalled execution cannot block governance (a delayed Type-2 rotation needs one post-delay call from any address). Actions are not garbage-collected; a follow-up ZIP MAY prune expired-and-unexecuted actions.
Non-atomic target execution. ExecuteAction marks Approved before the destination processes the send; if the destination rejects, the action stays terminal and cannot be retried. Approval is authorization to send, not proof of effect. (The deposit refund settles on approval regardless.)
Multisig ZIP dependency. Operational-security claims belong to the Multisig ZIP, which this ZIP binds to normative minimums (§6) and a shared activation height (§2), guaranteeing Pillars an on-chain path to replace the signer set under any activation ordering.

Changelog

Incorporates community review: the Multisig dependency is pinned (shared fork height, normative interface); a Type-1E emergency spork track is added (7 days, Yes from >66% of all active Pillars); the Type-2 ratchet floor rises >25%->>33% with a 72h delay on ratchet-round rotations; NoDecision now refunds the deposit; per-round Pillar snapshots, re-vote semantics, a 2-open-actions cap, and a measurable fork-height readiness signal are specified; and signer-set legitimacy is assigned to the Pillar vote rather than a nomination filter.

Latest revision — fixed deposit. The proposal deposit is now a fixed protocol constant of 100 ZNN for all action types. SetProposalDeposit, the [10, 1,000] ZNN bounds, the Type-2 pricing exemption, and the GetProposalDeposit RPC are removed. Rationale: Pillar-only proposing plus the 2-open-actions cap already bound spam, so the adjustment lever added attack surface (deposit-as-censorship, and the only Multisig-to-governance authorization edge) without benefit; the deposit can now change only by Pillar-approved protocol upgrade.

Copyright

This ZIP is licensed under the GNU General Public License v3.0.