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
- Related prior art: on-chain proposal execution in Caper (proposal → vote → automatic execution).
- Governed by the operative repository
RadixDAO/governance-framework, which moved off a personal account on 29 August 2026; the olderShadaffy/radix-daois the reference library of unactivated drafts, last pushed 7 May 2026. See see the Governance Framework Reference Repo and Charter (Round 1). - Parameters live in the DAO Parameters Registry.
- Executed through the on-chain governance app.
- The same stages in other DAOs, from forum discussion and temperature check through the vote to a timelock before execution: The DAO proposal lifecycle; and the trade-offs in setting the quorum and approval thresholds this framework fixes for Radix: Quorum and threshold design. Both are in the DAO governance reference on caper.network.
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.
The phase with no closing date now has a condition (10 September 2026)
When the Transition RAC removed the seven-day limit on 2 September it gave a reason and no condition: the ledger was stopped, so the phase would run for as long as its needed
. Eight days later the condition exists. At 18:43 UTC on 9 September 2026, under the heading LEGAL/DAO & Governance, projectShift wrote in the council's own channel that When we have a set date for mainnet’s liveness recovery, we’ll close down Discussion phase and plan TC, for the ratification process.
The precision is the part that matters. The trigger is not the restart. It is the setting of a date for the restart, which can happen while the network is still stopped, so the Temperature Check on the twenty-one documents can be planned before a single round is committed. The two conditions the 2 September extension implied, a working network and a finished discussion, have been replaced by one condition that is neither.
No date is set yet
Read at 15:08 UTC on 10 September 2026, the Gateway status endpoint returns state version 557,840,622, epoch 339,896, round 102, which is 233 hours and 49 minutes without a committed round, and /state/validators/list answers HTTP 500 counting the same gap at 841,756 seconds behind. Nine hours before that reading, at 09:13:53 UTC, the same author posted the council's other instruction: Although final versions has been made available, pls do not update your nodes yet. Further instructions and support will be shared later today or tmrw latest.
A body that has not yet told operators to install the fix has not set a restart date, so the condition it named on 9 September has not been met.
The condition is not in the governance record
It was announced in a chat channel, and twelve days into the phase it is in none of the three places the framework points a voter at.
- The anchor topic the council designated for the Discussion phase carries its first post last edited at 13:58 UTC on 2 September. That post still reads that the phase stays open
regardless of the initially set period
, and it names no condition for closing it. The topic has had no post of any kind since 10:03 UTC on 7 September, three days before this reading. - The Official Venue’s notices feed, read at 15:08 UTC on 10 September, holds the same two items it has held since 29 August: the Transition RAC certificate details and the decisions enabling the ratification process. Its Process notices category answers
No items of this type have been published yet.
The venue the framework designates for official acts has recorded neither the phase's opening, nor its extension, nor its closing condition. - The DAO’s own repository was last pushed at 13:28 UTC on 27 August, before the phase opened. The amendments of 6 September to eight of the ratifiable documents are still only in the personal repository, pushed 21:30:49 UTC on 6 September and unchanged since. The text a Temperature Check would be called on is not the text the DAO's repository holds.
What follows is a scheduling fact rather than a criticism of it. The Discussion phase can now end on a decision taken in a validator coordination channel, and a reader watching the forum, the venue or the repository for the signal will not see it there.
