8.2 Proposal Lifecycle

The Proposal Lifecycle is the heartbeat of NXT governance, converting raw ideas into executable smart-contract upgrades or budget allocations through a six-stage pipeline. Each gate prevents low-quality or conflicted initiatives from slipping into on-chain law while still encouraging experimentation.

Stage 1: Idea Incubation Anyone may open a “Request for Comment” (RFC) thread in the governance forum. An RFC must include a one-paragraph summary, a problem statement, and at least one proposed solution vector. No code or legal draft is required at this stage. The intention is to gauge community interest and solicit early feedback without burdening authors with premature detail. An RFC remains open for a minimum of seven days or until it collects at least ten unique commentary posts—whichever is longer—ensuring organic reach before further work begins.

Stage 2: Draft Specification If sentiment is positive—measured by a simple forum poll and moderator review—the author converts the RFC into an NXT Improvement Proposal (NXT-IP). This Markdown document follows a rigid template: Motivation, Backward-Compatibility Analysis, Technical Specification, Legal Impact Analysis, Risk Matrix, and Implementation Timeline. The Risk Matrix uses a 5×5 likelihood-versus-impact grid covering smart-contract, economic, regulatory, and user-experience vectors. Draft stage also requires an initial gas-cost analysis and a note confirming whether the change could trigger taxable events in major jurisdictions.

Stage 3: Expert Review & Revision Once published to the governance-proposals repository, the draft is tagged for expert review. The review cohort comprises at least one representative from each of four elected working groups—Technical, Legal, Security, and Economic-Research. Reviewers leave line-item comments on GitHub, demanding clarifications, additional tests, or alternate parameter ranges. The proposal cannot advance until it receives a minimum of one approval from each group or a governance override vote.

Stage 4: Testnet Implementation Upon multi-group sign-off, proposers deploy reference contracts or process workflows to the public testnet behind a feature flag. A two-week soak test is mandatory, during which automated bots and human testers simulate normal and adversarial behaviour. Metrics—gas usage, revert rates, exploit attempts—are logged to a public Grafana dashboard. If critical vulnerabilities surface, the proposal reverts to Draft for patching; otherwise, it graduates to Snapshot.

Stage 5: Snapshot & On-Chain Voting A block height announced at least 72 hours in advance captures token balances, freezing voting power to prevent flash-loan manipulation. Voting remains open for five to seven days depending on proposal category (longer for economic-parameter changes, shorter for UI when no contract code is touched). Votes are cast through a gas-less signature relay to lower participation friction. Quorum and approval thresholds are set by governance type: 5 % of circulating supply and simple majority for operational tweaks, 10 % supply and supermajority for treasury disbursements, and a dual-key legal-holder consent for wrapper-affecting amendments.

Stage 6: Timelocked Execution & Post-Implementation Report Approved proposals enter a thirty-six-hour timelock, during which auditors and node operators run final verification scripts. Emergency veto is possible by a qualified Security Council multisig only if an objective, on-chain check fails (e.g., contract bytecode hash differs from snapshot file). After execution, proposers must publish a Post-Implementation Report within fourteen days, measuring real-world metrics against risk matrix forecasts. Failure to submit the report locks the proposer’s wallet from initiating new proposals for one governance quarter, providing accountability for follow-through.

This lifecycle ensures that every change—trivial or monumental—moves through a gauntlet of community feedback, expert scrutiny, empirical testing, and time-buffered execution before affecting live assets.