Explore
Product navigation
Command Center
Create → Vote → Execute
Commercial + reviewer aware
Command Center
A guided governance product surface for normal users, reviewers, and operators
This is the part of the migration that closes the loop: product-pack selection, proposal submission, private voting, wallet state, proof visibility, and treasury execution in one operational shell.
Payments truth
Payments truth strip
Keep operators and reviewers on the same treasury truth before proposal execution: public rails, sender discipline, custody proof, and the blocker remain visible inside the command shell.
Payments readiness
Testnet rails live, production treasury still evidence-gated
Treasury network
Solana Testnet
Public rails
3 public rails
Payments fit
strong
Exact blocker
upgrade-authority-multisig · external ceremony gate
Move production upgrade authority and operational authorities to a documented multisig or governance-owned path and rehearse rotation.
9 ceremony evidence gates
PDAO token strategy
Solana Testnet
Token-2022
Mint authority disabled
PDAO token strategy for operator and execution paths
Show the token where operators act: proposal creation, voting, treasury-sensitive motions, and payout governance stay tied to a visible Testnet governance mint with an explicit reviewer boundary.
Live token truth
Mint
DFYvBdivHCe4bSErgCiKm2RhwGEcZYbBPFQzLNr37Bie
Initial supply
1,000,000 PDAO
Exact boundary
PDAO is preserved Testnet governance-token evidence attached to the current PrivateDAO Testnet path. It is not presented as a public mainnet payment coin or speculative market token.
What PDAO does now
Governance participation
PDAO is the live Token-2022 governance mint for the canonical reviewer-facing Testnet path and anchors proposal participation and voting.
Proposal discipline
It exists as the participation layer behind proposal lifecycle responsibility instead of leaving proposal access completely open-ended.
Treasury accountability
Treasury motions stay tied to a governed participation surface rather than informal wallet choreography or off-chain chat decisions.
Reviewer-visible identity
The token surface, mint attestation, metadata, and disabled mint authority are already reviewer-visible and bound to the proof package.
What it gates
Voting rights
PDAO gates who participates in the proposal lifecycle today, especially voting and reviewer-facing governance flows.
Proposal access
The token strategy supports proposal access and anti-spam governance posture without claiming a new protocol interface beyond the documented token-gated surface.
Treasury action classes
It governs who can shape treasury-sensitive motions such as top-ups, vendor payouts, contributor flows, and confidential payout proposals.
Community membership
PDAO already reads naturally as a membership and governance identity layer for recurring operator and community actions.
What remains future-facing
Gaming governance
Reward policies, clan treasury motions, sponsorship budgets, and tournament allocations are the most natural next gaming-facing uses.
API and operator permissions
Hosted reads, diagnostics, and API-oriented governance services can use PDAO as a permission and accountability layer rather than a billing token.
Commercial service access
Longer term, PDAO can anchor recurring governance identity across enterprise deployments, contributor rails, and governed service permissions.
Confidential settlement governance
Future-facing confidential payout and settlement policies can stay governed by PDAO without claiming that the token itself is the settlement asset.
How it connects to the stack
ZK
ZK remains the proof and reviewer-confidence rail around proposal patterns and governance interpretation, not a separate token thesis.
MagicBlock
MagicBlock is the responsive confidential payout corridor. PDAO governs access and policy around that corridor instead of replacing it.
REFHE
REFHE stays the encrypted settlement gate for confidential payout proposals. PDAO is the governance layer deciding when those proposals move forward.
RPC and API
Indexed proposals, hosted reads, diagnostics, and reviewer telemetry make the token strategy inspectable as infrastructure rather than symbolic branding.
Payments
PDAO should be read as a governance and control token around payments readiness, payout policy, and treasury routing, not as the public payments coin itself.
Custody truth quick actions
Open reviewer truth, canonical proof, intake schema, and the strict apply route without leaving the command shell first.
Reviewer packet
Shortest reviewer-facing custody truth packet with proven evidence, ceremony gates, and the ingestion route.
OpenCanonical custody proof
Exact ceremony gates, observed chain readouts, and explorer-linked closure points.
OpenStrict intake shape
Canonical multisig intake schema for signer keys, multisig address, timelock proof, and authority-transfer evidence.
OpenApply route
Open the strict packet workspace, then apply the operator JSON with `npm run apply:custody-evidence-intake`.
OpenCommand-center readiness
Structured custody evidence is partially recorded: 4/6 gates passed.
Partially evidenced
Operators need custody state in the same shell as create, vote, reveal, and execute so launch boundaries stay explicit.
Trust state
Some ceremony evidence is recorded, which improves reviewer confidence and points clearly to the remaining readiness steps.
Evidence completion
4/6
Multisig, threshold, signer roster, transfer signatures, and post-transfer readouts are counted together.
Immediate next move
Reviewer confidence improves once the packet is structured and reproducible, but the launch boundary must remain explicit until every signer, transfer, and readout reference is complete.
Missing evidence items
Read-node activation
Read-node operator activation
Operators need one truth surface for backend-indexed reads, runtime checks, and the exact deployment gap before same-domain `/api/v1` becomes a live production-style rail.
Activation state
Indexed reads and same-domain backend serving are live for Testnet reviewer checks
Public product routes consume indexed read evidence and the hosted `api.privatedao.org` lane now serves health, relayer, QVAC, Covalent GoldRush, Torque, Zerion, and SNS checks.
Read path
backend-indexer
Indexed coverage
17 proposals / 16 DAOs
Confidential
3 confidential payouts
Operator checks
6 operator checks
Integration coverage
2/3 REFHE settled · 1/2 MagicBlock settled
Host readiness
Backend host readiness
Operators need the cutover truth in-product: where the read service should live, what must be public, and how the UI behaves until the host is truly online.
Readiness state
Host-ready lane defined; same-domain public serving is in final security hardening before release cutover
Use https://api.privatedao.org/api/v1 as the live read-node boundary. Same-domain `/api/v1` on the static frontend remains a future reverse-proxy consolidation step, not the current production-candidate API host.
Deploy target
https://privatedao.org/ → https://api.privatedao.org/api/v1
Health
https://api.privatedao.org/healthz
Metrics
https://api.privatedao.org/api/v1/metrics
Public checks
6 public checks
Indexed proof
17 proposals / 16 DAOs
Settlement proof
3 confidential payouts · 2 REFHE settled · 1 MagicBlock settled
Telemetry freshness
2026-05-26T03:09:35.774Z
Route binding
Serve read-node traffic from `https://api.privatedao.org/api/v1` until a same-domain reverse proxy is intentionally cut over.
UI fallback policy
If the API host is unreachable, keep read-node evidence available through in-app packets and snapshots.
Live proofs
2
Baseline proof and dedicated V3 proof packet are both reviewer-facing
ZK anchors
3
On-chain proof anchors exposed in the Testnet evidence path
Wallets
50
Multi-wallet Testnet rehearsal already captured and packaged
Commercial rails
4
Grant, fund, gaming, and enterprise service packs remain part of the UI
UI full, CLI disciplined
Command Center is where real users operate. Engineering-heavy recovery, migration, stress, and batch controls stay in the repo and CLI so the product surface remains clean.
UI Full
Normal-user product surface
Connect Wallet
Create DAO
Create Proposal
Commit Vote
Reveal Vote
Finalize Proposal
Execute Proposal
View Logs
Diagnostics
Repo Public + CLI
Engineering and ops discipline
Advanced debugging
Batch operations
Emergency recovery
Migration tools
Stress tests
Verification split
Live lane and proof status stay explicit
Live now in product UI
Create DAO, Create Proposal, Commit, Reveal, Finalize, and Execute are wired through the live wallet-first lane on Testnet.
Repo proof captured
Local wallet lifecycle proof exists for the governance core, including treasury execution in the repo proof surfaces.
Pending captures
Browser-wallet proof on the web and real-device action proof on Android still need direct runtime capture. They are not implied by the live code lane alone.
Exact product operations
This route family keeps the full normal-user governance flow inside the UI: connect, create, vote, reveal, execute, log review, and diagnostics. Everything deeper stays in the repo.
Product flow
Connect Wallet
Start with Solflare, Phantom, or Backpack and activate the live governance flow.
Create DAO
Use the guided start workspace to move into the DAO creation rail instead of repo setup.
Create Proposal
Stay in the same govern flow and submit the first proposal after the DAO is ready.
Commit Vote
Commit voting stays inside the same live wallet-connected govern surface.
Reveal Vote
Reveal remains a first-class product action rather than a hidden protocol-only step.
Finalize Proposal
Finalize stays explicit in the govern flow so the product matches the real on-chain phase boundary before execution.
Execute Proposal
Execution only becomes visible when the real readiness boundary says it is ready.
Live Activity
Follow proposals, vote timeline, treasury state, and execution results in the activity view.
Diagnostics
Runtime evidence, proof freshness, and operational health stay in the product diagnostics route.
Operator layer
Engineering and recovery rails
Advanced debugging
Batch operations
Emergency recovery
Migration tools
Stress tests
These stay outside the buyer-facing flow. They remain accessible through the repo for maintainers, audits, migrations, incident handling, and deep protocol operations.
Step 1
Choose a product pack
Start from grant, fund, gaming, or enterprise rails so the app can bias the governance and treasury experience correctly.
The product story feels like a guided deployment, not a blank DAO console.
Step 2
Create and fund the DAO
Bootstrap the DAO, treasury, governance settings, and wallet-connected runtime surfaces from one product shell.
Operators understand treasury rails, review state, and service options before launching governance.
Step 3
Submit a private proposal
Proposal cards keep privacy boundary, treasury path, service fit, and hardening expectations visible before a vote begins.
Normal users understand what is being approved and what will be executed.
Step 4
Private vote and execute treasury
Commit, reveal, evidence gates, and treasury execution remain connected to proof packets and runtime diagnostics.
The product closes the loop from governance intent to reviewer-visible execution evidence.
Command-center operating health
These four panels keep live Testnet health, proof recency, wallet readiness, and product-to-market posture visible inside the daily product shell instead of hiding them in reviewer docs alone.
Proposal flow health
50%
0/7 governance proof steps are finalized. 1 proposal is already executed on Testnet, 0 proposal is still in commit mode, and 2 proposal is still waiting on settlement evidence.
Open proof and executionWallet-by-wallet readiness
Runtime capture live
Wallet diagnostics, connect/sign/submit evidence, and real-device intake are surfaced as a living runtime program with proof packets attached for each supported wallet path.
Open wallet diagnosticsProof freshness
2d old
Runtime evidence 2d old and Testnet canary 2d old remain published together. The integration packet remains linked as the reviewer baseline without turning an archived source packet into the freshness score. Latest Testnet rehearsal is 21d old with 9 confirmed lifecycle signatures.
Open trust documentsProduct-lane commercial readiness
Core Product Lane · Runtime API And Fast Reads · Privacy Infrastructure Lane
Current top conversion-ready product lanes combine commercial upside, operating readiness, and mainnet distance: Core Product Lane (9.2/10) · Runtime API And Fast Reads (8.3/10) · Privacy Infrastructure Lane (7.9/10).
Open learning pathStrict custody ingestion
Record ceremony evidence in the exact shape needed by the canonical custody proof
4/6 gates
This surface no longer collects free-form notes only. It builds a strict, reviewer-safe JSON packet that maps directly into
docs/multisig-setup-intake.json. Only public keys, public transaction signatures, and readout references belong here.Define signer set
Repo-ready
Freeze the real 3-signer roster and backup procedures before any authority movement.
Record multisig package
Strict ingestion live
Collect the implementation, address, creation signature, rehearsal signature, and timelock references in one structured packet.
Capture authority transfer evidence
External execution next
Record the destination authority, transfer signature, and post-transfer readout reference for each operational surface.
Apply and rebuild canonical proof
Repo automation ready
Save the JSON packet into `docs/custody-evidence-intake.json` and run the apply command to update canonical proof artifacts.
Multisig package
Implementation, address, creation signature, and rehearsal signature
Next step
Need implementation, multisig address, creation signature, and rehearsal signature.
Threshold and timelock
Capture the final threshold and 48+ hour configuration evidence
Valid
Threshold and timelock evidence are fully recorded.
Signer roster
Record each signer slot with a real public key and backup confirmation
Valid
Slot 1 · founder-operator
Valid
Public key and backup discipline recorded.
Slot 2 · independent-security-or-ops-signer
Valid
Public key and backup discipline recorded.
Slot 3 · recovery-or-governance-signer
Valid
Public key and backup discipline recorded.
Authority transfer surfaces
Each surface needs destination authority, transfer signature, and post-transfer readout reference
program-upgrade-authority
EP9xE8MJZ6FfyEwLqns6HDdUZBknEa7WGYs1Jzsecuva
Valid
Destination, signature, and readout reference are all recorded.
dao-authority
EP9xE8MJZ6FfyEwLqns6HDdUZBknEa7WGYs1Jzsecuva
Next step
Need destination authority, transfer signature, readout text, and a reference link.
treasury-operator-authority
EP9xE8MJZ6FfyEwLqns6HDdUZBknEa7WGYs1Jzsecuva
Next step
Need destination authority, transfer signature, readout text, and a reference link.
Authority split
Mainnet requires a hard separation between upgrade authority, treasury authority, and admin authority. PrivateDAO should not carry a single-wallet super-admin posture into production.
Upgrade authority must be isolated from treasury execution.
Treasury authority must remain bound to proposal execution and treasury policy.
Admin authority should stay bounded and explicitly reduced before launch.
Production ceremony
Authority transfer has to be observable and reviewable. The credible path is a documented multisig ceremony with signer inventory, role assignment, and transaction-backed handoff evidence.
Create the production multisig and define signer roles.
Transfer upgrade authority with transaction evidence.
Transfer treasury authority and record the evidence path.
Launch boundary
Until the ceremony is complete, authority hardening remains part of the explicit production-gate surface. This is a strength when shown clearly rather than implied away.
Remove unnecessary single-signer powers.
Keep the next trust steps visible to reviewers and buyers.
Treat authority transfer as a trust event, not an internal note.
Strict intake packet
How to close this fast
When the real ceremony values arrive, download the JSON packet below, save it as
docs/custody-evidence-intake.json, then run npm run apply:custody-evidence-intake. That command updates the canonical intake and rebuilds canonical custody proof, reviewer packet, and launch trust packet artifacts together.Ingestion readiness
4/6 structured gates passed
ready-for-transfer
This local packet remains reviewer-safe. It accepts only public keys, public transaction signatures, and docs or explorer references.
Current packet preview
Multisig implementation: Squads Protocol v4
Multisig address: CALHrBqx6jbzcPn2NVcinqSAHeod65v9LcDuTxsdPqBv
Timelock configured hours: 48
Signer keys populated: 3/3
Authority transfers with signatures: 1/3
Never include secrets
No seed phrases, private keys, unencrypted keypair exports, or screenshots containing secret material belong in this packet.