Operational Surface
Quick route 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
Devnet rails live, production treasury still evidence-gated
Treasury network
Solana Devnet
Public rails
3 public rails
Payments fit
strong
Exact blocker
upgrade-authority-multisig · pending-external
Move production upgrade authority and operational authorities to a documented multisig or governance-owned path and rehearse rotation.
24 pending evidence items
Loading execution workbench…
PDAO token strategy
Solana Devnet
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 Devnet governance mint with an explicit reviewer boundary.
Live token truth
Mint
AZUkprJDfJPgAp7L4z3TpCV3KHqLiA8RjHAVhK9HCvDt
Initial supply
1,000,000 PDAO
Exact boundary
PDAO is a live Devnet governance and coordination token. It is not presented as a public mainnet payment coin or speculative market token.
What PDAO does now
Governance participation
PDAO is the live governance mint for the canonical reviewer-facing Devnet DAO 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 what is proven now, what is pending, and the ingestion route.
OpenCanonical custody proof
Exact pending items, exact blocker, 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
Custody workflow exists, but no structured ceremony evidence is recorded yet.
Pending external
Operators need custody state in the same shell as create, vote, reveal, and execute so launch boundaries stay explicit.
Trust state
No custody ceremony evidence is recorded yet, so trust and mainnet posture must remain bounded.
Evidence completion
0/6
Multisig, threshold, signer roster, transfer signatures, and post-transfer readouts are counted together.
Immediate next move
The product now exposes a strict custody ingestion path, but the mainnet boundary stays blocked until real multisig details, signer keys, transfer signatures, and readout references are recorded.
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 are live in-product; same-domain backend serving is still pending host cutover
The current live site is static on GitHub Pages. `/api/v1` becomes a true product rail only after a separate backend host and reverse proxy are cut over.
Read path
backend-indexer
Indexed coverage
41 proposals / 21 DAOs
Confidential
8 confidential payouts
Operator checks
6 operator checks
Integration coverage
4/6 REFHE settled · 3/4 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; public same-domain serving is still pending real cutover
Do not claim `/api/v1` as live on the current public site until the read node is hosted behind a real domain or subdomain with health, metrics, and reverse-proxy evidence.
Deploy target
https://app.privatedao.xyz/ → /api/v1
Health
/healthz
Metrics
/api/v1/metrics
Public checks
6 public checks
Indexed proof
41 proposals / 21 DAOs
Settlement proof
8 confidential payouts · 4 REFHE settled · 3 MagicBlock settled
Telemetry freshness
2026-04-11T14:20:29.957Z
Route binding
Reverse-proxy `/api/v1/*` to the read-node process while keeping writes wallet-signed on the client.
UI fallback policy
Until backend cutover is live, 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 Devnet evidence path
Wallets
50
Multi-wallet Devnet 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
Execute Proposal
View Logs
Diagnostics
Repo Public + CLI
Engineering and ops discipline
Advanced debugging
Batch operations
Emergency recovery
Migration tools
Stress tests
Loading governance workbench…
Loading execution session…
Loading proposal workspace…
Loading wallet runtime…
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.
UI Full
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
Open the command center and stage governance actions from the product shell.
Commit Vote
Commit voting stays inside the live wallet-connected governance surface.
Reveal Vote
Reveal remains a first-class product action rather than a hidden protocol-only step.
Finalize Proposal
Finalize stays explicit in the UI so the product matches the real on-chain phase boundary before execution.
Execute Proposal
Execution only becomes visible when the proof and readiness boundary says it is ready.
View Logs
Execution logs, vote timeline, and treasury state belong inside the operating dashboard.
Diagnostics
Runtime evidence, proof freshness, and operational health stay in the product diagnostics route.
Repo Public + CLI
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.
Loading treasury routes…
Loading live indexed proposal…
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 Devnet health, proof recency, wallet readiness, and track-to-market posture visible inside the daily product shell instead of hiding them in reviewer docs alone.
Proposal flow health
37.5%
7/7 governance proof steps are finalized. 0 proposal is already executed on devnet, 0 proposal is still in commit mode, and 5 proposal is still waiting on settlement evidence.
Open proof and executionWallet-by-wallet readiness
80%
4/5 wallets are review-ready and 5/5 expose diagnostics. Pending real-device targets remain visible in runtime evidence.
Open wallet diagnosticsProof freshness
3d old
Runtime evidence 3d old, Devnet canary 3d old, and frontier integrations 3d old remain published together.
Open trust documentsTrack-specific commercial readiness
Colosseum Frontier · RPC Infrastructure Credits · Privacy Track
Current top conversion-ready tracks combine win probability, commercial upside, and mainnet distance: Colosseum Frontier (9.2/10) · RPC Infrastructure Credits (8.3/10) · Privacy Track (7.9/10).
Open competition centerStrict custody ingestion
Record ceremony evidence in the exact shape needed by the canonical custody proof
0/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 pending
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
Pending
Need implementation, multisig address, creation signature, and rehearsal signature.
Threshold and timelock
Capture the final threshold and 48+ hour configuration evidence
Pending
Need exact 2-of-3 threshold, 48+ hour timelock, configuration signature, and reference URL.
Signer roster
Record each signer slot with a real public key and backup confirmation
Pending
Slot 1 · founder-operator
Pending
Need a real signer public key and backup confirmation.
Slot 2 · independent-security-or-ops-signer
Pending
Need a real signer public key and backup confirmation.
Slot 3 · recovery-or-governance-signer
Pending
Need a real signer public key and backup confirmation.
Authority transfer surfaces
Each surface needs destination authority, transfer signature, and post-transfer readout reference
program-upgrade-authority
5AhUsbQ4mJ8Xh7QJEomuS85qGgmK9iNvFqzF669Y7Psx
Pending
Need destination authority, transfer signature, readout text, and a reference link.
dao-authority
5AhUsbQ4mJ8Xh7QJEomuS85qGgmK9iNvFqzF669Y7Psx
Pending
Need destination authority, transfer signature, readout text, and a reference link.
treasury-operator-authority
5AhUsbQ4mJ8Xh7QJEomuS85qGgmK9iNvFqzF669Y7Psx
Pending
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 Mainnet blocker surface. This is a strength when shown honestly rather than implied away.
Remove unnecessary single-signer powers.
Keep pending 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
0/6 structured gates passed
pending-external
This local packet remains reviewer-safe. It accepts only public keys, public transaction signatures, and docs or explorer references.
Current packet preview
Multisig implementation: pending-selection
Multisig address: Not recorded yet
Timelock configured hours: Not recorded yet
Signer keys populated: 0/3
Authority transfers with signatures: 0/3
Never include secrets
No seed phrases, private keys, unencrypted keypair exports, or screenshots containing secret material belong in this packet.