io.github.X-PACTPublished by GitHub account X-PACTv1.7.2Updated Nov 8, 2026
PrivateDAO services for verification, multichain intelligence, risk, and agent workflows.
The publisher's own server: Exchange.news — Crypto offers, campaigns and news
A remote MCP marketplace for PrivateDAO services: discover agents and capabilities, run paid jobs, and handle PrivatePAY x402 payments and receipts.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/io.github.X-PACT%2Fpdao-agent-exchange/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Add this to your client's mcpServers config.
{
"mcpServers": {
"privatedao-agent-exchange": {
"type": "http",
"url": "https://agents.privatedao.org/mcp"
}
}
}[PrivateDAO Agent Exchange MCP connector – tool definition quality and endpoint health on Glama]
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.
PrivateDAO is built for organizations entering Web3 as well as organizations that never intend to become crypto companies. A business can keep its existing operating model and add verifiable Web3 capability only where it is useful: private payroll, controlled treasury actions, governance, procurement, and verification. Privacy is the product principle; blockchain, wallets, and cryptography are execution infrastructure behind that principle.
The project is organized around six core organizational workflows:
These workflows share the PrivateDAO Kernel, policy controls, execution adapters, receipts, and reconciliation boundaries. The public product surface is intentionally simple; technical network details remain available for builders, reviewers, and operators.
The next product milestone is PDAO Wallet, an account and policy layer for organizations rather than a single consumer wallet. The planned wallet suite will support:
PDAO Wallet will be developed as a capability layer above the PrivateDAO Kernel. It will remain independent from any single chain or provider, while each network adapter is required to provide real implementation and evidence before it is described as supported.
PrivateDAO plans a quantum-resilience layer above the Kernel and PDAO Wallet. This work will evaluate current post-quantum and hybrid cryptographic libraries, key-agility patterns, signing policies, migration paths, and hardware-backed execution as the standards and production libraries mature. The implementation will use maintained, independently reviewed libraries and explicit compatibility gates. This roadmap is not a claim that PrivateDAO is currently quantum-safe, certified, or externally audited for post-quantum security.
PrivateDAO is participating in the following programs based on accepted program communications and the partnership records maintained by the project owner:
These program relationships do not by themselves mean endorsement of every PrivateDAO product, certification, customer reference, grant award, or joint commercial offering. Product capabilities remain subject to the evidence and status recorded in the repository. The supporting acceptance emails and public announcements are retained by the project owner; this repository records the program names and their intended technical role without reproducing private correspondence.
The PDAO Wallet roadmap will use these relationships for storage, AI inference, hardware/performance testing, developer tooling, and operational validation as the relevant integrations are enabled. See the ecosystem program record for the technical scope and disclosure boundary.
This repository distinguishes three states:
Network configuration, an address, a UI label, or a passing unit test alone is not evidence of a live product execution path. See the capability matrix and linked evidence for the status of each network and workflow.
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.
PDAO Worlds is the community layer for education, experimentation, and shared participation around PrivateDAO. It is separate from the organization workflow products and does not change the evidence or security requirements of the Kernel, PDAO Wallet, or settlement paths.
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.
The customer-facing workflow comes first. Wallets, providers, networks, RPC clients, cryptography, and settlement details remain behind the product boundary until execution requires them.
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.
The current separation between the six enterprise products and the external
Agent Exchange is documented in
docs/architecture/enterprise-kernel-boundary-20261014.md.
The repository contains provider-neutral runtime contracts in
packages/privatedao-runtime. The Kernel and Protocol layers provide common
boundaries for:
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.
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:
PrivateDAO separates capability evidence by network. The following labels are intentional:
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:
docs/current-network-state-2026-05-24.mddocs/multichain-readiness-20260917.mddocs/agent-exchange-production-report-20260920.mddocs/readiness-aggregate.mdpackages/privatedao-runtime/README.mdNo Mainnet capability should be inferred from a Testnet result. Mainnet payments, production custody, and customer deployment remain separate release gates.
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.
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 [email protected], 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:
docs/agent-discovery-live-20260918.mddocs/agent-mcp-independent-client-2026-09-19.mddocs/product-readiness.mddocs/security-readiness.mddocs/mainnet-readiness.mddocs/awards.mdRequirements 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.
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.
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.
See LICENSE, NOTICE.md, and
TERMS_OF_REVIEW.md for the applicable source, brand,
review, and commercial-use boundaries.
Source: README.md at commit 5e00683
PrivateDAO Workflow Guide
Return the overview, execution, or payment workflow guide. Use this instead of separate guide tools when you need lifecycle context; it is free, read-only, and returns the selected next steps without executing or paying.
topicrequiredPrivateDAO Capability Catalog
List services, products, external capabilities, or network metadata with optional filters. This is free and read-only; use discover_agents for a task-specific match and create_paid_job only after selecting a service.
qlimitfilterPrivateDAO Agent Discovery
Match a natural-language requirement or structured capabilities to first-party services and registered agents. Returns ranked matches without side effects or cost; use list_catalog for exact schemas and prices, and create_paid_job to execute selected paid work.
limitquerynetworkcapabilitiesPrivateDAO Provider Integrations
Return provider roles and integration metadata for planning. This is free and read-only; use list_catalog for purchasable capabilities and discover_agents for matching.
Takes no parameters.
PrivateDAO PrivatePay Architecture
Return the PrivatePAY x402 privacy architecture, merchant controls, and evidence model. Use this for payment-rail context before checkout; it is free, read-only, and returns structured status metadata without creating a payment.
Takes no parameters.
PrivateDAO Payment Challenge
Create and return a structured PrivatePAY x402 challenge for an eligible commercial workflow. Use this before privatepay_verify; it prepares payment context, does not sign or broadcast, and any charge is defined by the returned requirements.
nonceresourcerequiredmime_typeprovider_idrequiredamount_base_unitsrequiredPrivateDAO Private Checkout
Create or challenge a PrivatePAY checkout and return its commercial terms and payment requirements. Use this to begin a private checkout rather than create_paid_job with direct USDC; it does not sign or broadcast a wallet transaction.
payerphaseresourcepayment_iddescriptionamount_base_unitsexpires_in_secondsexternal_referencePrivateDAO Payment Preparation
Prepare and return an unsigned PrivatePAY deposit, transfer, or withdrawal context. Use this after privatepay_checkout and before local authorization; it is a preparation step with no signing or broadcast side effect.
ownerpayerphasesplitgaslessrequest_idrequiredamount_base_unitsrequiredPrivateDAO Payment Verification
Validate and return structured evidence for a PrivatePAY x402 payload against agreed requirements. Use this before privatepay_settle; it does not itself settle or spend funds.
x402VersionrequiredpaymentPayloadrequiredpaymentRequirementsrequiredPrivateDAO Payment Settlement
Submit an authorized PrivatePAY x402 settlement request and return settlement evidence. Use this only after privatepay_verify; it is the payment-moving action and may create an on-chain or facilitator-side settlement.
x402VersionrequiredpaymentPayloadrequiredpaymentRequirementsrequiredPrivateDAO Paid Workflow Payment
Apply an authorized PrivatePAY payment to a selected job and return workflow evidence. Use this for an existing privatepay job instead of submit_payment; it forwards the supplied payment proof and may settle funds.
job_idrequiredpayment_signaturerequiredPrivateDAO Receipt Verification
Verify an asset/record or retrieve and validate a PrivateDAO receipt. Returns structured evidence and hashes; it is free and read-only, never pays or executes work, and replaces the separate basic, receipt, and get-receipt paths.
mintmodeassetrecordnetworkreceiptreceipt_idexpected_hashexpected_digestPrivateDAO Service Request
Create a selected PrivateDAO capability request and return either an immediate result or an exact quote-first payment intent. Use discover_agents and list_catalog before it; creating a paid job does not spend funds.
inputservice_idrequiredpdao_accesspayment_modePrivateDAO Payment Confirmation
Confirm an authorized payment reference for a selected request and return the payment/execution result. Use this after create_paid_job and only with the exact returned quote; it may write payment state and never accepts a guessed amount.
job_idrequiredsignaturerequiredPrivateDAO Request Status
Return the current state, payment intent, result, or receipt reference for a request. Use this to poll after create_paid_job or submit_payment; it is free, read-only, and never retries payment.
job_idrequiredPrivateDAO Request Cancellation
Cancel an unpaid pending request before execution and return its updated status. It records cancellation only, never spends or refunds funds, and must not be used after payment or execution has started.
job_idrequiredreason100% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
news.exchangeOfficial publisher
A read-only remote catalog that lets an assistant look up crypto signup codes, partner links, campaign dates and Exchange.news stories.
Published by GitHub account kriton-dev
Remote Apify-hosted MCP server that lets an assistant read the latest ECB daily currency reference rates and calculated cross pairs.
Published by GitHub account Servosity
Unofficial MCP server that lets an assistant audit and administer Microsoft Exchange Online mailboxes across customer tenants over REST, without PowerShell.
Published by GitHub account PatrickPi1312
Find providers; send authorised installation or cleaning enquiries in Vienna. No customer account.
Published by GitHub account sepehr071
Unofficial read-only MCP server for the Iran Mercantile Exchange, letting an assistant query commodity trades, prices, supply offers and market totals.
Choose the workflow -> define rules and participants -> run privately -> approve and execute -> reconcile the result -> share only the evidence that others neednpm installnpm run typechecknpm run web:buildnpm run test:runtimenpm run test:record-verificationnpm run web:dev