Tooling WG · Ship the on-chain governance app (Consultation v2)

The DAO needs its own governance rails rather than a Foundation-run tool. Consultation v2 is a decentralized platform – a TanStack Start dApp for creating/voting/viewing proposals, a Node.js vote collector that tallies from on-ledger data, and Scrypto components holding governance state.

Where it stands (2 August 2026)

Consultation v2 is deployed on mainnet, which closes the last of the three shipping deliverables below. The running dApp at consultation.mountain-top.live declares NETWORK_ID: "1" and the dApp definition account account_rdx12y8wqqgpjndcns9m94tjyhmfyx3hujf5snqqqjmu86vrcvg8zsx88y, which at epoch 331326 held 99 of the 100 units of RCV2 (RadixConsultationV2) – a resource of fixed supply whose mint, burn, freeze and recall rules are all deny_all and locked, so the set of those units can never be enlarged.

It is also in real use rather than merely deployed. The platform carried the two Temperature Checks the Radix Accountability Council put to the community on 25 July 2026 – TC 4, Daffy's continuation of Stokenet operations, and TC 5, Timan's proposal to move the Radix website off Webflow – and when both passed, the Council announced on 28 July that they had been lifted to the DAO's first binding, XRD-weighted governance proposals, Proposal 1 and Proposal 2. A sixth temperature check, on registering Radix in the CAIP namespaces registry and the x402 payment standard, opened on 1 August.

A second instance, for the DAO (4 August 2026)

The deployment described above is the Foundation's. On 4 August 2026 Daffy set out the split: the Mountaintop-hosted app stays dedicated to Radix Foundation proposals and has to keep running until the Foundation is wound down, since the Foundation may still use it to record decisions. In parallel a second instance, dedicated to the Radix DAO alone, is being stood up on a clean slate – extended by Timan to directly support the proposal types and the elections the DAO needs to run. Elections are the capability the Foundation instance never had, and the one the permanent RAC election has been waiting on.

The new instance's first job is the Constitutional Proposal, due within four weeks of that announcement at 10% quorum and a 66% YES threshold. Asked in the same thread whether staked XRD would count, Timan confirmed that XRD staked to validators counts toward voting power, as does XRD held inside LP tokens on the popular DEXs, on a basis he described as similar to what counted for the Radix airdrop – with an overview screen planned inside the dApp so holders can check their own weight. Meanwhile the sixth temperature check on the Foundation instance, covering CAIP namespace and x402 registration, reached quorum on 3 August and its author began submitting the CAIP namespaces pull request.

What is still outstanding is the backlog: delegation – tracked separately on the delegation & bot card – plus the parameter-admin UI, real-time updates and comments. Outcomes are published only inside the dApp, which is client-rendered and fronted by a vote collector with no public read endpoint. The ballots themselves are not hidden – they sit in a key-value store on the Governance component and can be read and weighted independently – but the tally a proposal is judged on is the operator’s, and it is announced off-ledger.

Deliverables

• Ship the Consultation dApp (create / vote / view) on mainnet.
• Ship the vote-collector CLI computing results from ledger state.
• Deploy the Scrypto governance components (Stokenet → Mainnet).
• Backlog: delegation UI, parameter admin UI, real-time updates, comments.

Dependencies & cross-references

• Governed by Daffy's Radix DAO framework (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo and Charter (Round 1).
• Executes the Proposal & Voting Framework and reads the Parameters Registry.
• Delegation covered in the delegation & bot card.

Sources

• Consultation v2 – Product Scope Document
• Does the DAO want to own its governance layer?

A second implementation appears (8 August 2026)

Consultation v2 is no longer the only platform being built for the DAO's votes. On 8 August 2026 OTER – an optimistic oracle building on Radix – announced and published a design disclosure for OTER XRD Governance, a voting platform built as a client of its oracle and stated to be releasing within the week alongside an independent verifier and a full technical document.

It is deliberately not a competing process: the disclosure keeps the ballot surface identical – one signature, no deposit, voting power as XRD held, staked and pooled at the snapshot, the same Temperature Check → elevation → Governance Proposal workflow, elections under Majority Judgment as the Proposal & Voting Framework specifies – and targets only what happens after voting closes. Its argument starts from a constraint that binds Consultation v2 equally and that the disclosure credits it for handling honestly: a Radix component cannot read historical state, so no platform on this ledger can tally on-chain, and the published result is therefore the operator's statement. OTER's answer is to post the tally as a bonded on-chain assertion open to challenge, recomputable by a second implementation and by a keeper anyone can run, with a settled Approve executing its own bound action after a fixed hold. The post names the framework Consultation v2 implements as the standard it measures itself against and credits it with "the pioneering work of getting DAO governance this far".

Nothing here changes this card's status. Consultation v2 is deployed, in real use, and carrying the DAO's first binding proposals; OTER XRD Governance is an announced design with no release, no code published at the time of writing, and no ledger record to check. It is recorded because the Tooling WG's question – who supplies the DAO's governance rails, and on what trust assumptions – now has more than one candidate answer.

The queue, read from the component (11 August 2026)

The platform's state is public even where its results are not. Every ballot cast on a proposal is a record in a key-value store on the Governance component, holding the voter's account and the option chosen. What the component does not hold is voting power – that has to be computed off-ledger from balances at the snapshot and then published by whoever computed it, which is the whole of the trust assumption the OTER disclosure takes aim at.

Read on 11 August 2026 at epoch 334,159, the queue stands at seven temperature checks and three proposals, and the DAO's first two binding votes are closed and unopposed. Proposal 1 (Stokenet) closed on 4 August at 06:42 UTC with 55 ballots, all Yes; Proposal 2 (website) closed two minutes later with 56, all Approve. Recomputing the voting accounts' holdings – liquid XRD plus stake units converted back at each validator's exchange rate – gives roughly 969 million XRD behind the first and 966 million behind the second, against the 671,470,000 quorum written into both. That is the same order as the fuller recomputation dated 9 August on Radix Governance, moved by two days of ordinary balance changes. Neither result has been announced.

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 elevated: proposal_count still reads 3. Nor has the DAO's own instance appeared here – the clean-slate deployment Timan is extending with elections, whose first job is the Constitutional Proposal. The successor Radix DAO Consultations component, the one the governance framework's on-chain register names, is deployed and empty; unlike this one it carries a third store for Majority Judgment elections, and its temperature-check, proposal and election counts all read zero.

The DAO's ballot box goes public, and it is empty (23 August 2026)

The clean-slate instance now has a front door. vote.radixdao.org serves the Consultation app under the dApp definition account account_rdx128965k8mhauk679vtew96ynq4k43rzd975jak4d5z6cvp0t0c6z7u0, named Radix DAO on-ledger, which claims that domain, the Radix DAO Consultations component and two badges. The DAO's own site routes holders there and nowhere else: radixdao.org/participate sends both “Start a proposal” and the voting-power explainer to that host, and names no other venue.

Read live at epoch 337,473 on 23 August 2026, the component behind that front door still holds nothing. temperature_check_count, proposal_count and majority_judgment_election_count all read 0, and the component's most recent transaction of any kind was on 12 August at 17:33 UTC, eleven days earlier. What changed on that date was its configuration rather than its contents: five GovernanceParameterSet entries were written into its parameter_sets store between 17:23 and 17:33, which is the Parameters Registry arriving on-ledger and the first thing on this ledger that consumes those values programmatically.

Who can operate it is settled and cannot be reassigned. The component's owner role requires the Consultations Admin Badge (resource_rdx1ng4c5k872hvhr379n0z0x6ht2n0guugns4jeh6mck9y28cu432xvc4, a single NFT), and the role's updater is None, so the rule is locked for the life of the component. That badge presently sits in a single-signature account, and it administers six entities: two packages and four Governance components spanning this lineage, including a staging deployment named Radix DAO Consultation v3. Everything the community cannot do itself hangs off it – elevating a temperature check to a proposal, recording a temperature check's outcome, adding, updating or retiring a parameter set, opening an election, starting its rounds, recording a tie resolution, and hiding any item from the front end. The Consultations Master Badge that the Radix Accountability Council's 2-of-3 multisig has held since 13 August is a different resource, and it is named in no role assignment on any entity on the ledger: as deployed, it controls nothing.

One gap this card recorded has closed by construction. The Foundation build was “fronted by a vote collector with no public read endpoint”; its runtime config named api-consultation.mountain-top.live as VOTE_COLLECTOR_URL, and that host now answers 404 at its root. The new build ships no collector at all – its config carries only ENV, the dApp definition and NETWORK_ID, and the only Radix network host in its bundle is the public mainnet Gateway. That removes an operator-run service from the read path. It does not remove the trust assumption the OTER disclosure names, because voting power still has to be computed off-ledger from balances at the snapshot, by whoever computes it.

Meanwhile the venue that actually ran the transition's votes has become hard to reach. The TLS certificate for consultation.mountain-top.live expired on 22 August 2026 at 13:47:56 UTC and was still expired at 11:19 UTC the next day. The host also sends Strict-Transport-Security: max-age=31536000; includeSubDomains, so for any browser that has visited it before this is not a warning with a click-through – it is a refusal, and every link to that host on this page, TC 4 through TC 6 and Proposals 1 and 2, is unreachable for those readers. The links are kept because nothing is actually gone: the host still answers 200 to a client that skips verification, and the record itself is on-ledger either way. Read at the same epoch, the Foundation instance still holds seven temperature checks and three proposals, unchanged since 11 August. On 4 August that instance was said to be staying up until the Foundation is wound down; a lapsed 90-day renewal is the first sign of what that maintenance looks like in practice.