GP-PRE-1 — Constitutional Ratification of the Governance Framework
Discussion topic. This post explains the ratification vote and invites scrutiny before it opens.
This post is explanatory and has no legal force. The operative text — the thing you actually vote on and the thing the ledger records — is the ballot version of GP-PRE-1. Where this post and the ballot text differ, the ballot text governs. Nothing said here adds to, subtracts from, or
qualifies what is ratified.
|
|
| Proposal |
GP-PRE-1 · Constitutional · Major |
| Author |
Transition Radix Accountability Council |
| Voting system |
Consultation V3 — the community’s own on-chain governance system |
| Thresholds |
≥ 66% YES · ≥ 10% quorum · ≥ 3.5% affirmative floor |
|
|
The short version
The community has spent an extended drafting and review period building a governance framework: a Charter, and twenty operational policies underneath it. GP-PRE-1 asks the community to ratify that framework — to say, formally and on-chain, “this is our rulebook.”
It does three things and no more:
- it fixes exactly which documents, at exactly which versions, are the framework;
- it satisfies Activation Condition 6(b) of the Operating Agreement;
- it means the Transition RAC forms the Company already carrying a community-ratified rulebook.
It does not form the legal entity, and it does not activate the DAO. Those are separate acts, and the second of them is a separate vote you will get to cast. More on this below, because it is the point most likely to be misread.
Where this sits in the sequence
[ Founding mandate — ALREADY GIVEN by the formation of the current RAC; no vote here ]
│
▶ 1. GP-PRE-1 Constitutional ratification of the framework ← THIS PROPOSAL (pre-formation)
│ Operating Agreement Schedule 5, condition 6
2. Formation — Transition RAC files the Certificate of Formation + Operating Agreement
│ Company exists, MEMBER-MANAGED; Advisory Governance Period begins
3. GP-ELECT-1 Permanent RAC election + seating (Schedule 5, condition 7)
│
4. GP-ACTIVATE-1 Activation Vote → Activation Date → Algorithmically Governed
Radix DAO LLC does not yet legally exist. This vote happens before formation, on the community’s own governance system, using software donated by the Founding Transferor. The community operates that system in its own right.
How this fits with forming the entity
Formation and ratification are two tracks running in parallel. The Transition RAC is preparing the
formation filing; the community is ratifying the framework. Neither waits on the other, and a gap of
days or weeks in either direction is expected rather than a problem.
The Operating Agreement is drafted to absorb either order. If this vote concludes first, OA §1.11
treats the community’s current system as the Governance Mechanism for condition 6(b) specifically, and OA §11.1A has the Company adopt the vote — and the version of the framework it approved — on execution of the Agreement. If formation lands first, nothing breaks either: Condition 6 also requires adoption by the Transition RAC in its capacity as member-manager of the Company (limb (a)), which presupposes the Company exists. Condition 6 therefore completes after formation in either case.
The sequence that does matter comes later. The Permanent RAC election has to run on the ratified Elections & Role Governance Policy, and OA §7.1 requires it to be held after satisfaction of Condition 6. So ratification gates the election, and the election gates the Activation Vote. That is
the real dependency — not the order in which this vote and the formation filing happen to finish.
What this proposal deliberately leaves alone
This is a narrow proposal, and it is worth being explicit about what is not in it:
- The establishment mandate is not re-sought. Forming the entity, constituting the Transition RAC, the Delegate roster, the Establishment Grant — that mandate was already given by the community’s formation and approval of the current RAC. GP-PRE-1 does not revisit it and confers no new authority.
- Activation is not bundled in. Keeping ratification separate from activation is what makes the Activation Vote a real, informed sign-off later, rather than a take-it-or-leave-it vote on a
constitution nobody had read yet.
What is being ratified
The governance constitution
| Document |
Role |
| Charter |
Governance constitution of the DAO, subordinate to the Operating Agreement (Charter §13) |
The operational policy library
| Document |
Purpose |
| DAO Parameters Registry |
All numerical thresholds, durations and limits, incl. §3A activation parameters |
| Proposal & Voting Framework |
How decisions are proposed, voted on and recorded |
| Execution & Treasury Actions Policy |
How approved decisions are executed and funds moved |
| Emergency & Safeguards Policy |
Response to security events and critical failures |
| Treasury Signers Rules |
Operational rules for those executing treasury actions |
| On-Chain Identifiers & Verification Policy |
The public register of governance and treasury identifiers, and how to verify them |
| RAC Mandate |
Authority and limits of the Permanent RAC |
| Delegate Mandate |
Scope and operational rules of the Delegates and Delegated Functions |
| Conflict of Interest Policy |
Disclosure and recusal obligations for all role holders |
| Code of Conduct |
Behavioural standards for all DAO participants |
| Compliance Operations Policy |
Operational compliance practice |
| Governance Maintenance & Upgrade Framework |
Amending, versioning and classifying governance documents |
| Working Group Framework |
Establishing and operating Working Groups |
| Elections & Role Governance Policy |
Election procedures, including the Permanent RAC election |
| Governance Continuity Framework |
Continuity and fallback procedures |
| Dispute Resolution & Arbitration Policy |
Dispute handling, Tier 1 under OA Article XIV |
| Contributor Compensation Policy |
Cost models, payment procedures, compensation governance |
| Contributor Onboarding and Offboarding |
Onboarding contributors and handling role transitions |
| Source Code Stewardship Policy |
Managing, reviewing and releasing source code and software assets |
| Open Source & Intellectual Property Policy |
IP ownership, licensing and contribution requirements |
The Roles Registry is a navigation aid that maps roles to the documents above. It is not ratified
and is not a source of rules. The same is true of the plain-language reading guides.
How to check what you are actually voting on
This matters more than it sounds. What gets ratified is not “the framework” in the abstract — it is
twenty-one specific files at twenty-one specific content hashes, listed in the ballot text.
Before formation each document is versioned, rendered to PDF and signed. The SHA-256 of that signed PDF is what appears in the ballot manifest, and it is the definitive identifier of the ratified
version. If a byte changes, the hash changes.
To verify:
- Download the signed PDF from the Official Venue.
- Compute its SHA-256.
- Confirm it matches the hash for that document in the ballot manifest.
If any hash does not match, say so in this thread before the vote opens. Please also compare the .mdsources in the governance repository against the signed PDFs — this is exactly the kind of check the discussion period exists for.
Note which one counts. What is ratified is the signed PDF, and only the PDF is hashed in the
manifest. The .md in the repository is the working source it was rendered from: it stays editable
after the vote, nothing in the manifest pins it, and where the two differ the signed PDF governs. Read the repository for convenience, but check the PDF before relying on a provision.
The signing certificate
All twenty-one PDFs are signed with one certificate, self-signed by the Transition RAC. Its serial number, SHA-1 thumbprint and SHA-256 fingerprint are recorded in §2A of the ballot text. Your PDF reader will show you these when you open a signed document and inspect the signature.
Self-signed means no certificate authority vouches that the key belongs to the Transition RAC. So verifying a signature proves two things — the document was signed by the same key as the rest of the set, and it has not been altered since signing — but it does not, on its own, prove whose key it is. There is no external authority to ask.
Recording the fingerprint in the ballot is what closes that gap. The certificate is ratified along
with the manifest, so once the vote passes, that key is the Transition RAC’s signing key because the community said so. The vote is the trust anchor a certificate authority would otherwise provide. This is why §2A is part of what you are voting on and not a footnote.
Two practical points:
- Check the SHA-256 fingerprint, not the thumbprint. The serial number and thumbprint are there because readers and certificate stores display them, and they make the certificate easy to spot. SHA-1 is no longer collision-resistant, so treat the thumbprint as a label and the SHA-256 fingerprint as the check.
- The hash in the manifest still governs. The certificate confirms authorship and integrity
without making you recompute anything, but it does not displace §2. A file whose SHA-256 matches the manifest but whose signature is missing, invalid, or from a different certificate is not the ratified version — please flag it.
What happens if it passes
- The listed documents become the community-ratified governance framework, satisfying Activation Condition 6(b).
- The Transition RAC adopts the same framework by unanimous written resolution in connection with formation — condition 6(a) — and publishes it to the Official Venue.
- The Transition RAC proceeds, under its existing mandate, to form the Company.
- The Advisory Governance Period begins at formation.
- GP-ELECT-1 can then run on the ratified Elections & Role Governance Policy.
What still is not true after it passes
- The Company is member-managed (OA §8.1). Community governance outcomes are advisory (OA §§5.8–5.9; Charter §4A).
- Only three community acts are binding in this period: this ratification, the Permanent RAC
election, and the Activation Vote.
- Binding algorithmic governance begins on the Activation Date, when GP-ACTIVATE-1 passes (OA §§5.7, 8.8) — not before.
If you want the DAO to be genuinely community-governed, GP-PRE-1 is a necessary step toward that, but GP-ACTIVATE-1 is the vote that does it.
Thresholds, and what ABSTAIN actually does
Constitutional thresholds apply (DAO Parameters §3A.1):
| Test |
Requirement |
| Quorum |
≥ 10% of eligible voting power participates |
| Approval |
≥ 66% YES of Decisive Votes |
| Minimum Affirmative Support |
YES votes ≥ 3.5% of eligible voting power in their own right (§3.3A) |
- YES — ratify and adopt the Charter and policy library as the community’s constitutional framework.
- NO — do not ratify. The framework is not adopted and the standard cooldown applies before
resubmission.
- ABSTAIN — counts toward the 10% quorum, is excluded from the 66% approval calculation, and does not count toward the affirmative floor. It is a way to help the vote be valid without taking a side.
The result is determined arithmetically from the record of the voting system and published by the
persons named as Transition RAC in Operating Agreement Schedule 1. That publication is ministerial — it reports what the tallies produce. It is not a discretionary decision, and anyone can verify it from the same public record (Proposal & Voting Framework §6.5).
Risks and trade-offs
| Risk |
Likelihood |
Impact |
Mitigation |
| The vote fails the 66% / 10% thresholds |
Medium |
High |
This discussion period exists to surface objections early enough to address them before the binding vote opens |
| The community conflates ratification with activation |
Medium |
Medium |
Stated expressly in the ballot text and throughout this post; the sequence diagram is published prominently |
| The framework needs changes after ratification |
Low |
Medium |
Post-ratification changes follow the Governance Maintenance & Upgrade Framework, and for entrenched provisions the OA §12.2 thresholds |
Conflict of interest
The Transition RAC authored the framework it is asking the community to ratify. That is an inherent founding conflict and we are stating it plainly rather than burying it.
What mitigates it: this public discussion period; the community’s ability to reject the proposal; and
the fact that GP-PRE-1 confers no new authority on the RAC — the establishment mandate is
pre-existing and entirely unchanged by this vote.
What we are asking of this discussion
Concretely, before the vote opens:
- Verify the hashes against the signed PDFs and flag any mismatch.
- Read the documents that will bind you — the Charter, the DAO Parameters Registry, and the Proposal & Voting Framework are the highest-leverage three.
- Challenge the sequencing if you think ratifying before formation is the wrong call.
- Point at anything that reads as authority the RAC should not have. That is the objection this framework most needs tested, and now is when it is cheapest to fix.
Substantive objections raised here can be addressed before the binding vote. Once ratified, changes go through the amendment process instead — slower, and for entrenched provisions, considerably harder.
Where to check the source
| Source |
Relevance |
legal/operating-agreement.md |
Schedule 5 condition 6; §11.1A, §11.1–§11.5; §§5.7–5.9, §8.1 |
constitutional/charter.md |
§4A (Activation & Advisory Governance Period); §12–§13 |
parameters/dao-parameters-registry.md |
§3A.1 ratification thresholds; §3.3A affirmative floor |
governance/proposal-and-voting-framework.md |
§5 proposal requirements; §6.5 result determination |
| Ballot text of GP-PRE-1 |
The operative proposal — what is actually voted on and recorded |
