◈ PRIVATE GOVERNANCE · CONFIDENTIAL TREASURY · SOLANA DEVNET LIVE

1st Place · Superteam Poland

ZK Companion Layer

PRIVATE VOTING. SAFE EXECUTION.

PrivateDAO is a live Solana governance and treasury product for serious on-chain organizations. Voting intent stays sealed during commit, confidential compensation stays aggregate on chain, and every lifecycle action remains signed, proposal-bound, and Devnet-verifiable.

Commit-reveal governance · zk_enforced hardening · Confidential payroll and bonus plans · REFHE and MagicBlock payout gating · Backend-indexed runtime reads

◎

Solana + Anchor

Real DAO lifecycle, treasury execution, PDA-bound governance state, and Devnet-verifiable transactions.

⟡

ZK Layer

Companion proof anchors, proof registry, and stronger `zk_enforced` review path for sensitive proposals.

▣

REFHE

Proposal-bound encrypted evaluation envelope for confidential payroll and bonus flows that need stronger review logic.

◈

MagicBlock

Private token corridor support for confidential payout plans with proposal-bound settlement evidence.

⇄

RPC Fast

Backend-indexed proposal reads, pooled RPC path, metrics, diagnostics, and direct RPC fallback for reliability.

◌

Realms + Android

Realms-oriented migration path, voter-weight compatibility, and Android native support with Solana Mobile Wallet Adapter.

✦ConsumerCommunity treasury app

◉WebLive governance surface

◌AndroidKotlin native + MWA

◎On-chainDevnet program live

⟡ZKCompanion proofs + zk_enforced path

▤PayrollConfidential salary + bonus plans

◈MagicBlockPrivate token corridor support

▣IntegritySHA256 artifact manifest live

◇PDAODevnet governance token · DeAura

Zero-Knowledge Layer Live PrivateDAO now includes a real non-breaking Groth16 companion layer for proof-backed vote validity and eligibility. Artifact Integrity Layer Live Canonical zk and proof artifacts now ship with a published sha256 manifest for tamper-evident review.

Service Catalog ↗ Pricing Model ↗ Pilot Program ↗ Pilot SLA ↗ Governance Hardening V3 ↗ Settlement Hardening V3 ↗ ZK Overlay ↗ Artifact Integrity ↗ Android Native ↗ Mirror Deployment ↗

LIVE SUCCESS PROOF

Real Devnet treasury execution already completed across baseline and V3 paths

A live wallet-to-wallet treasury action already ran through the full lifecycle on Devnet, and a dedicated V3 packet now proves additive governance and settlement hardening without reinterpreting legacy flows.

Latest Live Proof ↗ Live Proof V3 ↗ Operational Evidence ↗

REVIEWER PACKET

50 wallets, 212 attempts, 3 on-chain ZK anchors, and V3 hardening proof

The reviewer surface now combines the 50-wallet Devnet rehearsal, expected security rejects, ZK anchors, runtime evidence, and a dedicated V3 live proof packet in one machine-checked package.

Frontier Integrations ↗ Launch Trust Packet ↗

BOUNDARY CHECK

Live now versus pending-external stays explicit

The page sells the operating story, but it does not pretend multisig transfer, audit closure, or mainnet cutover are already complete. Those remain linked as pending-external blockers.

Mainnet Blockers ↗ Go-Live Attestation ↗

0 / 0

TALLY DURING VOTING

SHA256

COMMITMENT SCHEME

LIVE PROPOSALS LOADED

SYNCING

CURRENT LEADING PHASE

REVIEW

ZK PATH STATUS

WAITING

EXECUTION READINESS

DISCONNECTED

WALLET STATUS

UNKNOWN

GOV TOKEN READINESS

CREATE

CHECKING

Proposal creation requires a connected wallet with the governance token for the active DAO.

COMMIT

CHECKING

Commit is available only during the commit phase and remains proposal-bound.

REVEAL

CHECKING

Reveal opens only after voting closes and requires the original vote plus salt.

EXECUTE

CHECKING

Execution remains blocked until finalize succeeds and timelock clears.

STOREFRONT

Choose the operating pack that matches the organization you serve.

Start with the pack that matches the organization you operate. Each pack maps to the same PrivateDAO surface: DAO creation, proposal submission, private voting, treasury execution, confidential payroll, Realms migration, and review automation.

PRODUCT-FIRST ENTRY

BEST FOR

Community grants and treasury approvals

Best for grant committees that need private approvals and clean execution steps.

WHY THIS PACK

Simple lifecycle, strong reviewer clarity

This pack keeps the flow centered on create DAO, fund treasury, submit proposal, private vote, and execute with the lowest onboarding friction.

TECHNOLOGY FIT

Core governance only

Commit-reveal governance

Treasury execution

Read-node visibility

PRIMARY CTA

Launch a standard treasury proposal

Launch the DAO bootstrap, treasury funding, and proposal builder with the right defaults already loaded.

REALMS

Migration-ready, not hand-wavy.

PrivateDAO already supports a Realms-oriented migration path and voter-weight compatibility. Use it to move into private governance without pretending every Realms workflow becomes one click.

Migration Story

PRODUCT FLOW

Create DAO → Submit proposal → Private vote → Execute treasury

The homepage now keeps the lifecycle readable for non-builders. The same packs lead into the real DAO bootstrap, builder presets, command center, and proof layer below.

Production Simulation DAO

API AND OPS

PrivateDAO is also a service surface.

Beyond the app, the project can be delivered as hosted read API, review-export tooling, migration support, pilot onboarding, and operator workflows. The boundary stays honest: packaged services are documented, not faked as already-live SaaS checkout.

Pricing Model

WHAT IT IS

A live governance workspace

PrivateDAO is a wallet-connected governance and treasury product for on-chain organizations. It combines DAO bootstrap, proposal creation, private voting, reveal, finalize, treasury execution, and confidential payout orchestration in one surface.

Create DAO and treasury

Create and inspect proposals

Run commit, reveal, finalize, and execute

WHAT IT DELIVERS

Private voting with visible operations

The voting intent stays hidden during the active commit window, while the governance lifecycle, confidential payout paths, and runtime evidence remain reviewable through signed Devnet transactions, backend-indexed reads, and reproducible repo flows.

Hidden tally during voting

Explicit proposal lifecycle

Encrypted payroll and bonus approvals

Backend-indexed proposal reads with RPC fallback

Explorer-verifiable execution evidence

CRYPTOGRAPHY

Commit-reveal plus Groth16 companion proofs

PrivateDAO uses sha256 commitments for proposal-scoped private voting, a non-breaking Groth16 companion layer for vote validity, delegation authorization, and tally integrity, plus a stronger `zk_enforced` proposal path when receipts are upgraded.

Proposal-scoped commitment binding

ZK companion proofs live in the repo

Published transcript and attestation artifacts

SAFETY GUARANTEES

Lifecycle safety, treasury safety, replay resistance

The product surface is backed by the on-chain state machine, signer checks, treasury recipient and mint validation, proposal-scoped replay rejection, and published operational evidence.

Timelocked execution

Exact account and signer binding

Runtime, adversarial, and stress evidence

SYSTEM PILLARS

The repo is deeper than the UI.
This is what PrivateDAO actually ships.

ON-CHAIN LIFECYCLE

A real governance state machine

PrivateDAO is not a voting mockup. The repo ships a live Solana governance program with proposal creation, commit, reveal, finalize, timelocked execution, and treasury action enforcement.

Commit, reveal, finalize, cancel, veto, and execute are implemented on-chain

Proposal, DAO, treasury, signer, and delegation bindings are enforced by program logic

Execution remains explicit and phase-bound rather than implied by UI state

CRYPTOGRAPHY

Privacy layer plus proof layer

The product combines proposal-scoped sha256 commit-reveal voting with a non-breaking Groth16 companion stack for vote validity, delegation authorization, and tally integrity, then exposes a proposal-level `zk_enforced` route with stronger receipt requirements.

Commitment binds vote, salt, proposal, and wallet

Groth16 layers are published with transcript, registry, provenance, and attestation

Artifact integrity is anchored by a reviewer-visible sha256 manifest

RUNTIME ASSURANCE

Evidence under stress, not claims

The repository contains multi-wallet, adversarial, RPC-failover, race-condition, runtime, release-drill, read-node, and MagicBlock runtime evidence so the system can be reviewed as an operating product.

50-wallet Devnet execution plus a 350-wallet wave profile for heavier operator runs

Proposal isolation, finalize races, execute races, and stale blockhash recovery

Runtime diagnostics, wallet matrix, canary, real-device intake paths, and backend-indexed read flow

GOVERNANCE PRODUCT

Treasury operations with accountable access

The repo also ships the product layer around the protocol: PDAO token-gated participation, mobile path, migration path, confidential payroll flows, MagicBlock and REFHE operator routes, and reviewer-ready Devnet execution surfaces.

PDAO governance token on Devnet through DeAura

Web governance surface plus Android-native path with MWA

Encrypted salary and bonus batch approvals with proposal-bound settlement

Proof Center, Security, Diagnostics, and mainnet transition package

Confidential Treasury Operations

PrivateDAO now ships encrypted payroll and bonus approvals as a real product surface. The detailed recipient sheet stays off-chain, while governance approves and executes the aggregate batch on chain through a proposal-bound payout plan.

PAYROLL + BONUS

WHAT IS PUBLIC

Aggregate settlement only

The chain exposes only payout type, asset type, settlement recipient, recipient count, total amount, and immutable hashes for the encrypted manifest.

Feature Note Diagram

OPERATOR FLOW

Proposal-bound payroll and bonus batches

Create a proposal, attach the encrypted batch hashes, pass the proposal through commit-reveal or `zk_enforced`, then execute the aggregate payout after timelock. Token batches can now bind to a MagicBlock private payment corridor before execution.

Flow Note Flow SVG

MAGICBLOCK

Private payment corridor for token payouts

For confidential token payouts, PrivateDAO can now bind a MagicBlock corridor to the proposal itself. The treasury path remains blocked until the corridor is settled on-chain with validator, queue, and transaction evidence.

Feature Note Operator Flow

REVIEW BOUNDARY

Auditable without leaking the full sheet

Auditors and reviewers can reason about plan binding, treasury safety, and immutable hashes without requiring the full payroll manifest to be on chain.

Audit Scope Audit Packet

CONFIDENTIAL TREASURY COMMAND CENTER

One guided path from private approval to evidence-gated execution.

This operator flow turns the feature stack into a single user journey: choose a confidential payout, bind encrypted evidence, pass commit-reveal governance, wait for proof and settlement readiness, then execute only when the selected proposal is actually eligible. It is a product guide over the existing protocol surface; it does not bypass wallet signatures or on-chain timing rules.

CURRENT BOUNDARY Devnet-ready
evidence-gated
mainnet-blocked

Select DAO and payout type

Start with a DAO PDA, choose salary or bonus, define aggregate amount, recipient count, and the settlement recipient without placing the full sheet on chain.

Bind encrypted evidence

Attach manifest hash, ciphertext hash, optional REFHE envelope inputs, and MagicBlock corridor settings for token payout paths.

Pass private governance

Move through commit, reveal, finalize, and timelock. The selected proposal panel keeps valid next actions and explorer evidence tied to the same proposal.

Execute only when ready

Execution remains blocked until the proposal is finalized, the timelock clears, and the relevant proof, REFHE, or MagicBlock evidence boundary is satisfied.

Open Frontier Flow Open Payroll Flow Open MagicBlock Evidence Open ZK Evidence

ACTIVE FLOW CONTEXT

Select a live proposal or connect a wallet to hydrate the guided flow with the current DAO, phase, and evidence boundary.

STEP 1

CHECKING

Create proposal

Configure a confidential salary, bonus, or grant proposal and keep the recipient-level sheet off-chain.

STEP 2

WAIT

Commit vote

Commit a hidden vote hash that binds vote byte, salt, proposal, and voter wallet.

STEP 3

WAIT

Reveal and finalize

Reveal the original vote and salt, then finalize through the standard or zk_enforced path when the window closes.

STEP 4

WAIT

Execute treasury

Execution stays blocked until timelock, proposal phase, and confidential evidence boundaries are all satisfied.

REVIEW

ZK companion layer

On-chain anchors, receipts, and the zk_enforced finalize path stay proposal-bound.

REFHE

OPTIONAL

Encrypted evaluation

REFHE envelopes gate confidential payroll and bonus execution when encrypted evaluation is required.

MagicBlock

OPTIONAL

Private token corridor

MagicBlock binds confidential token payouts to a proposal-scoped private-payment corridor and settlement evidence.

RPC Fast

BACKEND

Read-node reliability

The frontend reads runtime, proposals, and ops through the backend-indexer path when available, with direct RPC fallback.

Execution checklist

Waiting for live proposal contextThe checklist hydrates after a proposal is selected or the live proposal list loads.

Technology activation matrix

Waiting for live proposal contextThis matrix will explain why ZK, REFHE, MagicBlock, or backend-indexed RPC matter for the currently active proposal.

WHY PRIVATEDAO

Hide voting intent.
Keep execution accountable.

PUBLIC GOVERNANCE

Intent leaks before the decision is final

Open tally pressure changes behavior mid-vote. Capital can react early, narratives shift around the live count, and treasury expectations start moving before governance is finished.

LIVE TALLY ● LIVE

YES 0

NO 0

🤖 Bot detected: whale wallet buying votes to flip proposal. Front-running treasury transfer...

PRIVATEDAO FLOW

Intent stays sealed until reveal opens

Commit-reveal keeps the vote hidden while the proposal is still active. The chain records the commitment first, then verifies the original reveal payload only in the correct phase.

TALLY — CRYPTOGRAPHICALLY SEALED

YES: ? / NO: ?

SEALED UNTIL REVEAL PHASE ENDS

› Waiting for live proposal data
› Commitments remain hidden during voting
› Refreshes automatically from devnet

ACTIVE GOVERNANCE

Live Proposals

CHECKOUT-LIKE ONBOARDING

Start like a product operator, not like a protocol archaeologist.

This rail condenses the normal-user path into four actions: pick the right pack, create and fund the DAO, launch the proposal, then run private voting and treasury execution when the proposal is live.

PRODUCT FLOW

STEP 1

Choose product pack

Start from Grant Committee, Fund Governance, Gaming DAO, Enterprise DAO, or Realms Migration instead of filling raw fields from scratch.

STANDARD PACK

STEP 2

Create and fund DAO

Create the DAO, receive the initial governance token allocation, then fund the treasury from the same surface.

CHECKING

STEP 3

Launch proposal

Use a preset-backed builder instead of a blank console. The builder advisor already explains when ZK, REFHE, MagicBlock, and RPC Fast matter.

CHECKING

STEP 4

Private vote and execute

Commit, reveal, finalize, and execute remain phase-bound. When a proposal is live, the selected proposal panel and command center keep the next valid action obvious.

CHECKING

STANDARD GRANT PACK

Standard Treasury Grant

The cleanest starting point for normal operators: bootstrap the DAO, fund the treasury, launch one proposal, then run private vote and execute with the least onboarding friction.

BEST FOR

Grant committees and community treasuries that need private approvals before visible treasury movement.

BUYER PATH

Pilot package first, then operator trust packet and launch checklist.

RECOMMENDED OFFER

Pilot Package

ACTIVE TECHNOLOGY FIT

Commit-reveal governance

Treasury execution

RPC Fast read path

WHAT YOU GET

Fastest path to Create DAO → Submit proposal → Private vote → Execute treasury

Minimal operator overhead for the first pilot cycle

Clear reviewer packet and buyer-facing story

NEXT PROOF TO OPEN

Latest Live Proof + Trust Package

Commercial Decision Surface

This layer keeps the next business decision obvious: compare the packs, open the API surface, or inspect the live-versus-pending boundary before you ask a buyer or reviewer to trust the story.

DECISION LAYER

COMPARE PLANS

Choose the product pack before you read protocol details.

Each pack already maps to a buyer persona, a technology stack emphasis, and an operating outcome. Start from the commercial shape, then open the exact proof and builder path.

Grant Committee: shortest route to DAO bootstrap and treasury execution

Fund Governance: private committee direction plus ZK review overlay

Gaming DAO: token-native operations with MagicBlock relevance

Enterprise DAO: payroll, bonus, trust package, and guided rollout

API + OPS

Open the hosted service surface before you promise an integration.

PrivateDAO can already be packaged as hosted read infrastructure, runtime evidence exports, migration help, and pilot ops support without pretending that custody is delegated or final mainnet launch is complete.

Hosted Read API + pooled RPC / RPC Fast path

Runtime evidence and reviewer export packets

Realms migration and governance continuity help

Pilot onboarding, SLA, and operator guidance

LIVE BOUNDARY

Trust the line between live Devnet proof and pending-external launch work.

This is where the page stays credible: it shows what is already real, what still needs external ceremony, and what a pilot should expect in week one versus a real-funds launch process.

Live now: lifecycle, evidence packets, ZK anchors, guided command center

Live now: REFHE and MagicBlock paths, RPC-backed reads, reviewer exports

Pending-external: multisig custody, authority transfer, audit closure

Pending-external: real-device matrix completion and final mainnet cutover

DEVNET · LIVE DATA LOADING

Loading live proposals from Solana Devnet

The app is reading real on-chain proposal accounts from the configured program. If nothing is live yet, this panel will switch to the bootstrap guidance state.

Current task Fetch proposal accounts and derive the leading phase

SELECTED PROPOSAL

Inspect state, choose the next action, and verify execution.

This panel maps the selected proposal into a product control surface: current phase, next valid action, verification links, and exact repo commands for the live lifecycle.

🔒 ZK Companion

Awaiting selection

OPERATE

Use the valid next step only

Commit during voting, reveal after voting closes, finalize after reveal closes, then execute only after timelock expiry.

VERIFY

Keep every action tied to chain state

Explorer links, history, and command builders stay attached to the selected proposal instead of floating as disconnected review notes.

GUARDRAILS

Safety stays protocol-bound

Treasury movement, replay rejection, signer checks, and timing windows remain enforced by the deployed program rather than page state alone.

ZK STATUS

Anchors appear here when they are live

The canonical Devnet proof path carries on-chain proof anchors. Other proposals keep the same lifecycle and can still open the Proof Center review path.

STATUS

Click any live proposal card below to populate this panel.

BUYER STORY

Waiting for selected proposal context

Choose a live proposal card to see the correct buyer path, proof packet, operator next step, and trust boundary for this exact proposal.

Step 1 / 2 — DAO bootstrap console

Use this console in order: create the DAO, receive the initial governance token allocation automatically, then fund the treasury before opening proposals.

STEP 1 — CREATE DAO

yarn create-dao -- --name "PrivateDAO Live" --quorum 51 --reveal-window 180 --delay 5

This flow creates the governance mint, creates your associated token account, and mints the initial governance allocation to the connected wallet automatically.

If this fails, the usual next step is simple: change the DAO name first, then retry from the same wallet.

STEP 2 — DEPOSIT TREASURY

yarn deposit -- --dao <DAO_PDA> --amount 0.2

Use the DAO selector above or paste a DAO PDA directly. This keeps treasury funding scoped to the DAO you actually intend to operate.

FINALIZE

When the reveal window closes, finalize the selected proposal from the repo.

yarn finalize -- --proposal <PROPOSAL_PUBKEY>

Step 3 — Create proposal on-chain

Proposal creation is real and permissioned by governance token ownership. Run this after DAO creation and treasury funding. The connected wallet must hold the governance token for the selected DAO. Use direct treasury actions for simple transfers, or switch on a confidential salary or bonus batch when the recipient sheet must stay encrypted.

SMART PRESETS

Start from a proposal template that already matches the operating path.

These presets only prefill the existing builder fields. They do not sign, submit, or bypass any on-chain validation. Use them to move faster without losing clarity around ZK, REFHE, MagicBlock, or treasury execution.

Preset ready: Standard Treasury Grant

DAO PDA

TITLE

DURATION (SECONDS)

TREASURY RECIPIENT

TREASURY AMOUNT (SOL)

CONFIDENTIAL PAYOUT TYPE

SETTLEMENT RECIPIENT

PAYOUT ASSET

PAYOUT TOTAL

RECIPIENT COUNT

PAYOUT TOKEN MINT

MAGICBLOCK PRIVATE PAYMENTS

MAGICBLOCK OWNER WALLET

DESCRIPTION

ENCRYPTED MANIFEST URI

MANIFEST HASH (32-BYTE HEX)

CIPHERTEXT HASH (32-BYTE HEX)

REFHE MODEL URI

REFHE POLICY HASH (32-BYTE HEX)

REFHE INPUT HASH (32-BYTE HEX)

REFHE EVALUATION KEY HASH (32-BYTE HEX)

MAGICBLOCK API BASE

yarn create-proposal -- --dao <DAO_PDA> --title "Fund community work"

Best practice for multi-DAO operation: choose the DAO from the filter above, confirm the DAO PDA field matches that DAO, then create the proposal from a wallet that holds that DAO governance token. Confidential payout batches are configured immediately after proposal creation, using only the encrypted batch manifest, hashes, settlement account, and aggregate amount. Add REFHE inputs only when this proposal must bind encrypted payroll or bonus evaluation to a proposal-scoped on-chain envelope before execution.

FRONTIER BUILDER ADVISOR

Choose the right activation path before signing.

This advisor reads the current builder inputs and explains whether ZK, REFHE, MagicBlock, and the backend-indexer RPC path are recommended, optional, or not needed for the proposal you are about to create.

GENERAL

OPTIONAL

Use the ZK layer when the proposal will benefit from the stronger review path or zk_enforced finalize route.

REFHE

NOT NEEDED

REFHE only matters for confidential payroll, bonus, or grant flows that require encrypted evaluation before execution.

MAGICBLOCK

NOT NEEDED

MagicBlock is only relevant for confidential token payout plans that should not execute without private-payment corridor settlement.

RPC FAST / READ NODE

OPTIONAL

The builder will still work on direct RPC, but backend-indexed reads provide a cleaner reviewer and operator experience when available.

Confidential Payouts Payroll Flow Diagram Frontier Guided Flow MagicBlock Private Payments REFHE Protocol REFHE Operator Flow

Advanced governance console

Delegation and combined-weight commit stay available as advanced proposal-scoped flows. They are grouped separately so the main DAO path remains clear.

ADVANCED — DELEGATE VOTE

yarn delegate-vote -- --proposal <PROPOSAL_PUBKEY> --delegatee <DELEGATEE_PUBKEY>

ADVANCED — COMMIT DELEGATED VOTE

yarn commit -- --proposal <PROPOSAL_PUBKEY> --vote yes --delegator <DELEGATOR_PUBKEY>

OPERATOR NOTES

Keep operation, verification, and escalation separate.

This page is for running the governance lifecycle. Proof Center, Security, and Diagnostics stay available for verification without taking over the main operating workspace.

OPERATE HERE

1. Bootstrap the DAO and treasury.

2. Create a proposal from a wallet that holds governance tokens.

3. Commit, reveal, finalize, and execute only in the valid phase.

4. Use advanced delegation only when the base path is already clear.

VERIFY ELSEWHERE

Keep runtime depth and security evidence in their own surfaces so the core product flow stays fast, readable, and safe to operate.

Runtime Panel

VERIFICATION FLOW

Fast path to reproduce
the real governance cycle.

1) Connect a Solana wallet such as Phantom, Solflare, or Backpack on Devnet.

2) Review the selected proposal and its current on-chain phase from this surface.

3) Reproduce the lifecycle with the repo or wallet-native paths: create proposal → commit → reveal → finalize → execute.

4) Verify phase transitions, treasury effects, and transaction hashes against Solscan.

5) Run npm run demo for the repository walkthrough and npm run verify:all for the full review gate.

The product surface and the repository are intentionally aligned: the frontend explains and signs, while the protocol, scripts, proofs, and verification gates provide the hard evidence.

TRUST LAYER

Runtime depth, security reasoning,
and release evidence.

🔒 ZK Companion

START HERE

Operate the live product

Use the live app, inspect the selected proposal flow, and confirm the deployed program path before diving into evidence depth.

THEN VERIFY

Read runtime and security evidence

Move from operational state to stress, adversarial, replay, integrity, and ZK review paths without leaving the curated proof surface.

END WITH RELEASE

Review readiness and transition

Mainnet readiness, release ceremony, canary, and production-boundary artifacts stay grouped here instead of competing with daily product use.

Depth without losing the product path

Trust Layer is the second layer of the product. Use it when you need runtime evidence, trust reasoning, and release depth without pushing that density back into the main governance workspace.

PRODUCT DEPTH

LIVE PRODUCT

Operate and verify the system

Start from the live app, inspect the program on Solscan, and use the Devnet lifecycle proof as the canonical operational path.

Live App Review Surface Program on Solscan Live Devnet Proof Confidential Payouts Payroll Flow Runtime Panel Release Manifest

STRESS AND RUNTIME

Inspect runtime behavior under load

These reports show the 50-wallet lifecycle run, proposal isolation, race handling, RPC recovery, runtime captures, and explorer-visible transaction evidence.

50-Wallet Load Report Multi-Proposal Report Race Report Resilience Report Operational Evidence Runtime Evidence Real-Device Runtime Evidence MagicBlock Runtime Evidence ZK-Enforced Runtime Evidence TX Registry Adversarial Report Performance Metrics

SECURITY AND ZK

Read the trust model directly

Security reasoning, replay analysis, ZK companion layers, and artifact integrity stay grouped here instead of being mixed into the product surface.

Security Review Payout Audit Scope Threat Model Failure Modes Replay Analysis ZK Layer ZK Stack ZK Capability Matrix ZK Proof Registry Artifact Integrity Cryptographic Manifest

MAINNET AND RELEASE

Track the path from Devnet to production

Mainnet readiness stays visible, but isolated from the main operating surface. This keeps the product usable while preserving audit-grade release evidence.

AWARD

1st Place — Superteam Poland

PRODUCT FOCUS

Private voting · confidential payouts · runtime assurance

PROGRAM ID

5AhUsbQ4mJ8Xh7QJEomuS85qGgmK9iNvFqzF669Y7Psx

DEVNET LOAD TEST

50 wallets · 212 attempts · 32 expected rejects · 3 ZK anchors

50-Wallet Devnet Stress Package

PrivateDAO now includes a reproducible multi-wallet Devnet harness covering bootstrap, wave-based commits, reveals, finalize, execute, adversarial rejection paths, and Groth16 companion proofs with explorer-verifiable transaction evidence.

MULTI-WALLET EVIDENCE

35 voter wallets

10 adversarial wallets

5 zk tester wallets

Wave-based execution with retries

Three live proposals isolated in one DAO

Single-winner finalize and execute races

RPC failover and stale-blockhash recovery

Duplicate and replay rejection evidence

Treasury and lifecycle invariants preserved

Open Load Test Report Open Operational Evidence Open Multi-Proposal Report Open Race Report Open Resilience Report Open TX Registry Open Adversarial Report Open ZK Proof Registry

Live Transaction Timeline

This is the real devnet governance proof sequence for PrivateDAO. It shows the full lifecycle from deployment to treasury execution with direct explorer verification on every step.

REAL TX HASHES

DEPLOY

Program deployment on Solana devnet.

2CMEujY1CKnC8rH8BuLy4GvwYk3zfqMfAKaUjybcAvRhS1dnzg3Zd3GeMttBp4vkUbu69GkQtr3TWgbmBqGY8cyC

Open Deploy TX

CREATE DAO

Bootstraps the governance state and treasury.

5mcyVi3SbZo4hvpVMjH2eZH8FYeywdbbPz4ArmE5wHXH5X9EnP6gSq76ogBWYWVkVUwzrCchPnSdhGV1mFb48s5Q

Open Create DAO TX

GOVERNANCE BALANCE / DEPOSIT

The verification wallet reused its existing PDAO balance for voting, then funded the treasury for the live run.

reused-existing-governance-balance KHWqfteEQhsH7hk7onQymbmnYdtF8rLoPWwchoQz5XFy8eY3DufeaX8DPiiVS1or7XkMVjMrbH2rsEhPtrPfzi9

Existing PDAO balance reused Open Deposit TX

PROPOSAL / COMMIT / REVEAL

The private voting path is visible as real transaction evidence.

E93ikMXVJbtvz8ewAHA2BasZPVKYyUXe3Jy88h3b3AQubm7PSYFMNtDveBkRts7uYodwzb8cGZSVDoneKF16X2L 3RMbrcYGx297hgcTrov9PqtUqM97ZFg6A21qxmepTboLQAoXov6toY2QTa8yU1i8zmQPvjR3ArNGpvR3jat79uTP 5L3cxZZgwMRnJTxNXLQCyjQMXSAi6bwoskFoKsfaQ7JycYUPuGCkWAkr7qA18WkddfNdSPB5qHt3FVSiHq2eDGh5

Open Proposal TX Open Commit TX Open Reveal TX

FINALIZE / EXECUTE

Proof that the governance result finalized and treasury execution completed on-chain.

4JSPRJQuSY5es74TcChBTzuGMMCr4RknHkmr6vFmtmbav4TRABDAnapmtgipYioEZzh4wmKfg2PMzZHCfJ7UruLG x1vhP6H3Regi6WHYx6LUGbeo4CCbJxWwtUVucPVjonnymyccpM8mpb7t3UpQpqksXBU7PYGPd86cPnZLYwRzBn9

Open Finalize TX Open Execute TX

ZK PROOF ANCHORS

Proposal-bound proof anchors now land on-chain. Solscan can show vote, delegation, and tally zk material as real Devnet transactions.

3L6SHDNuziEXQiiAWjega4UbjURkWpzYVG5kRKr4YWAekp1AdTvriMqNAtyRchNpzKstEPMp6cmDidFLRx8XDgfP 4nYrBo57V6fCueyu44Jm9XeSA15ti9G6n1ZQXG9AbsdT4e5JJa9vFdmdjpK6Snd27eJNwUSaNaCWWWt3bndTca3X WTt8i2v1FWitQG2yye28CVCVWVeKvMA7c3D9wm4Upkbf2keK8ae8FXaGK95FaDjnmfJB3L7evBCMtoJrfC3EUrV

Open Vote Anchor Open Delegation Anchor Open Tally Anchor

FULL ARTIFACT

The repository note captures commands, states, balances, and all explorer links in one audit trail.

docs/live-proof.md

Open Live Proof Note

Dedicated V3 Hardening Proof

The baseline treasury lifecycle proof remains live, and the repository now also carries a dedicated Devnet packet for the additive `Governance Hardening V3` and `Settlement Hardening V3` paths.

V3 DEVNET PROOF

WHAT THIS PROVES

A dedicated Devnet artifact proves `token-supply quorum`, the `reveal rebate vault`, proposal-scoped settlement policy snapshots, REFHE-bound settlement, and verified settlement evidence consumption in the stricter additive path.

GOVERNANCE V3

Use this surface when you need the stronger quorum and rebate model, not only the legacy or V2 lifecycle proof.

Open Governance Hardening V3 Open Live Proof V3

SETTLEMENT V3

Use this surface when the review question is about stricter payout caps, evidence aging, REFHE gating, or single-use settlement consumption.

Open Settlement Hardening V3 Open Live Proof V3

BOUNDARY

This is a real Devnet proof for the additive hardening path. It is not a production-custody or mainnet real-funds claim.

Open Mainnet Blockers Open Launch Trust Packet

Production readiness snapshot

The current stack is already beyond concept stage. The remaining work for mainnet is operational discipline and external review, not redesign of the core governance model.

DEPLOYMENT GRADE

PROGRAM LOGIC

Commit, reveal, finalize, cancel, veto, and execute are already implemented on-chain.

LIVE OPERATOR FLOW

Repository scripts emit real transaction signatures and explorer links instead of hidden local-only behavior.

FRONTEND SURFACE

The published UI reads live proposal accounts, shows phase-aware state, and builds real lifecycle commands.

Mainnet blockers are operational: external audit depth, deployment ceremony, monitored RPC, and production key handling.

Core protocol blockers are not the issue: lifecycle correctness, treasury execution, and proposal proof surfaces are already working end to end.

Reviewer takeaway: this is a live governance product with a credible path to production, not a prototype that still needs its protocol invented.

Submission standard: every future competitive submission should ship with the same density of proof, links, and executable operator flows.

INVESTOR REEL

A short investor-facing reel aligned to the live product surface.

The strongest PrivateDAO review flow is not a claim-only narrative. It starts with a short investor reel, then lands immediately on the real on-chain and repo-native proof surface.

WATCH

Repo-native MP4: Direct asset

Pitch deck: Investor / Competition Deck

Poster: Preview image

YouTube reference: cwsPpNLiwbo

SUPPORTING NOTES

Competition roadmap: Roadmap

Strategy documentation: Strategy Documentation

Risk policy: Risk Policy

Judge audit note: Technical Audit

Security architecture: Architecture Diagram

Submission registry: Submission Registry

Audit packet: Audit Packet

Operational Proof Paths

These links and commands tie the presentation layer to the real repository behavior without hiding behind simulated actions.

ON-CHAIN VERIFIED

END-TO-END LIVE FLOW

Runs a real devnet lifecycle and prints transaction hashes plus explorer links.

npm run live-proof

LOCAL DEMO

Runs the repository demo through the test harness.

npm run demo

CREATE PROPOSAL

Governance-token holder creates a proposal on-chain.

DAO_PDA=... && yarn create-proposal -- --dao "$DAO_PDA" --title "Fund community work"

EXECUTE

Treasury execution remains behind finalize plus timelock.

PROPOSAL_PUBKEY=... && yarn execute -- --proposal "$PROPOSAL_PUBKEY"

Production Simulation And Startup Packs

These documents turn the protocol into clear operating stories for judges, pilot users, and early customers without inventing features that do not exist on-chain.

GO-TO-MARKET READY

PRODUCTION SIMULATION DAO

The clean canonical walkthrough for `Create DAO -> Submit proposal -> Private vote -> Execute treasury`.

Open Production Simulation DAO

USE CASE PACKS

Grant committee, fund governance, gaming DAO, and enterprise DAO product stories built on the same protocol surface.

Use Case Packs Grant Committee Pack Fund Governance Pack Gaming DAO Pack Enterprise DAO Pack

TRUST / MIGRATION / PILOT

Operator-facing startup material for onboarding, trust framing, migration, pricing, SLA, and pilot execution.

Operator Guide Trust Package Migration Story Pilot SLA Pricing Model Pilot Program

REAL DEMO VIDEO

One lifecycle-first demo asset focused on the real product flow, not only an investor reel.

Demo Video Brief MP4 Asset Poster

API, operator, and migration services

PrivateDAO is not only an application surface. It can also be packaged as a hosted read path, migration program, reviewer export layer, and guided pilot service for organizations that need governance operations support.

SERVICE CATALOG

BUYER PATH

Pilot first, not vague enterprise theater

PrivateDAO is positioned as a guided rollout: prove the lifecycle on Devnet, scope the operating boundary, then move into stronger custody and launch readiness.

COMMERCIAL PACKS

Four ways to buy the product surface

Pilot Package

Hosted Read API + Ops

Confidential Operations Premium

Enterprise Governance Retainer

BEST FIT

Who should move first

Grant committees, crypto-native funds, gaming DAOs, and enterprise-style treasury operators that already feel the cost of public signaling.

NEXT STEP

Pick a buying path, then open the exact packet

Use the pricing model, pilot program, SLA, and onboarding playbook together. The surface stays honest: documents are ready even where production rollout is still pending-external.

PILOT PACKAGE

The cleanest commercial entry. One real governance workflow, one treasury action type, operator training, evidence review, and launch blockers captured before any mainnet commitment.

Pilot SLA Pilot Onboarding

HOSTED READ API + OPS

For teams that want the product surface plus backend-indexed reads, operator snapshots, pooled RPC reliability, and reviewer export workflows without building their own governance ops layer first.

Read Node RPC Architecture

CONFIDENTIAL OPERATIONS PREMIUM

For organizations that need more than private voting: encrypted manifests, confidential payroll or bonus plans, REFHE review boundaries, MagicBlock settlement hints, and stronger trust packaging.

Confidential Payments REFHE MagicBlock

ENTERPRISE GOVERNANCE RETAINER

For serious operators that want governance configuration, security readiness, operator runbooks, migration planning, trust packaging, and periodic review support wrapped into one operating relationship.

Trust Package Operator Guide

HOSTED READ API

Backend-indexed proposal reads, pooled RPC access, diagnostics, and operator snapshots for teams that want reliable governance visibility.

Service Catalog Read Node RPC Architecture

REVIEW EXPORTS

Evidence bundles, judge packets, audit-oriented runtime exports, and trust packaging for grants, internal approvals, and pilot reviews.

Trust Package Launch Trust Packet Audit Packet

REALMS MIGRATION SERVICE

Migration planning, governance token mapping, voter-weight compatibility, and continuity documentation for communities moving from Realms-oriented governance into private voting.

Migration Story Pilot Program

PILOT AND OPERATOR SUPPORT

Onboarding, runbooks, operator training, monitoring expectations, and scoped service levels for organizations that want a guided rollout.

Pilot SLA Pricing Model Pilot Onboarding

Buyer Journey And Operating Fit

This is the shortest honest story for an investor, judge, or pilot customer: who should buy PrivateDAO, why it exists beyond Realms or Squads alone, what happens in the first 30 days, and what is already live versus still pending-external before real-funds launch.

BUYER JOURNEY

WHO THIS IS FOR

Organizations hurt by public signaling

Grant committees, crypto-native funds, gaming DAOs, and enterprise-style operators that already feel the cost of open treasury signaling, exposed intent, and weak internal governance privacy.

WHY NOT REALMS OR SQUADS ALONE

PrivateDAO is the privacy and execution layer on top of treasury discipline

Realms and Squads remain strong references for governance and treasury control. PrivateDAO exists where private voting, confidential operations, ZK review overlays, proposal-bound settlement evidence, and reviewer-grade runtime packaging matter together in one product.

FIRST 30 DAYS

Pilot, prove, train, then decide

Week 1: choose one governance workflow and one treasury action type

Week 2: run Production Simulation DAO on Devnet and capture evidence

Week 3: train operators, define signer model, and review launch blockers

Week 4: decide on extended Devnet, pilot continuation, or mainnet prep

LIVE NOW VS PENDING-EXTERNAL

Strong live Devnet product, honest mainnet boundary

Live now: DAO lifecycle, confidential payout surface, ZK anchors, REFHE and MagicBlock integration paths, RPC-backed reviewer flow

Pending-external: multisig custody ceremony, authority transfer, external audit closure, real-device capture matrix, final mainnet cutover

TRUST THE BOUNDARY

The product page is allowed to sell the operating story, but it is not allowed to pretend that pending-external launch work is already complete. The linked trust and blocker packets keep that boundary explicit.

Trust Package Mainnet Blockers Launch Trust Packet

ACT LIKE A PRODUCT

Use the packs and guided flow to start from a customer problem first, not from protocol archaeology. The protocol remains real underneath, but the first interaction should feel like choosing an operating path.

COMMERCIAL CHECKOUT RAIL

The first month should feel operationally clear, not fuzzy. This rail keeps the buyer story grounded in deliverables instead of generic enterprise language.

WEEK 1

Scope one governance flow

Choose one DAO workflow, one treasury action, and one operating pack.

WEEK 2

Run the production simulation

Execute Create DAO, Submit proposal, Private vote, and Execute treasury on Devnet.

WEEK 3

Train operators and review trust

Walk through runbooks, trust package, monitoring expectations, and signer model.

WEEK 4

Decide next custody step

Continue Devnet, extend pilot, or begin multisig and audit preparation.

REQUEST PILOT PACKET

Copy a ready-to-send pilot packet with the exact links a buyer, partner, or evaluator needs: pilot program, pricing, SLA, trust package, onboarding playbook, and production simulation DAO.

THE PROTOCOL

How PrivateDAO works
in one operating flow.

1. Commit privately

Voters submit a sha256 commitment bound to vote, salt, proposal, and wallet. The chain stores proof of intent, not the visible vote itself.

2. Reveal deterministically

After the commit window ends, the on-chain program recomputes the commitment from the reveal payload and counts only valid proposal-scoped reveals.

3. Execute safely

A passed proposal still cannot move treasury funds until finalize succeeds and the timelock expires. Execution remains explicit, not implicit.

01 🔒

COMMIT

During voting, every voter submits a cryptographic hash. The chain stores commitments — not votes. Tally shows 0/0 to everyone.

// Commitment = sha256(vote‖salt‖proposal‖pubkey) commitment[32] = sha256( vote_byte, // YES=1 NO=0 salt[32], // random, kept private pubkey[32] // prevents replay ) // Stored on-chain. Vote is hidden. // Proposal scoping is enforced by the VoteRecord PDA.

02 🔓

REVEAL

After voting ends, voters prove (vote, salt). The program recomputes the hash on-chain. Match means the vote is counted, and the revealer can receive the configured rebate if the proposal account stays rent-safe.

// On-chain verification sha256(vote‖salt‖proposal‖pubkey) == stored_commitment → vote counted ✓ → rebate: +0.001 SOL (proposal account only) // Authorized proposal-scoped keeper can reveal if you forget

03 ⚡

EXECUTE

After reveal window closes, anyone finalizes. If the proposal passed, treasury execution becomes available only after the timelock expires.

finalize() → PASSED | FAILED ↓ timelock: 86400s (24h) ↓ execute() → treasury action SendSol | SendToken | CustomCPI(event relay)

OPERATING CAPABILITIES

Governance features that stay tied
to the live product.

⚖️

DualChamber Voting

Both capital chamber (token-weighted) AND community chamber (quadratic √balance) must independently pass. Whales need genuine community support to push proposals through.

GOVERNANCE MODE

🤝

Private Delegation

Delegate your voting weight to any address for a specific proposal. The delegatee commits the combined weight. The vote remains hidden during voting, and the delegation is single-use per proposal.

PROPOSAL-SCOPED

🤖

Keeper Auto-Reveal

Authorize a proposal-scoped keeper address at commit time. If you forget to reveal, the keeper can submit your exact proof during the reveal window and earn the rebate. Browser flows generate salts in memory and require you to save them yourself.

OPTIONAL FLOW

🔌

Three Voting Modes

TokenWeighted (raw balance), Quadratic (√balance under an external sybil-resistance policy), or DualChamber (both must pass). DAOs choose their governance model at creation, not after.

DAO POLICY

REALMS MIGRATION

Move a governance community
without losing continuity.

What this path does

PrivateDAO can bootstrap a new DAO from Realms-oriented governance context while preserving clear ownership, governance-token intent, and a migration-friendly narrative.

What it does not claim

This is not presented as a magical one-click replacement for every Realms workflow. The migration surface stays explicit about what is supported and what remains separate work.

How to use it

Review the migration path first, then fill the form to generate the exact repo-native command for the authority wallet and governance token configuration you want.

MIGRATE
WITH CLEAR
BOUNDARIES.

PrivateDAO includes a Realms-oriented migration path and a voter-weight record account. The current repo is built to preserve governance provenance and support migration-friendly adoption, not to claim a full drop-in replacement for every Realms workflow.

Connect your Realms DAO authority wallet The migration helper is designed to be non-destructive and governance-token aware.

Run migrate_from_realms instruction Creates a PrivateDAO with the chosen governance token and records the source Realms governance address.

Use the voter-weight record path where it fits your setup The repo includes a Realms-style voter-weight account path, while full end-to-end lifecycle coupling remains separate work.

All future votes are now private Commit-reveal privacy, timelock discipline, and treasury checks are available without pretending migration complexity disappears.

REALMS MIGRATION PACKS

Start from the migration profile that matches the organization you are moving.

These presets only configure the migration helper and next-step guidance. They do not submit transactions or claim full Realms replacement. They exist to shorten the path from migration intent to an exact PrivateDAO bootstrap command.

Preset ready: Community Treasury

MIGRATION FORM

Configure Your Migration

REALMS GOVERNANCE PUBKEY

DAO NAME

GOVERNANCE TOKEN MINT

QUORUM (%)

MIGRATION COMMAND

Fill the fields above to generate the exact migration command for this DAO.

NEXT STEP GUIDE

What to do immediately after migration.

Community treasury migrations should usually start with DAO bootstrap, a standard treasury grant flow, and the cleanest create → vote → execute lifecycle before adding confidential layers.

COMMUNITY TREASURY

FIRST FLOW

STANDARD DAO

Start with DAO bootstrap, treasury funding, and a standard treasury proposal to preserve operator clarity.

REALMS FIT

MIGRATION READY

Use the Realms governance pubkey only to preserve continuity and provenance. Do not assume total workflow parity on day one.

PRIVATE LAYERS

LATER

Keep advanced layers optional at migration start unless the operating use case is already sensitive enough to require them.

PACK DOC

OPEN

Open the matching pack, then use the generated migration command and the storefront builder below.

SECURITY

Make private governance
defensible, not cosmetic.

Lifecycle enforcement

PrivateDAO rejects out-of-order lifecycle actions. Reveal, finalize, and execute remain bound to the correct phase and proposal state.

Treasury execution safety

Recipient, mint, signer, PDA, and treasury wiring checks prevent governance success from turning into unsafe treasury mutation.

ZK and integrity layers

Groth16 companion proofs and the published sha256 artifact manifest add verification depth without replacing the deployed on-chain enforcement boundary.

Why PrivateDAO Exists

Public governance leaks intent too early. PrivateDAO counters that with commit-reveal voting, lifecycle enforcement, timelocked execution, treasury validation, and replay-resistant bindings.

SECURITY FIRST

CORE REQUIREMENT

Exploit resistance is part of the product, not optional hardening.

WHY IT MATTERS

If lifecycle, signer binding, or treasury execution can be manipulated, privacy becomes cosmetic rather than protective.

REVIEWER PATH

Two minutes from this page. Five minutes from the repository.

Reviewer Clarifications

These are the protocol boundaries most likely to be misunderstood in partial scans, kept explicit in one place.

TRUTH-ALIGNED

PROGRAM ID

PrivateDAO keeps one canonical governance program id: 5AhUsbQ4mJ8Xh7QJEomuS85qGgmK9iNvFqzF669Y7Psx. The separate Token-2022 id belongs to the live PDAO mint surface only.

BROWSER SALTS

Browser-native commit flows generate salts in memory and ask the voter to save or export them. This surface does not persist salts in localStorage or sessionStorage.

REPLAY SCOPING

The raw commitment hash binds vote, salt, proposal key, and voter key. Cross-proposal replay is rejected both cryptographically and through proposal-scoped VoteRecord accounts, reveal bindings, and lifecycle flags.

REBATE SOURCE

Reveal rebate is paid from the proposal account only when that account remains rent-safe. The DAO treasury is not the rebate source.

Verified Protections

These are not abstract claims. They are protocol-level protections tied to tests, bindings, and failure-path assertions already present in the repository.

TESTED

LIFECYCLE SAFETY

No reveal before commit. No finalize before reveal end. No execute before timelock. No duplicate execute.

TREASURY SAFETY

Recipient, mint, ownership, and treasury source wiring are validated. Miswired token paths are rejected.

COMMIT-REVEAL INTEGRITY

Invalid reveal payloads, mismatched salts, wrong signers, and cross-proposal vote-record misuse are rejected.

ACCOUNT BINDING

DAO/proposal/delegation/treasury bindings are exact. Valid-looking but semantically wrong accounts are rejected.

ZK Companion Layer Available

PrivateDAO now includes a real zero-knowledge companion stack built with Circom and Groth16. It does not replace the deployed governance lifecycle; it adds vote-validity, delegation-authorization, and tally-integrity proof layers as a non-breaking companion path for the current system.

REAL ZK

WHAT IS LIVE

Real circuit compilation, witness generation, proof generation, and proof verification are now part of the repository across multiple zk layers.

CURRENT VS ZK-AUGMENTED

Current PrivateDAO still runs the deployed commit-reveal lifecycle. The zk path augments it with proof-backed validity and eligibility checks without changing the live protocol surface.

WHY IT IS SAFE

The zk layer is additive. It does not change contracts, instruction interfaces, PDA derivations, or the current browser governance flow.

VOTE LAYER

Boolean vote form, minimum-weight eligibility, proposal-scoped commitment binding, and proposal-scoped nullifier binding.

DELEGATION LAYER

Delegation activation, delegatee binding, delegated-weight commitment, and proposal-scoped delegation nullifier binding.

TALLY LAYER

Deterministic weighted yes/no tally proofs over a commitment-consistent reveal sample plus a public nullifier accumulator.

HOW TO VERIFY

npm run zk:all rebuilds and verifies the full zk sample flow from this repository.

ARTIFACT INTEGRITY

npm run verify:cryptographic-manifest verifies the sha256 manifest covering zk artifacts, live-proof anchors, and canonical proof materials.

CAPABILITY MATRIX

Open the capability matrix to see what is live now, what is verified, and what is intentionally not claimed.

PROVENANCE

Open zk provenance for the proving-system, ptau, and artifact-traceability layer.

ATTESTATION

Open zk attestation for the machine-readable registry and transcript summary bound to the live proof stack.

PER-LAYER REVIEW PATH

npm run build:zk-transcript
npm run build:zk-attestation
npm run verify:zk-transcript
npm run verify:zk-attestation
npm run verify:zk-docs
npm run verify:zk-consistency
npm run verify:zk-negative

Zero-Knowledge Protection

PrivateDAO publishes Groth16 zk-SNARK companion proofs for vote, delegation, and tally review. Proof generation and verification remain additive and off-chain, while proposal-bound proof anchors are now recorded on-chain for the canonical Devnet path.

PrivateDAO Governance Token (PDAO)

The PrivateDAO Governance Token enables structured participation, protects governance lifecycle integrity, and supports accountable decision-making.

GOVERNANCE TOKEN

Core roles:

• Enables proposal participation

• Supports voting authority

• Aligns treasury governance

• Prevents governance spam

• Anchors long-term ecosystem participation

NAME

PDAO

NETWORK

Devnet

UTILITY

Governance Voting Token

PLATFORM

DeAura

MINT

AZUkprJDfJPgAp7L4z3TpCV3KHqLiA8RjHAVhK9HCvDt

PROGRAM

Token-2022

INITIAL SUPPLY

1,000,000 PDAO

TOKEN ACCOUNT

F4q77ZMJdC7eoEUw3CCR7DbKGTggyExjuMGKBEiM2ct4

VERIFIED TXS

create-token, create-account, initialize-metadata, mint-initial-supply, disable-mint-authority

BOUNDARY

The protocol still supports DAO-configured governance mints. The current canonical Devnet DAO now uses PDAO itself as the live governance mint.

MINT AUTHORITY

Disabled on-chain after initial supply and metadata setup.

PROGRAM BOUNDARY

PrivateDAO keeps one canonical governance program id. The separate Token-2022 id belongs to the live PDAO mint surface and is expected.

TOKEN NOTE

Open the token architecture note for the governance model, then open the live PDAO token note for the final Devnet mint details and signatures.

ATTESTATION

Open the generated PDAO attestation for the machine-readable token identity, metadata, and program-boundary surface. The published metadata asset is available here.

Cryptographic Integrity

ZK proves validity. Cryptographic integrity proves the review artifacts themselves have not been altered. PrivateDAO publishes a reviewer-visible sha256 manifest for the canonical zk and proof surfaces.

SHA256

WHAT IS HASHED

The published manifest covers the zk circuit, verification key, sample proof, public inputs, proof registry, devnet release manifest, live proof, submission registry, and the canonical review notes.

WHY IT MATTERS

Reviewer-facing artifacts become tamper-evident. The same surface used for judging can be verified directly instead of being trusted as static prose.

REVIEWER-VISIBLE MANIFEST

Open the published manifest and inspect the sha256 fingerprints directly.

HOW TO VERIFY

npm run build:cryptographic-manifest
npm run verify:cryptographic-manifest
npm run verify:all

Security Evidence

These curated review paths keep the reasoning artifacts grouped by purpose so the security surface reads like an audit path, not a document dump.

FORMAL DOCS

CORE SECURITY

Review protocol reasoning

Start here for the main trust model, lifecycle boundaries, replay rejection, and failure-path coverage.

Security Review Threat Model Coverage Map Failure Modes Replay Analysis Fair Voting Model

ZK AND INTEGRITY

Inspect the companion proof stack

These links cover the additive Groth16 layers, their assumptions, provenance, transcript, and artifact-integrity binding.

ZK Layer ZK Stack Capability Matrix Verification Flow Provenance ZK Registry ZK Transcript ZK Attestation ZK Architecture ZK Evidence Artifact Integrity Manifest

RUNTIME AND OPERATIONS

Review how the product behaves

Runtime evidence, wallet diagnostics, operational traces, and release discipline remain accessible here without flooding the main product flow.

Wallet Diagnostics Wallet Runtime Real-Device Runtime QA Real-Device Runtime Evidence MagicBlock Runtime Evidence ZK-Enforced Runtime Evidence Runtime Evidence Operational Evidence Strategy Operations Wallet Compatibility Matrix Devnet Canary Devnet Scale Profiles Production Ops Monitoring Incident Response Review Automation

MAINNET TRANSITION

Track the production path

These artifacts show what is ready in-repo, what is operationally pending, and how PrivateDAO moves from Devnet proof to production launch discipline.

Verified Protection Checklist

This is the shortest path for a reviewer to understand what the protocol actively rejects today.

CHECKLIST

✅ Rejects reveal before commit

✅ Rejects invalid reveal payload

✅ Rejects signer misuse

✅ Rejects treasury miswiring

✅ Rejects cross-proposal delegation misuse

✅ Rejects duplicate execution

✅ Preserves state on failed finalize and execute

✅ Enforces exact proposal, DAO, delegation, and treasury bindings

Architecture And Trust Model

The protocol is not a decorative frontend. Security depends on the on-chain state machine, wallet signatures, exact account binding, and treasury PDA enforcement.

ON-CHAIN

LIFECYCLE

Create Proposal
→ Commit
→ Reveal
→ Finalize
→ Timelocked Execute

TRUST SURFACE

Wallet signer
→ Proposal accounts
→ Voter records
→ Delegation records
→ Treasury PDA
→ On-chain program

Known Limitations

Reviewer confidence increases when limits are explicit. These are current boundaries, not hidden assumptions.

HONEST LIMITS

CURRENT BOUNDARIES

Devnet-first deployment.
Direct-commit versus delegation overlap is rejected on-chain through proposal-bound marker accounts.
Quadratic weighting still assumes an external sybil-resistance policy.
Commit-reveal hides vote content, not transaction timing metadata.
`CustomCPI` remains intentionally unsupported rather than arbitrary on-chain CPI.
The current Groth16 proof stack still verifies off-chain, while proposal-bound on-chain proof anchors are now live on Devnet.
Mainnet audit completeness is not claimed.

REVIEW FILES

`docs/security-review.md`
`docs/threat-model.md`
`docs/security-coverage-map.md`
`docs/failure-modes.md`
`docs/replay-analysis.md`

THREAT MODEL

Threats reduced by
specific on-chain checks.

ATTACK VECTOR	PUBLIC VOTING	PRIVATEDAO	MECHANISM
Real-time tally tracking	✗ Trivial	✓ Impossible	Commitment hides vote
Vote buying via tally watching	✗ Common	✓ No tally to watch	0/0 during voting
Whale intimidation	✗ Systemic	✓ No visible pressure	DualChamber + hidden tally
Treasury MEV / front-running	✗ Common	✓ Reduced, not eliminated	Hidden tally + timelock
Commitment replay attack	✗ N/A	✓ Proposal + pubkey bound	sha256(v‖s‖proposal‖pubkey)
Flash loan manipulation	✗ Common	✓ Weight at commit time	Snapshotted on commit
Malicious proposal execution	✗ Instant	✓ 24h veto window	Timelock + authority veto
Brute-force commitment	N/A	✓ 2²⁵⁶ combinations	32-byte random salt

What this panel checks

Diagnostics inspects wallet connection state, provider detection, browser capabilities, backend read-path availability, RPC health, and the live PrivateDAO anchors that matter for runtime trust.

When to use it

Use this page when a wallet fails to connect, an RPC looks unstable, or you need a reviewer-friendly runtime snapshot tied to the current browser session.

What it produces

The panel generates a snapshot of the current runtime state that can be copied directly and linked back to the wider runtime-evidence and real-device review package.

Wallet Diagnostics

Live runtime checks for wallet state, browser capabilities, RPC health, and the current PrivateDAO anchors. This is a browser-side control panel, not a static note.

LIVE RUNTIME

CONNECTED PROVIDER

Not connected

CONNECTED WALLET

Not connected

RPC HEALTH

Pending refresh

READ PATH

Direct RPC

REFHE BACKEND

Pending refresh

MAGICBLOCK

Pending refresh

350-WALLET PROFILE

Pending refresh

READ NODE METRICS

Pending refresh

PROGRAM ID

5AhUsbQ4mJ8Xh7QJEomuS85qGgmK9iNvFqzF669Y7Psx

PDAO MINT

AZUkprJDfJPgAp7L4z3TpCV3KHqLiA8RjHAVhK9HCvDt

GO-LIVE CHECKLIST

Open go-live checklist

AUTHORITY HARDENING

Open authority hardening path

MULTISIG INTAKE

Open multisig setup intake

MAINNET BLOCKERS

Open production blocker register

READINESS REPORT

Open generated readiness report

GO-LIVE ATTESTATION

Open go-live attestation

RUNTIME ATTESTATION

Open runtime attestation

PHASE C HARDENING

Open zk enforcement hardening path

VERIFIER STRATEGY

Open verifier strategy

READ NODE

Open read-node and indexer path

READ NODE SNAPSHOT

Open generated read-node snapshot

OPS SNAPSHOT

Open generated ops snapshot

SAME-DOMAIN DEPLOY

Open same-domain deploy path

GO-LIVE SNAPSHOT

This panel compresses the current mainnet decision boundary into one operator-facing view. It distinguishes what is already strong inside the repository from what still remains external before any real cutover.

REPOSITORY GATES

INTERNAL PASS

Frontend, submission registry, generated artifacts, review surfaces, cryptographic manifest, and operational evidence are already bound into the repo surface.

REAL-DEVICE WALLET QA

EXTERNAL BLOCKER

Mainnet language should stay conservative until Phantom, Solflare, Backpack, Glow, and Android captures are recorded as real signer evidence.

AUTHORITY HARDENING

MULTISIG REQUIRED

Upgrade authority, treasury operations, and token administration still need their final production custody path before any cutover should be called acceptable. The repository now defines the intake shape, but the multisig remains pending until public signer keys, timelock configuration, transfer signatures, and authority readouts exist. See Authority Hardening and Multisig Setup Intake.

STARTUP LAUNCH OPS

TRACKED, NOT CLEARED

Launch operations are documented and machine-checked in the repo, but production monitoring, real-device wallet captures, and legal/audit closure remain external evidence gates. See Launch Ops Checklist, Monitoring Alert Rules, and Wallet E2E Test Plan.

EXTERNAL AUDIT

PENDING

The repository is hardened and reviewable, but it should not be presented as mainnet-cleared until external audit work is completed and findings are closed.

ZK PHASE C

HARDENING REQUIRED

`zk_enforced` is live in parallel, but it is not yet promoted as the dominant production path. See Phase C Hardening.

ZK RUNTIME EVIDENCE

CAPTURE REQUIRED

The stronger path now has a dedicated runtime registry and generated package, but actual wallet captures for enable-mode and finalize still need to be recorded. See ZK-Enforced Runtime Evidence.

MAGICBLOCK RUNTIME

CAPTURE REQUIRED

The MagicBlock confidential payout corridor now has a dedicated runtime registry and generated package, but wallet-side deposit, private transfer, settlement, and execute captures still need to be recorded. See MagicBlock Runtime Evidence.

ZK EXTERNAL CLOSURE

PENDING EXTERNAL EXECUTION

The remaining stronger-path work is now flattened into one package: runtime captures, external audit handoff, and canonical verifier-boundary freeze. See ZK External Closure.

VERIFIER STRATEGY

DECISION REQUIRED

The repo now records anchors, receipts, and proposal policies, but the final production verifier boundary still needs to be frozen. See ZK Verifier Strategy.

FRONTIER INTEGRATIONS

LIVE DEVNET PROOF

The repo now emits one machine-checked package that binds ZK proof anchors, MagicBlock settlement, REFHE settlement, and backend-indexed RPC state into a single Frontier-facing review surface. See Frontier Integration Evidence.

READ NODE / INDEXER

DEPLOY RECOMMENDED

Mainnet readiness improves when proposal reads, DAO inspection, and runtime health move behind a pooled RPC read node instead of relying on browser RPC alone. See Read Node and Indexer.

READ NODE SNAPSHOT

GENERATED

The repo now emits a backend-indexer snapshot covering runtime, proposal counts, zk mode coverage, and confidential payout coverage. See Read Node Snapshot.

SUPPORTED PROVIDERS

Run diagnostics to inspect provider detection and runtime capabilities.

BROWSER CAPABILITIES

Run diagnostics to inspect browser crypto and clipboard support.

RPC DETAILS

Run diagnostics to confirm Devnet access and latest blockhash retrieval.

Diagnostic snapshot will appear here.

PRIVATE VOTING. SAFE EXECUTION.

The repo is deeper than the UI.This is what PrivateDAO actually ships.

Hide voting intent.Keep execution accountable.

Live Proposals

Inspect state, choose the next action, and verify execution.

Keep operation, verification, and escalation separate.

Fast path to reproducethe real governance cycle.

Runtime depth, security reasoning,and release evidence.

How PrivateDAO worksin one operating flow.

Governance features that stay tiedto the live product.

Move a governance communitywithout losing continuity.

Configure Your Migration

Make private governancedefensible, not cosmetic.

Threats reduced byspecific on-chain checks.

PrivateDAO Awards& Recognition

The repo is deeper than the UI.
This is what PrivateDAO actually ships.

Hide voting intent.
Keep execution accountable.

Fast path to reproduce
the real governance cycle.

Runtime depth, security reasoning,
and release evidence.

How PrivateDAO works
in one operating flow.

Governance features that stay tied
to the live product.

Move a governance community
without losing continuity.

Make private governance
defensible, not cosmetic.

Threats reduced by
specific on-chain checks.

PrivateDAO Awards
& Recognition