PrivateDAO
Private decisions. Verifiable outcomes.
PrivateDAO is a privacy-first operating layer for organizations that need to
run sensitive work without making every detail public. It helps teams define
rules, run workflows, approve actions, execute through the appropriate
infrastructure, and share evidence of the outcome.
Live Testnet program: EP9xE8MJZ6FfyEwLqns6HDdUZBknEa7WGYs1Jzsecuva
Historical Devnet proof registry program: 5AhUsbQ4mJ8Xh7QJEomuS85qGgmK9iNvFqzF669Y7Psx
(docs/proof-registry.json); this is retained as provenance and is not the
current Testnet deployment.
An organization does not need to become a Web3 or crypto company to use
PrivateDAO. A company, institution, financial team, DAO, data provider, or
Web3 operator can start with a familiar business workflow and add wallets,
networks, settlement, or verifiable Web3 capability only where it creates
value.
What PrivateDAO provides
Private operations
- Confidential Payroll - prepare payroll, apply tax and deduction rules,
collect approvals, settle through a supported private-payment path, and
produce a verifiable result without exposing employee records.
- Treasury Coordination - manage spending requests, budgets, approvals,
execution, reconciliation, and evidence for sensitive financial operations.
- Private Governance - coordinate proposals, committees, delegation, and
decisions while keeping sensitive discussion and voting context private
where the workflow requires it.
Private transactions and markets
- Confidential Auctions - protect competing bids until the agreed close,
then produce a fair and checkable result.
- Private Settlement Workflows - move an approved operation through a
supported settlement provider and retain a receipt with clear lifecycle
status.
Verification
- Blind Verification - prove that a condition or policy was satisfied
without revealing the underlying data.
- Record Verification - create a shareable, tamper-evident record for a
document, event, approval, or business result without publishing private
fields.
- Private Identity Verification - support selective confirmation of
identity, entity, jurisdiction, or authorization requirements while keeping
the source material private.
Agent and community products
- PrivateDAO Agent Exchange - an MCP-compatible service marketplace for
verification, blockchain intelligence, market context, agent discovery, and
verifiable receipts.
- PDAO Worlds - an independent community game about privacy, trust,
evidence, and coordination. It is a separate product and does not define
the commercial workflow runtime.
PDAO token surface
The current published token surface is documented in
docs/pdao-token.md and the machine-readable
attestation is docs/pdao-attestation.generated.json.
The documented Testnet governance token is PDAO with mint
DFYvBdivHCe4bSErgCiKm2RhwGEcZYbBPFQzLNr37Bie and a published initial supply
of 1,000,000 PDAO. These references describe the current evidence surface;
they do not claim Mainnet launch, market liquidity, or speculative returns.
How it works
Choose the workflow
-> define rules and participants
-> run privately
-> approve and execute
-> reconcile the result
-> share only the evidence that others need
The customer-facing workflow comes first. Wallets, providers, networks, RPC
clients, cryptography, and settlement details remain behind the product
boundary until execution requires them.
Agent Exchange
The production Agent Exchange is available at:
The endpoint is designed for standard MCP clients and exposes discovery,
verification, intelligence, agent matching, job lifecycle, payment-aware
receipts, and marketplace capabilities. Free discovery and read-only tools are
separate from paid service execution. A client must use the published schemas
and receipts; a frontend response is not payment proof.
Current payment and network claims are capability-specific. Where a service
requires payment, the active payment rail and supported target network are
returned by the service catalog. Do not infer that every advertised target
network has the same execution or payment capability.
Kernel and runtime architecture
The repository contains provider-neutral runtime contracts in
packages/privatedao-runtime. The Kernel and Protocol layers provide common
boundaries for:
- product capabilities and permissions;
- provider selection and lifecycle states;
- wallet-signing boundaries;
- preparation, submission, confirmation, and receipts;
- reconciliation, idempotency, normalized errors, and telemetry;
- MCP, REST, SDK, and agent-facing contracts.
Network-specific transaction construction belongs behind adapters. The runtime
package does not store private keys, contain a wallet signer, or invent a
successful receipt. A configured network is not considered supported merely
because it appears in a UI or configuration file; it needs a real adapter and
independent evidence.
Review and operating references
The repository keeps security, release, runtime, and operating evidence
available for reviewers. These documents describe engineering evidence and
boundaries; they are not claims of incorporation, certification, partnership,
or mainnet readiness unless the referenced document says so explicitly.
Reviewer entry points:
Network status
PrivateDAO separates capability evidence by network. The following labels are
intentional:
- Verified Testnet - a documented testnet workflow has independent
execution evidence for the stated capability.
- Read or discovery - the system can inspect or describe a network, but
this is not proof of write-enabled product execution.
- Planned - configuration or roadmap information exists, but the product
must not advertise execution until its adapter and E2E evidence are ready.
The current repository evidence includes Solana Testnet lifecycle material,
selective EVM-family Testnet verification, and Tempo Testnet payment/runtime
material. Ethereum, Base, Arbitrum, Robinhood, Zcash, Hyperliquid, and other
network entries must be read through the capability matrix and their linked
evidence rather than treated as one universal support claim.
Start with:
No Mainnet capability should be inferred from a Testnet result. Mainnet
payments, production custody, and customer deployment remain separate release
gates.
Public product surfaces
Historical product links are preserved through the site route inventory. The
public site is the commercial surface; this repository is the implementation,
evidence, and review surface.
historical links stay alive as bridges to the consolidated commercial
surfaces. The current evidence record signs from a Solana Testnet wallet; it
must not be read as Mainnet execution or as a claim that every network is
write-enabled.
Review and Colosseum access
This is the repository submitted for review:
https://github.com/X-PACT/PrivateDAO
The repository is private. The official Colosseum review account is
colosseum-git, associated with hackathon@colosseum.com, and has repository
access. The canonical review branch is main.
The review package contains source and documentation only. Secrets, private
keys, wallet seed material, and deployment credentials are not part of the
repository.
Useful reviewer entry points:
Local development
Requirements depend on the surface being tested. The web application uses
Next.js, React, TypeScript, and the Solana wallet-adapter ecosystem. Runtime
contracts are TypeScript packages; the on-chain program uses Anchor and Rust.
npm install
npm run typecheck
npm run web:build
npm run test:runtime
npm run test:record-verification
For the web application alone:
Run network or wallet tests only with the explicitly configured testnet
environment. Never place a private key, seed phrase, token, authenticated RPC
URL, or deployment credential in the repository.
Evidence discipline
PrivateDAO distinguishes between implementation, testnet evidence, production
readiness, and mainnet execution. A green unit test does not prove an on-chain
transaction. An RPC health check does not prove product support. A marketplace
listing does not prove payment settlement. Each product and network must carry
its own lifecycle, receipt, reconciliation, privacy, and release evidence.
License and notices
See LICENSE, NOTICE.md, and
TERMS_OF_REVIEW.md for the applicable source, brand,
review, and commercial-use boundaries.