RADIX WikiRADIX Wiki

The three-stage improvement process – RFC → Temp Check → RFP – reached rough consensus (58 for, 1 against) in the RDD structure thread. The DAO must lock the mechanics: who can initiate each stage, XRD/LSU thresholds, voting windows, quorums, and approval thresholds.

Deliverables, as the card set them in July 2026

  • Ratify stage gates: RFC (open) → TC (initiator ≥0.5M LSU-XRD, 100M quorum) → RFP (initiator ≥2M XRD, 500M quorum).
  • Settle whether TCs auto-graduate to RFP or require RAC to promote them.
  • Fix voting windows (proposed 7-day standard) and the no-confidence override (75% / 1.5B XRD quorum).
  • Wire the framework to the on-chain governance app so votes are computed from ledger state.

Dependencies & cross-references

Sources

Settled by the framework now under ratification

Every deliverable above has an answer, and the answer is a document the community is currently being asked to adopt. Proposal & Voting Framework v1.0.0, dated 27 August 2026, is one of the twenty-one documents in the GP-PRE-1 ratification manifest, and has been in its Discussion phase since 30 August 2026. That phase was announced with a seven-day limit that would have closed it on 6 September; at 13:49 UTC on 2 September 2026 the Transition RAC removed the limit, on the ground that the halted network offers no technical conditions to move to a Temperature Check or a ballot, and the discussion now runs for as long as it is needed. It is not in force. It is also the most consequential of the three documents the Transition RAC named as highest-leverage for a reader to check before voting, alongside the Charter and the DAO Parameters Registry.

The shape of the answer is that the numbers left the framework. Almost nothing quantitative lives in the Proposal & Voting Framework itself: it defines the pipeline and the vote types, and every threshold, quorum and duration is a cross-reference into the Parameters Registry, which can be amended without touching the framework text.

What changed against the July framing

  • The initiator thresholds are gone entirely. §2 gives any Governance Participant the right to submit a proposal with "no minimum holding, prior registration, or approval from any DAO body", flowing from Charter §4.1 sovereignty. The 0.5M LSU-XRD and 2M XRD gates above have no successor.
  • Quorums are percentages of eligible voting power, not absolute XRD. Parameters §3.2: Constitutional 10%, Governance Process 7%, Treasury & Budget 7%, Executable 5%, Temperature Check 3% — measured as participation, YES + NO + ABSTAIN. Approval is the YES share of decisive votes, excluding ABSTAIN (§3.3): 66% Constitutional, 60% Governance Process, 50% for the rest.
  • A third test was added that the July design had no equivalent of. Parameters §3.3A sets a Minimum Affirmative Support floor — YES power as a share of the whole electorate, independent of quorum: 3.5% Constitutional, 2% Governance Process, 1.5% Treasury & Budget, 1% Executable. It exists because ABSTAIN counts toward quorum but not toward approval, so without it a proposal could be carried over quorum largely by abstentions and then decided by a very small affirmative base. Each figure is set at roughly half the YES share a zero-abstention vote clearing its own quorum at its own approval threshold would produce.
  • Temperature Checks neither auto-graduate nor sit at the RAC's discretion. §3.3 makes elevation a duty of the Governance Operator, exercised through the Owner Badge, within the TC Elevation Window — five business days (Parameters §3.1). Miss it without recording documented grounds with the RAC and the elevation backstop in the Governance Continuity Framework §4.2A fires.
  • The no-confidence override does not survive as a distinct instrument. Removal of a role holder is an ordinary Governance Process proposal — 7% quorum, ≥60% YES, subject to the §3.3A floor — and the registry states the reason for the cross-reference: unseating should cost at least what seating cost. There is no 75% / 1.5B XRD lever.
  • The 7-day voting window became a range with a discussion period in front of it. Parameters §3.1: Draft Discussion ≥5 days, Temperature Check voting 5–7 days, DAO Proposal voting 5–7 days.

What the framework demands of the voting app

The last deliverable above — wire the framework to the on-chain app so votes are computed from ledger state — is the one that is now a stated capability requirement rather than an aspiration. §6.1 fixes voting power at a snapshot taken by the system when each vote opens, not chosen by the RAC or the proposer and not alterable afterwards, with a single exception: a rerun reuses the snapshot of the round it re-runs, because the remedy a rerun offers is time and it would not be that if the electorate changed with it. The framework then says outright that a governance component unable to open a rerun against the stored snapshot of an earlier round cannot run those provisions as specified. Eligible holdings are tiered (Parameters §8A): liquid XRD and LSU converted at the redemption rate are the constitutional floor, while LSULP and DEX pool positions sit in an RAC-maintained register that can change without a constitutional amendment. See the governance app, now at Consultation V3, for the deployment this lands on.

One caveat carries across from the ratification thread and applies to every link on this card: what is ratified is the signed PDF of each document, published to the Official Venue and hashed in the manifest. The markdown cited here is the working source it was rendered from, it stays editable after the vote, and where the two differ the PDF governs.

HydrateLast updated Sep 2, 2026v2.1.06 revisionsVerified Sep 2, 2026