# Consultation v2 — Product Scope Document **URL:** \ **Category:** Radix Community DAO\ **Created:** [29 January 2026 08:16 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193 "2026-01-29T08:16:48Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![xStelea](https://radixtalk.com/user_avatar/radixtalk.com/xstelea/32/1674_2.png) [@xStelea](https://radixtalk.com/u/xStelea)\ **Post date:** [29 January 2026 08:16 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/1 "2026-01-29T08:16:48Z")
# Consultation v2 — Product Scope Document ## 1. Overview **Product Name:** Consultation v2 **Purpose:** Decentralized governance platform for Radix community decision-making, replacing the Foundation-dependent v1 system before 2026 wind-down. **Components:** 1. **Consultation dApp** — TanStack Start web app for creating/voting/viewing governance items 2. **Vote Collector** — Node.js CLI for calculating vote results from on-ledger data **Core Flow:** ```dpr Anyone creates TC → Community votes For/Against → If passes (quorum + majority) → Admin promotes to RFP → Community votes on options → Winner determined ``` **Tech Stack:** - dApp: TanStack Start, Radix dApp Toolkit, PostgreSQL - Vote Collector: Node.js, Radix Gateway API, PostgreSQL - On-ledger: Scrypto components - Network: Configurable (Stokenet / Mainnet) * * * ## 2. Users & Permissions | Role | Identification | Capabilities | | --- | --- | --- | | Visitor | No wallet connected | View active votes, view results | | Voter | Wallet connected (any account) | Above + create TCs, cast votes | | Admin | Holds owner badge | Above + promote TC → RFP, update GovernanceParameters | **Authentication:** - Radix Wallet Connect via dApp Toolkit - Account-based identity **Voting Power:** - Determined by LSU holdings at voting start snapshot - LSU converted to XRD equivalent using validator redemption rates - 1 XRD equivalent = 1 voting power unit **Vote Constraints:** - One vote per account per TC/RFP - Votes are final — cannot change after casting - Must connect wallet to vote * * * ## 3. Governance Items ### 3.1 Temperature Check (TC) | Field | Description | | --- | --- | | title | Short title for the TC | | description | Full description/rationale | | vote\_options | For / Against (binary) | | attachments | Supporting files | | rfc\_url | Link to RadixTalk RFC discussion | | quorum | Min participation required (from GovernanceParameters) | | approval\_threshold | % For votes needed to pass | | max\_selections | For future RFP phase (stored for promotion) | | start | Voting start instant (snapshot taken here) | | deadline | Voting end instant | | elevated\_proposal\_id | Links to RFP if promoted (null until promoted) | **TC Lifecycle:** ```scss Created → Voting Open → Deadline Reached → → Passed (quorum met + majority For) → Can be promoted to RFP → Failed (quorum not met OR majority Against) → Archived ``` ### 3.2 Request for Proposal (RFP) | Field | Description | | --- | --- | | title | Inherited from TC | | description | Inherited from TC | | vote\_options | Multiple options (defined by admin at promotion) | | attachments | Inherited + additional from admin | | rfc\_url | Inherited from TC | | quorum | From GovernanceParameters | | approval\_threshold | % needed to win | | max\_selections | How many options voter can select (usually 1) | | start | Voting start instant (new snapshot) | | deadline | Voting end instant | | temperature\_check\_id | Links back to originating TC | **RFP Lifecycle:** ```sql Promoted from TC → Voting Open → Deadline Reached → → Winner (option with most votes if quorum met) → Executed → No quorum → Failed ``` * * * ## 4. Consultation dApp Features ### 4.1 Pages | Page | Route | Description | | --- | --- | --- | | Home | `/` | Active votes + recent results | | TC Detail | `/tc/:id` | TC info, tally, voters, vote/promote actions | | RFP Detail | `/rfp/:id` | RFP info, options tally, voters, vote action | | Create TC | `/tc/new` | Form to create new TC | ### 4.2 Home Page - **Active Votes** — Open TCs and RFPs, sorted by deadline (soonest first) - **Recent Results** — Completed votes with pass/fail, sorted by end date - Each item: title, type (TC/RFP), status, deadline, participation % ### 4.3 TC Detail Page - Header: title, description, rfc\_url link, attachments - Status: voting open/closed, time remaining - Tally: For vs Against (count + voting power) - Progress: quorum %, approval threshold - Voter list: account, vote, voting power - **Voter Action** : Vote For / Against (if connected + not voted + open) - **Admin Action** : Promote to RFP (if admin + passed + not promoted) ### 4.4 RFP Detail Page - Header: title, description, rfc\_url link, attachments - Status: voting open/closed, time remaining - Options: each option’s count + voting power - Progress: quorum % - Voter list: account, selected option(s), voting power - **Voter Action** : Select option + Submit (if connected + not voted + open) - Link to originating TC ### 4.5 Create TC Page - Form: title, description, rfc\_url, attachments, max\_selections - Submit via wallet transaction * * * ## 5. Vote Collector ### 5.1 Purpose Node.js CLI that calculates vote results by: 1. Reading votes from on-ledger governance contract state 2. Fetching LSU holdings for each voter at snapshot time 3. Converting LSU → XRD voting power via validator redemption rates 4. Storing calculated results in PostgreSQL ### 5.2 Data Flow ```scss ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ Radix Gateway │────▶│ Vote Collector │────▶│ PostgreSQL │ │ API │ │ (Node.js) │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ ``` ### 5.3 Inputs (from Radix Gateway) | Data | Source | | --- | --- | | TC/RFP details | Governance component state | | Votes | Governance component KVStore | | Voter LSU holdings | Account fungible resources at snapshot | | LSU → XRD rate | Validator component state | ### 5.4 Outputs (to PostgreSQL) | Table | Contents | | --- | --- | | `tc_results` | TC id, status, total\_for, total\_against, quorum\_met, passed | | `rfp_results` | RFP id, status, winning\_option, quorum\_met | | `voter_power` | vote\_id, account, vote\_choice, voting\_power | ### 5.5 Invocation ```bash # Calculate results for specific TC vote-collector tc # Calculate results for specific RFP vote-collector rfp ``` ### 5.6 Configuration | Env Var | Description | | --- | --- | | `NETWORK` | `stokenet` or `mainnet` | | `GATEWAY_URL` | Radix Gateway API endpoint | | `GOVERNANCE_COMPONENT` | Component address | | `DATABASE_URL` | PostgreSQL connection string | * * * ## 6. Success Criteria ### 6.1 Functional Requirements | Requirement | Acceptance | | --- | --- | | Create TC | User can submit TC via wallet transaction, appears on home page | | Vote on TC | User can cast For/Against vote, vote recorded on-ledger | | TC Results | Vote Collector calculates correct totals with LSU-weighted power | | Promote TC | Admin can promote passed TC to RFP with defined options | | Vote on RFP | User can select option, vote recorded on-ledger | | RFP Results | Vote Collector calculates correct totals with LSU-weighted power | | View Results | dApp displays accurate tallies from PostgreSQL | ### 6.2 Non-Functional Requirements | Requirement | Target | | --- | --- | | Network support | Stokenet and Mainnet via config | | Wallet support | Radix Wallet via dApp Toolkit | | Data accuracy | Vote power matches on-ledger LSU at snapshot | | Transparency | All votes publicly visible with voter + power | * * * ## 7. Out of Scope (v1) | Item | Reason | | --- | --- | | Vote delegation | Exists in contract, not exposed in dApp v1 | | Admin page for GovernanceParameters | Managed outside dApp | | Real-time vote updates | On-demand calculation only | | Vote change/revocation | Votes are final by design | | Comment/discussion on votes | Use rfc\_url to RadixTalk instead | * * * ## 8. Open Questions | Question | Impact | Notes | | --- | --- | --- | | Voting power mechanism | Core calculation | Currently assuming LSU → XRD | | Spam protection for TCs | UX / governance quality | Anyone can create — may need lock amount or rate limiting later | | Attachment storage | dApp | Where do TC/RFP attachments live? On-ledger (expensive) or off-chain ( S3)? | ---
**Author:** ![djtebel](https://radixtalk.com/user_avatar/radixtalk.com/djtebel/32/1602_2.png) [@djtebel](https://radixtalk.com/u/djtebel)\ **Post date:** [29 January 2026 09:29 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/2 "2026-01-29T09:29:56Z")
> [@xStelea](#): > > For / Against (binary) Looking good xStelea! May I propose an Abstain option? It lets voters signal participation without forcing a For/Against position, which reduces noisy votes and makes quorum a better measure of engagement imo. I would say: • Abstain counts toward quorum • Abstain does not count toward approval threshold / majority To prevent Abstain votes making it harder to pass a TC, while still measuring engagement on a TC. ---
**Author:** ![projectShift](https://radixtalk.com/user_avatar/radixtalk.com/projectshift/32/1704_2.png) [@projectShift](https://radixtalk.com/u/projectShift)\ **Post date:** [29 January 2026 11:09 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/3 "2026-01-29T11:09:11Z")
We still don’t have an official community-votes decisions on what should be used for voting power. I believe Adam said FND will put that up for voting very soon - next consultation, I believe. It’s highly probable that both XRD and Validator Staking LSUs will both be selected as valid voting power assets, so in that sense, the wording in the current proposal might become inadequate after we have that result … and you may need to revise parts of the code to properly account for what gets selected? In any case, if the Validator Staking LSUs do become a valid voting power asset - they need to be filtered against valid running validators in the set, in my view. The reasoning behind using these LSUs is related to them representing a form of commitment to Radix, a sort of proof-of-support. That is only true if the stake is being actively used, i.e., in the validator set that’s participating in consensus. That might pose a challenge, since we’ll need to capture that for snapshot time and it can change meanwhile. I believe that the snapshot “module” needs to include that information, so that the calculation module is able to do the filtering. It’s all perhaps just code and techy, but I believe it should be reflected enough in the proposal. ---
**Author:** ![Leonets](https://radixtalk.com/user_avatar/radixtalk.com/leonets/32/1405_2.png) [@Leonets](https://radixtalk.com/u/Leonets)\ **Post date:** [29 January 2026 11:09 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/4 "2026-01-29T11:09:46Z")
> [@xStelea](#): > > votes from on-ledger governance contract state hello, who and how can decide the | approval\_threshold | % For votes needed to pass ? | | --- | --- | what is the schedule of the LSU counter from start to end ? once a day , once an hour ? ---
**Author:** ![xStelea](https://radixtalk.com/user_avatar/radixtalk.com/xstelea/32/1674_2.png) [@xStelea](https://radixtalk.com/u/xStelea)\ **Post date:** [29 January 2026 11:24 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/5 "2026-01-29T11:24:49Z")
Sounds like a good addition. @octo should be an easy add to the blueprint ---
**Author:** ![xStelea](https://radixtalk.com/user_avatar/radixtalk.com/xstelea/32/1674_2.png) [@xStelea](https://radixtalk.com/u/xStelea)\ **Post date:** [29 January 2026 11:30 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/6 "2026-01-29T11:30:13Z")
The tokens used towards calculating vote power is extendable. I used LSU since it was mentioned in previous discussions. Aiming to get a scoped version of the dApp open sourced and iterative on further improvements. ---
**Author:** ![xStelea](https://radixtalk.com/user_avatar/radixtalk.com/xstelea/32/1674_2.png) [@xStelea](https://radixtalk.com/u/xStelea)\ **Post date:** [29 January 2026 12:09 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/7 "2026-01-29T12:09:42Z")
> approval\_threshold % For votes needed to pass ? It’s decided by the holder of the owner badge. > > what is the schedule of the LSU counter from start to end ? once a day , once an hour ? > Manually triggered in first version ---
**Author:** ![Magal36](https://radixtalk.com/user_avatar/radixtalk.com/magal36/32/1762_2.png) [@Magal36](https://radixtalk.com/u/Magal36)\ **Post date:** [29 January 2026 12:15 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/8 "2026-01-29T12:15:50Z")
That’s not difficult to do at the snapshot time I believe, just get the active validator set LSUs. People who want to keep engaged in voting have to be sure their validator doesn’t fall out of the set right before a snapshot, and voting power is set at snapshot time ---
**Author:** ![projectShift](https://radixtalk.com/user_avatar/radixtalk.com/projectshift/32/1704_2.png) [@projectShift](https://radixtalk.com/u/projectShift)\ **Post date:** [29 January 2026 12:22 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/9 "2026-01-29T12:22:10Z")
Btw … consultation is now open from FND regarding what assets should be considered as voting power. I believe we’ll mostly use whatever comes out of this to do our first community-run consultation … that will probably be to confirm that exact same 🙂 ---
**Author:** ![Vlad](https://radixtalk.com/user_avatar/radixtalk.com/vlad/32/612_2.png) [@Vlad](https://radixtalk.com/u/Vlad)\ **Post date:** [29 January 2026 12:58 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/10 "2026-01-29T12:58:28Z")
I made a mockup based on what Stelea suggested in the initial post. It might not be fully accurate but it’s a start and probably much easier to understand than reading so much text. At-least for me was. You can find the code here, although i will probably update with new versions, but feel free to grab or modify. I used Google AI Studio to build, so you can copy and modify also yourself in Google studio. ![Screenshot 2026-01-29 at 13.47.26](https://radixtalk.com/uploads/default/original/2X/b/b494179c16440f4bf7f16904040a13351e114a9b.png) > **[GitHub - Kafkafrate/Radix-Consultation-App-V2: Frontend for the Radix...](https://github.com/Kafkafrate/Radix-Consultation-App-V2/tree/main)** > > main I have also a Video of how it works but I’ll post it on telegram as I can’t figure out how to upload directly here. ---
**Author:** ![linuxx](https://radixtalk.com/user_avatar/radixtalk.com/linuxx/32/1670_2.png) [@linuxx](https://radixtalk.com/u/linuxx)\ **Post date:** [29 January 2026 13:16 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/12 "2026-01-29T13:16:06Z")
![deepseek_mermaid_20260129_b585b5](https://radixtalk.com/uploads/default/original/2X/4/42b5528a77677f0c0b52b7382f336d8d90569cc0.jpeg) Something like these ? ---
**Author:** ![xStelea](https://radixtalk.com/user_avatar/radixtalk.com/xstelea/32/1674_2.png) [@xStelea](https://radixtalk.com/u/xStelea)\ **Post date:** [29 January 2026 13:18 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/13 "2026-01-29T13:18:40Z")
Yes, this looks accurate ---
**Author:** ![xStelea](https://radixtalk.com/user_avatar/radixtalk.com/xstelea/32/1674_2.png) [@xStelea](https://radixtalk.com/u/xStelea)\ **Post date:** [29 January 2026 13:28 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/14 "2026-01-29T13:28:43Z")
This is a good start. ![image](https://radixtalk.com/uploads/default/original/2X/c/cdf6e9614caf050fd3b9b1c5c0e08d51b05663e2.jpeg) On the create temp check page How would you display the different vote variants? **Single choice** ![image](https://radixtalk.com/uploads/default/original/2X/d/dd1fead05c1502c9e98ca6f38768d625aebddd52.png) **Multi choice** ![image](https://radixtalk.com/uploads/default/original/2X/f/f6f3d1884b350817a95c39365fc58c08ce244787.png) Which input element to use to define the selection limit? ---
**Author:** ![Vlad](https://radixtalk.com/user_avatar/radixtalk.com/vlad/32/612_2.png) [@Vlad](https://radixtalk.com/u/Vlad)\ **Post date:** [29 January 2026 14:19 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/15 "2026-01-29T14:19:30Z")
I would make that max selection field as a drop-down list selection. It works better on mobile. ---
**Author:** ![jonericcook](https://radixtalk.com/user_avatar/radixtalk.com/jonericcook/32/200_2.png) [@jonericcook](https://radixtalk.com/u/jonericcook)\ **Post date:** [29 January 2026 17:38 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/16 "2026-01-29T17:38:38Z")
I’m going to be the squeaky wheel about terminology / naming 🙂 > [@Naming / Terminology](https://radixtalk.com/t/naming-terminology/2129): > > Below is subject to change but is a starting point. I believe we should have terminology that follows the type of entity we use. If we use the DUNA then below is an example of what the names could be. Search “Definitions.” in the above document to see where I got terms. If a DUNA is used then the name on the paperwork could be: RadixDLT DAO LLC RD - RadixDLT DAO (The RD was created.) RDA - RadixDLT DAO Administrator (Bob is a RDA. There are 30 RDAs) GP - Governance Proposal (Carl submit… I believe RFP is the wrong term to use in our situation. An RFP is something someone submits out to industry to solicit proposals to come back. An architectural firm would submit an RFP out to their contractor pool. The architectural firm is at the top and it submits an RFP to those outside of it or below it who then submit proposals back in response to the RFP. What we are doing is having everything start at the bottom or outside the DAO and move up to it. RFC (request for comments) → TC (temperature check) → GP (governance proposal) or RDIP (radixdlt dao improvement proposal) or IP (improvement proposal) For me personally if we use GP (governance proposal) it could be viewed as a proposal to change how governance is done. I think we need a more general term that can encompass all types of things (ie what to fund, how to upgrade the protocol, how to change the governance structure, how to vote out people). I think XYZ Improvement Proposal is in the right direction (where XYZ is some term we agree on). I believe we all will only vote and pass something that improves radixdlt. Ideas - RadixDLT Enhancement Proposal (REP) - RadixDLT Advancement Proposal (RAP) - RadixDLT Improvement Proposal (RIP) - RadixDLT Proposal (RP) - Improvement Proposal (IP) - Proposal (P) ---
**Author:** ![projectShift](https://radixtalk.com/user_avatar/radixtalk.com/projectshift/32/1704_2.png) [@projectShift](https://radixtalk.com/u/projectShift)\ **Post date:** [29 January 2026 20:12 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/17 "2026-01-29T20:12:54Z")
Nothing can be more fitting than P (proposal) … but I’ll bet you someone is gonna come up with a subfield for _type of proposal_ 😂 ---
**Author:** ![Magal36](https://radixtalk.com/user_avatar/radixtalk.com/magal36/32/1762_2.png) [@Magal36](https://radixtalk.com/u/Magal36)\ **Post date:** [29 January 2026 20:42 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/18 "2026-01-29T20:42:31Z")
@xStelea I just used the consultation Dapp currently availbe, and I have a problem. I have ledger accounts and I have to prove ownership of those accounts EVERYTIME I vote? That would make it harder to vote on the run (ledger doesn’t work mobile & deep linking setup). When I am offshore, I can’t install the connector to corporate PCs so that would obligate me to have my own notebook with me, understand? Wouldn’t it be possible to link those accounts ONCE and after only sign with fingerprint tap? Have been long wanting to define the ledger just for recovery but Idk what’s possible with MFA on mainnet atm, I know it’s far from complete. But voting is simpler, right? No risk of loosing assets!!! ---
**Author:** ![octo](https://radixtalk.com/user_avatar/radixtalk.com/octo/32/1504_2.png) [@octo](https://radixtalk.com/u/octo)\ **Post date:** [30 January 2026 10:21 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/19 "2026-01-30T10:21:47Z")
That is very much doable, good suggestion. I thought of it while creating the blueprints, but what would happen if many XRD votes abstain and the quorum is hit, 1 XRD votes for, and 0 against? Would that pass? Seemed a bit silly to me then, but maybe this is just a crazy edge case. Or is it actually good behaviour, and is the silliness just a wrong intuition? ---
**Author:** ![octo](https://radixtalk.com/user_avatar/radixtalk.com/octo/32/1504_2.png) [@octo](https://radixtalk.com/u/octo)\ **Post date:** [30 January 2026 10:25 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/20 "2026-01-30T10:25:51Z")
**Current consultation dApp:** yes that would probably be possible through the use of Personas (it probably was, some time back? but we switched to account-based voting). **Future consultation dApp:** that will be hard, one of the core requirements is for the consultation dApp to not rely on a central entity, which results in not being able to use a centralized database. In other words, we need all data on-ledger. For that, you’ll have to sign with the account that is voting. What **will** be possible though, is to delegate the vote of your Ledger-controlled account, to an account that isn’t controlled by a Ledger. You basically allow another account to vote for you (without having to move the XRD out of the Ledger-controlled account). I think that would suit your needs right? ---
**Author:** ![Magal36](https://radixtalk.com/user_avatar/radixtalk.com/magal36/32/1762_2.png) [@Magal36](https://radixtalk.com/u/Magal36)\ **Post date:** [30 January 2026 11:15 UTC](https://radixtalk.com/t/consultation-v2-product-scope-document/2193/21 "2026-01-30T11:15:26Z")
yes, that does the job [Next page](https://radixtalk.com/t/consultation-v2-product-scope-document/2193.md?page=2)