Radix Governance

Introduction

Radix governance is the set of institutions, rules, and processes by which decisions about the Radix network and its shared resources – its treasury, intellectual property, trademarks, and core infrastructure – are made. Since 2026, Radix has been undergoing a deliberate transition from stewardship by the Radix Foundation toward ownership and governance by its community, with authority expressed through XRD-weighted voting.

This page is a durable overview of that structure. Because the specific bodies carrying out the transition – most visibly the Radix Accountability Council – are explicitly time-bound and will be succeeded, this page describes Radix governance in terms of enduring roles and phases, and points to where the latest developments are published.

The Radix Governance Map

Radix governance spans a family of legal entities and an in-progress handover from the Radix Foundation to a community-owned DAO. The map below shows who holds what today and where authority is heading.

How Radix Is Governed

Radix governance is token-weighted and non-custodial. Holders of XRD, the network's native token, vote directly on proposals – one XRD equals one vote – and voting never requires locking or transferring tokens. Instead, an on-ledger consultation application reads a snapshot of XRD balances at a set block height, so participation carries no custody risk and cannot be gamed by moving tokens after a vote opens.

In practice, decisions move through discussion and then a formal vote. Community members debate proposals on RadixTalk, the governance forum, before consultations are put on-ledger for a binding vote. Approved actions – such as spending from a shared treasury or changing governance rules – are then executed by elected representatives holding multi-signature authority. The detailed proposal-to-execution process, thresholds, and quorums are set out in the community-drafted Radix Network DAO Charter.

From Foundation to DAO: the Transition

Radix was designed from the outset to progressively decentralise. Its governance can be understood as three enduring phases, each defined by a role rather than by the individuals or bodies that occupy it at any moment:

1. Foundation stewardship. The Radix Foundation, a UK not-for-profit, and its subsidiaries built, funded, and stewarded the network, while RDX Works developed the core protocol. In January 2026 the Foundation announced its transition to community ownership and has since moved toward a maintenance-only role.
2. Transition governance. A community-elected bridge body completes two jobs: forming the DAO's legal entity and receiving the Foundation's handover of treasury, intellectual property, and operational assets. As of 2026 this role is held by the Radix Accountability Council (the "Transition RAC").
3. Permanent community governance. Once the DAO's legal entity – a Marshall Islands DAO LLC (MIDAO) – exists and the handover completes, the community elects a permanent council to steward it. This is the destination: a network owned and governed by its token holders.

Framing governance this way keeps the overview stable: as the transition body is replaced by a permanent one, only the current occupants below need updating, not the structure itself.

Governing Bodies (as of 2026)

The roles above are currently held by the following bodies:

• Radix Foundation – the outgoing steward. Registered in the UK as RADIX FOUNDATION (company 12106715), a not-for-profit limited by guarantee, whose subsidiaries issued XRD (Radix Tokens (Jersey) Ltd), publish the open-source code (Radix Publishing Ltd, a Jersey company, through its UK subsidiary Radix Publishing (UK) Limited), and hold intellectual property (Archetype Ltd). Since 10 February 2025 the group has been controlled by Radix Foundation Limited, a separate Jersey company, and the UK company has had a single director. It is winding down to a maintenance role.
• Radix Accountability Council (RAC) – the transition body: five community-elected members guiding DAO formation and the Foundation handover. This is a temporary "Transition RAC" that a permanent, elected council will succeed.
• Radix DLT DAO (RDD) – the community-owned entity being formed as a Marshall Islands DAO LLC, which will receive the Foundation's assets and become the network's permanent governance home.

Key Governance Documents

• Operating Agreement – the legally binding document that constitutes the Marshall Islands DAO LLC.
• Charter – the constitutional document capturing the community's governance principles, adopted by community vote.
• Radix Network DAO Charter – a discussion-stage governance framework on this wiki, adapted from the Aragon Network DAO Charter, that informed the transition structures.
• Radix DAO Governance repository – the open repository where the Operating Agreement and Charter were drafted, authored and maintained by community contributor Daffy. It defines a four-step founding sequence rather than a single founding vote: Constitutional Ratification (GP-PRE-1) → entity formation → the permanent RAC election (GP-ELECT-1) → the Activation Vote (GP-ACTIVATE-1), after which governance outcomes become binding and the Transition RAC sunsets. Until that sequence completes, no document in the repository is yet operative.

The On-Chain Register, checked against the ledger

Most governance documents can only be read. One can be checked: on 7 August 2026 the framework's On-Chain Identifiers & Verification Policy stopped carrying [to be recorded at deployment] placeholders and recorded the deployed mainnet addresses, then wrote the rules governing the Master Badge as "the root of governance-infrastructure control rather than a peer of the Owner Badge". The register names a governance component, a governance package, two badges, XRD as the voting-power resource, a governance platform and an official venue, each with a public verification link. The entries below were read from the ledger on 9 August 2026 at epoch 333391, re-checked on 12 August 2026 at epoch 334446, and re-read on 16 August 2026 at epoch 335598.

The component is deployed and has never been used. The recorded governance component runs blueprint Governance v1.0.0 from the package the register names, and its stored state is three key-value stores with a counter each: temperature_check_count, proposal_count and majority_judgment_election_count. All three read 0. The contract that the whole framework routes through is live on mainnet and has processed nothing — which is the correct state, since nothing in the framework is operative and the transition votes to date have run on the earlier Consultation instance.

Majority Judgment is deployed, not merely drafted. That third store exists at all, which is on-ledger corroboration for a change the repository made on 29 July 2026, when Majority Judgment became a co-equal election mechanism alongside two-stage approval. Its counting rule is stated in Proposal & Voting Framework §6.2.4: a candidate's grade is the highest one that three-fifths of the voting power cast placed them at or above, a fraction chosen to equal the approval threshold of the other mechanism so that both put the same share-of-turnout test to a candidate. The same section requires that comparison be evaluated by cross-multiplication on exact decimals and never in floating point, on the ground that an error in the last place "raises no exception and is invisible in the published tallies". OTER's independent tally verifier implements that rule the same way.

The badges are the Consultation dApp's own. Both recorded resources carry on-ledger metadata naming them for the existing voting app rather than for a new deployment: the Master Badge is the "Consultations Master Badge", the Owner Badge is the "Consultations Admin Badge", described on-ledger as "the admin badge for the DAO Voting dapp". Each is a single non-fungible. Their authority settings differ in exactly the way the policy describes:

• Master Badge – minter, burner, freezer and recaller are all deny_all, and the rules are locked. A second one cannot be minted, and the existing one cannot be burned or recalled from whoever holds it. The root of control is neither clonable nor revocable at the resource level, which is what makes the policy's custody rule — held in the multi-signature treasury account, never used to perform an elevation — the whole of the control.
• Owner Badge – minter, burner and recaller are its owner role and its rules are not locked. The mint, recall and invalidate capability the policy attributes to the Master Badge is therefore real at the resource level, and so is the hazard the policy names: a recalled badge disables the elevation pipeline, and a freshly minted one confers elevation authority on a holder bound by no mandate.

The venue entry was corrected, and the last placeholder filled. When this section was first written the register recorded the Official Venue as https://www.radixdao.org – a hostname with no DNS record, while the apex radixdao.org resolved and served. On 11 August 2026 the policy dropped the www prefix so that "the recorded identifier matches the live location", and the same commit replaced the register's last [to be recorded at deployment] placeholder with the deployed primary multi-signature treasury account. Recording an address invites the check that a document cannot: the two paragraphs below are that check.

The treasury account holds 200 XRD, and now holds the Master Badge. Re-read on 16 August 2026 at epoch 335598, the recorded primary multi-signature treasury account held 200 XRD and one non-fungible, the Master Badge, which arrived on 13 August; the paragraph below traces it. Its first two transactions are dated 10 August 2026. Its owner rule is a CountOf(2) over three Ed25519 signature badges – a 2-of-3 multi-signature, and exactly the threshold the framework specifies for this phase: 2-of-3 for ordinary actions with the three Transition RAC members as the initial signers, rising to 3-of-5 standard and 4-of-5 high-risk on the Activation Date (DAO Parameters §6A; On-Chain Identifiers §6). The deployment therefore matches the document. What it does not yet hold is a treasury: the Foundation's handover of assets has not arrived at this address, and nothing about the balance is disclosed anywhere the address is not.

The Master Badge moved into it on 13 August, a day after this section said it had not. The policy's custody rule for the Master Badge is specific – it "is held in the primary multi-signature treasury account recorded at §5, not by any natural person", so that it "cannot be exercised without a signing quorum", and that quorum is also what makes the badge-compromise backstop operable. Until 13 August 2026 the badge sat in a single-signature account carrying the on-ledger name Astrolescent. At 15:24:19 UTC that day a single transaction withdrew the Consultations Master Badge #1# from that account and deposited it into the treasury account, where a re-read on 16 August at epoch 335598 found it. The custody rule is now satisfied on the ledger before it is in force on paper: the policy still sits in pending/ awaiting ratification, so the move is the holder's own act rather than an obligation anyone can enforce.

The Owner Badge did not move. It remains in the unnamed account that has held it throughout, secured by a single signature rather than a quorum. That is the badge whose minter, burner and recaller are its owner role with the rules unlocked, so it is also the badge where one key carries the hazard the policy names: a recalled badge disables the elevation pipeline, and a freshly minted one confers elevation authority on a holder bound by no mandate. The badge that moved into the quorum is the one whose resource rules are locked; the one still under a single key is the one whose are not.

None of this is yet in force. The policy sits in the repository's pending/ directory with the rest of the framework, awaiting the ratification vote that opens the founding sequence described above.

The First Governance Proposals (July–August 2026)

The two-stage route a proposal takes during the transition – a Temperature Check to gauge support, then a binding Governance Proposal – was exercised for the first time in late July 2026. The Radix Accountability Council opened two Temperature Checks on 25 July: one from Daffy asking the Foundation to fund the community-run Stokenet operation it had handed over, and one from Timan on the Radix website. On 28 July the RAC confirmed both had passed and been lifted to Governance Proposals, opened for XRD-weighted voting at proposal 1 (Stokenet) and proposal 2 (website).

Both closed on 4 August 2026, and both closed unopposed. Read from the Governance component on 11 August, the Stokenet proposal carries 55 ballots and the website proposal 56, and not one of them is a No. The weight behind the voting accounts clears the 671,470,000 XRD quorum written into each by roughly 40%; the arithmetic, and the reason a liquid-only count gets it wrong, is set out on Daffy's page.

Both are pre-activation votes: they signal community will to the Foundation rather than binding a DAO that does not yet legally act. That distinction is the practical shape of the transition period – the community votes, and an entity that is still winding down executes. A week past the deadline neither outcome had been published. The component records ballots, not results, so the tally a proposal is judged on is computed off-ledger and announced by whoever computed it; the RAC's channel has posted nothing since the 28 July elevation. The consultation behind them has also stalled: Temperature Check 6, on registering Radix in the CAIP namespaces registry and the x402 payment standard, closed on 6 August with 58 votes and has not been lifted to a proposal, and the component's proposal_count still reads 3.

Execution began without any result being published (18 August 2026). Fourteen days past the deadline no tally for either proposal has been announced, by the Council or by anyone else. What arrived instead was the work. At 07:20 UTC the contributor carrying the website workstream told the main channel they were meeting that day about the migration, "per the approved proposal" — the first public treatment of Governance Proposal 2 as carried. Three and a half hours later they reported the site being moved off its static export onto an Astro site hosted on Cloudflare, and by midday that the first generation attempt had produced a new design instead of a conversion and was being redone. That correction is the substantive part: Proposal 2 approved preservation of the existing site, and a new design is what the separate, unvoted website RFC proposes. During the transition, then, the step that carries a proposal into effect is not an announcement. It is somebody starting.

The voting venue has moved to the DAO's own domain, and it is a different dApp. The DAO's participation page now directs voters to vote.radixdao.org, which serves the Consultation application under the radixdao.org venue the on-chain register names. It is not the same deployment as the instance that ran the first three votes. Each site declares its dApp definition in the runtime config it serves, and read from the ledger on 18 August 2026 at epoch 336079 the two differ: the new site declares account_rdx128965k8…, named Radix DAO on-ledger, while consultation.mountain-top.live declares account_rdx12y8wqqg…, named Radix Consultation V2 and described as "Governance on Radix, by the Radix community". Every proposal and temperature-check link on this page points at the older one. Which deployment runs the Charter ratification — the first binding vote the DAO will hold — is an open question, and the answer decides where the record of it lives.

The new venue also publishes, at an address the register names, the rule any tally rests on. Voting power is the XRD behind an account "wherever in the network you have deployed it": liquid XRD, validator LSUs, LSULP and eligible DEX liquidity positions all count, for the XRD underneath them, measured at a snapshot taken when each vote opens. Liquid staking units are excluded from the register's address table by design, since each validator mints its own, and are converted to their XRD equivalent at that snapshot. This is why a quorum recomputed from liquid balances alone reads far short of the real one — most of the weight behind a Radix voter is staked, not sitting in an account.

Staying Informed

Governance moves quickly during the transition. To follow the organizational progress of Radix:

• Live updates – the community governance channel. Currently the Radix Accountability Council's Telegram, where the body stewarding the transition posts its updates first. This is the single best place to watch organizational progress as it happens.
• Consultations and votes. The governance category on RadixTalk, where proposals are discussed and on-ledger votes are announced.
• Official announcements. The Radix blog, for Foundation-level announcements – becoming less central as the Foundation winds down.

When the transition body changes, the primary channel may move with it; this page tracks the current one.

External Links

• Radix Accountability Council – Telegram
• RadixTalk – Governance
• 2026 Strategy: The Next Chapter of Radix – Radix Blog
• Radix DAO Governance repository
• How DAOs fail: participation-weighted governance and common failure modes (Caper wiki)