Privi Ledger

Tamper-evident, quantum-sealed audit logs for AI agents: log every action, prove it later, sealed compliance reports (EU AI Act, OMB AI inventories, post-quantum plans), agent trust passports, wallet Know-Your-Agent, spending mandates. Remote MCP, free tier, x402.

託管 MCP 伺服器

npx add-mcp 'https://privi-ledger.onrender.com/mcp'

可安裝到 Claude Code、Codex、Cursor 等客戶端

文件

Privi Quantum Ledger MCP

(formerly Privi Ledger)

Quantum-sealed, tamper-evident audit logs for AI agents. Every company running agents needs to prove what those agents did: what data they touched, what they paid for, what they changed, and that nobody rewrote the record afterwards. Privi Ledger gives any MCP-capable agent a place to log each action, and gives auditors a way to verify the log, paid per check in USDC on Base via x402.

Works with Claude, ChatGPT, Cursor, VS Code and custom agents. Built by Privi World Co on the same record technology as Privi Verify.

Live (testnet): https://privi-ledger.onrender.com/mcp

Tools

Real-time tools (live_*, approval_*, trust_events, gateway_*, room_*) are described under Privi Live below.

ToolAccessWhat it does
ledger_pricingfreePrices, network, action types, how to get a key
ledger_check_receiptfreeConfirms an action receipt (entry_hash) exists and when; reveals no contents
ledger_audit_stream$0.02 (x402)Integrity audit of an agent's log: intact or not, where it broke, counts, time span, head hash. No action contents
ledger_record_actionorg keyAppend an action; returns the entry and its entry_hash receipt
ledger_read_streamorg keyRead your own entries with an integrity check
ledger_list_streamsorg keyYour streams and entry counts
ledger_compliance_reportorg keyAudit-ready report of agent activity for a period, sealed on the Privi chain
ledger_report_pdforg keyThe sealed report as a finished PDF (also at GET /reports/<id>.pdf with the org key)
ledger_handshake_offer / _accept / _reject / _inboxorg keyPrivi Handshake: two-sided records of dealings between companies
ledger_handshake_verifyfreePublic check of a handshake and its on-chain seal; never reveals terms
ledger_verify_reportfreeProves a report is unaltered and was issued by Privi Ledger; checks its on-chain seal

Action types: tool_call, data_access, data_change, payment, message, decision, approval, error, other. Outcomes: success, failure, pending, blocked.

How the log stays honest

Each entry's SHA-256 fingerprint covers its contents and the previous entry's fingerprint in the same stream. Editing, deleting or reordering any entry breaks the chain from that point, and audits report the exact entry where it broke. Organizations only ever see their own streams; API keys are stored as hashes.

Stream heads are anchored on the Privi blockchain every few minutes (see On-chain checkpoints), so integrity can be proven without trusting Privi.

Plans (self-serve)

PlanHowIncludes
Freeledger_signup (no key needed)Every tool, up to 500 entries per month
Proledger_upgrade_pro, $29 USDC per 30 days via x402Unlimited entries; each payment adds 30 days
EnterpriseCreated by Privi (/admin/orgs)Unlimited; billed by agreement

Any company, or an AI agent acting for one, can sign up, start logging, and upgrade without talking to anyone. Payments go straight to LEDGER_PAY_TO, and each purchase is recorded in the organization's own privi-billing stream. ledger_plan shows usage and renewal. Set LEDGER_FREE_MONTHLY and LEDGER_PRICE_PRO_MONTH to change the limits.

Onboarding a customer

Create an organization with the admin key (set LEDGER_ADMIN_KEY):

curl -X POST https://<host>/admin/orgs \
  -H "Authorization: Bearer $LEDGER_ADMIN_KEY" -H 'Content-Type: application/json' \
  -d '{"name": "Acme Robotics"}'
# -> {"org_id": "org_...", "api_key": "plk_...", ...}  (the key is shown once)

The customer adds the server to their agent with header Authorization: Bearer plk_..., and tells it to call ledger_record_action after each meaningful action. They share their org_id and stream names with auditors, who call ledger_audit_stream.

Compliance reports

ledger_compliance_report turns an organization's agent logs into evidence for SOC 2 reviews, customer security questionnaires and AI-regulation record keeping. For any period it reports actions by type, actors, failures, blocked actions, human approvals, log integrity and on-chain status. It also lists findings an auditor would raise, such as broken integrity, logs not yet anchored, failed actions, or payments and data changes with no human approval recorded. The result comes as JSON plus a ready-to-share Markdown version.

Each report is sealed. Its SHA-256 hash, taken over canonical JSON, is anchored on the Privi blockchain through Privi Anchor. Anyone holding the report can run ledger_verify_report, which recomputes the hash, confirms Privi Ledger issued exactly that content, and checks the anchor on chain. Editing even one number, such as hiding a failure, makes verification fail.

Privi Gov AI Inventory (OMB M-25-21)

Federal agencies must keep an inventory of their AI use cases, publish the releasable ones as a machine-readable file, and show minimum risk practices for high-impact AI. That requirement comes from OMB Memorandum M-25-21 and OMB's guidance on 2025 agency AI reporting. Privi Ledger covers the whole loop:

ToolWhat it does
gov_ai_usecase_saveAdd or update a use case in the guidance's reporting fields. Every change is a new version, written to the agency's tamper-evident ai-inventory log
gov_ai_inventoryCurrent inventory
gov_ai_inventory_checkFlags what a review would flag: missing required fields, PII without a Privacy Impact Assessment, and high-impact AI in pilot or deployment missing any minimum practice (testing, impact assessment, independent review, monitoring, operator training, fail-safe, appeals, public feedback) or without a recently active activity log as monitoring evidence. Practices waived by a written CAIO determination are respected
gov_ai_inventory_exportCSV of releasable use cases for agency.gov/ai, with its SHA-256 sealed on the Privi chain
gov_ai_verify_export (free)Proves a published inventory file is exactly what the agency exported

The inventory links to agents' Privi Ledger activity logs (monitoring_streams), so "ongoing monitoring" is backed by real, tamper-evident records.

Field names follow OMB's published reporting fields. Confirm them against OMB's current template before submitting. This tool supports compliance work; it is not legal advice or an OMB-approved system.

Privi Quantum-Ready (post-quantum migration)

Executive Order 14409 (June 2026) requires federal key establishment to move to post-quantum cryptography by Dec 31, 2030, and digital signatures by Dec 31, 2031. OMB M-26-15 asks every agency for a migration plan built on a cryptographic inventory (CBOM), prioritizing High Value Assets, high-impact systems and data that must stay sensitive past 2030, plus TLS 1.3 support by Jan 2, 2030.

ToolWhat it does
gov_pqc_classify (free)Classifies algorithms and cipher suites: quantum-vulnerable (RSA, ECDH, ECDSA, EdDSA, DH, DSA, MQV), post-quantum (ML-KEM, ML-DSA, SLH-DSA), hybrid, symmetric/hash, or unknown
gov_pqc_system_saveRecords one system's cryptographic assets (from people, scanners or agents). Versioned and written to a tamper-evident pqc-inventory log
gov_pqc_inventoryCurrent inventory
gov_pqc_planRanked migration queue with per-asset deadlines and NIST replacements, progress metrics, and findings: targets past the deadline, TLS below 1.3, priority assets with no target date, unrecognized algorithms
gov_pqc_exportThe CBOM plus plan as one JSON document, sealed on the Privi chain
gov_pqc_verify_export (free)Proves an exported document is unaltered

The rules follow public summaries of EO 14409 and OMB M-26-15. Confirm them against the official texts and NIST IR 8547 before relying on them. This tool supports compliance work; it is not legal advice.

Privi Passport (trust credentials for AI agents)

The feature no one else can copy: a signed, on-chain-anchored credential that says how much an AI agent can be trusted, scored 0-1000 from evidence only Privi Ledger holds.

ComponentMaxEvidence
history300verified entries and days of activity
integrity250every hash chain still verifies (all or nothing)
anchoring150share of streams whose on-chain checkpoint matches the record
reliability1001 - failure rate
oversight50human approvals on sensitive actions
compliance100a sealed compliance report exists and is clean
handshakes50deals other Privi organizations confirmed

Grades: A >= 850, B >= 700, C >= 550, D >= 400, E below. Valid 30 days.

  • passport_issue (org key; free on Pro/enterprise, $LEDGER_PRICE_PASSPORT via x402 on the free plan) - Ed25519-signed by the server, hash anchored on the Privi chain, every component itemised.
  • passport_verify (free) - signature, content, expiry, revocation, chain anchor, and a live re-score: if the agent's history is tampered with after issue, the passport fails.
  • passport_gate (free) - one-call allow/deny with your minimums (min_score, min_grade, require_anchored); send your own key and the decision is written to your log as due-diligence evidence.
  • passport_list, passport_revoke (org key).
  • Public: GET /passports/<id> (JSON + live verification), GET /passports/<id>/badge.svg (embeddable badge), GET /.well-known/privi-passport.json (issuer public key).

Why it compounds: agents that gate on passports push their counterparties onto Privi Ledger; every logged action, report and handshake raises the score; a better score wins more deals. Set LEDGER_PASSPORT_SIGNING_KEY (32-byte hex Ed25519 seed) to pin the issuer key across redeploys; otherwise one is generated and stored in the database.

Privi KYA (Know-Your-Agent for blockchain wallets)

As AI agents become the main senders of on-chain transactions, every chain, DeFi protocol, exchange, stablecoin issuer and x402 facilitator needs one answer before accepting a transaction: is this wallet operated by an audited agent, and how trustworthy is it right now? Privi KYA answers it, and only Privi can, because the answer is the Passport.

  • kya_challenge + kya_bind_wallet (org key) - bind a wallet to your Passport by signing a Privi challenge with the wallet (EIP-191 personal_sign, recovered in pure Python; no web3 dependency). A binding without a signature is only declared.
  • kya_check <address> (free) - resolves the wallet to its organization and live Passport; returns allow/deny with reasons, the current score and grade, and a Privi-signed KYA attestation valid 60 minutes that a facilitator can cache and verify offline. Send your key and the decision is logged as evidence.
  • kya_wallets, kya_unbind_wallet (org key) - rotated or compromised keys are denied immediately.
  • Connect wallet page: GET /kya/connect — paste the org key, connect MetaMask, sign once; done. No code needed.
  • Public: GET /kya/<address> (JSON verdict + attestation; ?min_score=&min_grade=&require_signed=), GET /kya/<address>/badge.svg.

Integration pattern for a chain or protocol: before accepting an agent transaction, GET /kya/<from>; require allow: true (and optionally proof: "signature"); keep the attestation + signature as your compliance record.

Privi Quantum Ledger (quantum-sealed blocks, fused with the Privi Foundation chain)

The whole log is sealed into a chain of quantum blocks every few minutes (LEDGER_QBLOCK_INTERVAL, default 300 s):

  • Each block commits to the previous block, the signed tree head of the transparency log (size + Merkle root) and a SHA3-512 root of the entries it adds.
  • Blocks are hashed with SHA3-512 (FIPS 202; 256-bit security even against Grover's quantum search) and co-signed with ML-DSA-87 (FIPS 204, CNSA 2.0) and Ed25519, the same keys as Privi Fortress.
  • Consecutive blocks are linked by RFC 9162 consistency proofs, so the log provably only grew.
  • Fused with the Privi Foundation chain (Cosmos SDK + CometBFT + Cosmos EVM, production-network/): every block names the Foundation chain IDs (PRIVI_FOUNDATION_COSMOS_CHAIN_ID, PRIVI_FOUNDATION_EVM_CHAIN_ID) and, when PRIVI_FOUNDATION_RPC_URL points at a Foundation node, carries a witness of its latest block (height + hash). Until the Foundation mainnet launches, each block settles on Base through Privi Anchor.

Tools (all free except sealing): qledger_status, qledger_block, qledger_verify_chain (anyone can re-verify the entire chain), qledger_entry_proof (prove a receipt is sealed in a block, without revealing contents), qledger_seal (organization key; seal now). Privi Quantum Scan (/quantum-scan) is the public block explorer: every block, entry-receipt, tree-head, log-root and Base settlement hash, with search by block height or any hash. Only hashes and counts are shown, never an organization, stream or entry contents. JSON behind it: GET /quantum-ledger (status), /quantum-ledger/stats, /quantum-ledger/blocks?limit&before, /quantum-ledger/blocks/<height>, /quantum-ledger/entries?limit&offset&block, /quantum-ledger/search?q=.

Engineering controls, not a certification (FIPS 140-3, FedRAMP, DoD IL).

Privi Fortress (defense-grade integrity controls)

Engineering controls aligned with CNSA 2.0 and NIST SP 800-53 (AU-9 protection of audit information, AU-10 non-repudiation, AC-5 separation of duties, SC-13 cryptographic protection). They are not a certification (no FIPS 140-3 validation, FedRAMP or DoD Impact Level authorization is claimed).

  • Post-quantum co-signatures. Passports, compliance reports, mandates, KYA and mandate attestations, tree heads and evidence bundles are signed with Ed25519 and ML-DSA-87 (NIST FIPS 204; the CNSA 2.0 parameter set). Keys: fortress_keys, /.well-known/privi-passport.json. Pin the seed with LEDGER_PQ_SIGNING_KEY (32-byte hex) or one is generated and stored.
  • Transparency log. Every entry from every organization is a leaf in one RFC 9162 Merkle tree (the Certificate Transparency design). ledger_tree_head returns a dual-signed tree head, anchored on the Privi chain every LEDGER_STH_INTERVAL seconds (default 900); ledger_inclusion_proof proves an entry is in the log and ledger_consistency_proof proves the log only grew between two heads. HTTP: /log/sth, /log/inclusion?hash=, /log/consistency?first=&second=. All free.
  • Two-Person Integrity. fortress_tpi_policy names the officers' wallets and how many must approve (at least 2). fortress_tpi_request returns an approval page (/tpi/<id>); each officer signs with their own wallet, the same officer cannot approve twice, outsiders are refused, and any officer can veto. fortress_tpi_execute consumes the authorization once. Every step is logged.
  • Air-gapped evidence bundles. ledger_evidence_bundle exports entries, the hash chain, an inclusion proof, the signed tree head, the on-chain checkpoint and Privi's keys, dual-signed. python verify_bundle.py bundle.json (download at /tools/verify_bundle.py) checks all of it with no network access.

Privi Mandates (human-authorized agent spending)

Signed proof that a person authorized an AI agent to spend, which any merchant or payment facilitator can check before taking the agent's money.

  1. mandate_create (org key) drafts the terms: budget, per-payment cap, allowed payees (0x addresses or domains), expiry, purpose. It returns a sign_url.
  2. The human opens /mandates/<id>/sign, reads the plain-English terms, and signs once with their wallet (EIP-191; free, no transaction). The terms hash is countersigned by Privi and anchored on the Privi chain, and the approval is logged.
  3. Before each payment the agent calls mandate_spend, which enforces the caps, payee list, expiry and remaining budget atomically and writes the payment (or the blocked attempt) to the agent's tamper-evident log.
  4. Merchants and facilitators call mandate_check or GET /mandates/<id>/check?amount=&payee= (free) and get allow/deny with reasons plus a Privi-signed attestation.
  5. The human revokes from the same page with one signature, or the organization calls mandate_revoke.

Public: GET /mandates/<id> (terms, signatures, budget, recent spends).

Privi Guard (prompt-injection and data-leak check with receipts)

One call checks content before an agent acts on it or sends it:

  • inbound: prompt injection, fake system turns, exfiltration and prompt-leak requests, concealment, tool and payment coercion, hidden text, markdown-image exfiltration, base64-hidden instructions;
  • outbound: cloud and API keys, private keys, tokens, seed phrases, passwords, card numbers, SSNs and URL data smuggling, with a redacted copy.

Each check returns an Ed25519-signed receipt holding the content's SHA-256 (never the content). Receipts are Merkle-batched into the transparency log every five minutes and anchored on-chain.

MCPguard_check, guard_check_many, guard_receipt, guard_balance, guard_buy_credits, guard_pricing; gateway_set_guard screens every tool result through a Privi Gateway (tag or block)
HTTPPOST /guard/v1/check, /check_many, /signup, /demo (website, rate-limited, no receipt); GET /guard/v1/receipts/<id>, /pricing, /stats, /revenue (admin key)
Price1,000 checks per month free per organization, then credits (1k / 10k / 100k for 7 / 50 / 300 USDC) or 1 cent per check via x402 (MCP _meta or HTTP PAYMENT-REQUIRED / PAYMENT-SIGNATURE)
SDKsguard-sdk/: Python and JS clients (zero dependencies) and a Claude Code hook

Privi Scan (public MCP trust registry)

Privi Scan syncs the official MCP Registry. It reads every public streamable-HTTP server's tool list with initialize and tools/list only, and never calls a tool. It grades each server A-F for tool poisoning:

  • prompt-injection markers
  • concealment from the user
  • requests for SSH keys, .env files or seed phrases
  • tool shadowing
  • invisible characters
  • unauthenticated high-impact tools

Every tool definition is hashed. The first observation and every change go into the Privi Ledger transparency log (Merkle tree, anchored on-chain). That gives anyone a permanent record of what a server's tools said and when they changed.

Directory/scan, one server at /scan/s/<server_id>
Free checkmcp_server_check(url, expected_tools_hash?), or GET /scan/api/check?url=&expected=
Searchscan_search, scan_server, scan_changes, scan_stats, or /scan/api/servers, /scan/api/changes, /scan/api/stats
Watch (org key)scan_watch pins the tools_hash and sends real-time scan.tools_changed / scan.risk_found / scan.server_down events on your org Live channel; free 3 servers, Pro 500
Ownersscan_claim_start / scan_claim_verify (token at /.well-known/privi-scan.txt), scan_rescan, scan_owner_listing (opt out)
Badge/scan/badge/<server_id>.svg
Live channelsscan (public, delayed for free) and scan:<server_id>

Config: SCAN_ENABLED (default 1), SCAN_INTERVAL (300 s), SCAN_BATCH (40), SCAN_REPROBE_S (6 h), SCAN_REGISTRY_URL.

Privi Live (real-time: streams, human approvals, kill switch, gateway, rooms)

Everything here runs over WebSocket and server-sent events, backed by one durable event log (7 days of replay).

Streams (live_info lists them): wss://…/live/ws, GET /live/events (SSE), GET /live/trust/recent, dashboard at /live.

  • Channels: trust (public: passports issued / revoked / re-scored, wallets bound, mandates activated or revoked, transparency-log heads anchored), mandate:<id>, and org (private: a live tail of your audit log, approvals, kill switch, rooms).
  • WebSocket frames: {"type":"auth","key":"…"}, {"type":"subscribe","channels":["trust","org"],"replay":20,"filter":{"address":"0x…","types":["passport."]}}, {"type":"kill","stream_id":"agent|*"}, {"type":"ping"}. Server frames: {"type":"event","event":"passport.score_changed","id":N,"channel":"trust","at":"…","data":{…}}, heartbeat.
  • API keys never go in URLs: use Authorization: Bearer (SSE/HTTP) or the first WebSocket frame.
  • Free and anonymous subscribers see the public channels delayed by LIVE_FREE_DELAY_S (default 300 s); Pro and enterprise get them in real time. A background watcher re-scores every live passport every LIVE_TRUST_INTERVAL seconds (default 120) and announces score or state changes (valid → broken / expired).

Human approvals. approval_policy_set makes mandate_spend pause on payments over a threshold: it returns approval_required with an approve_url; the mandate's principal signs an approve/deny message with their wallet (EIP-191), then the agent calls mandate_spend again with approval_id. An approval is for exactly one payment (mandate, amount and payee must match), valid 10 minutes after it is granted, usable once. approval_request / approval_wait do the same for any action. The organization's API key can only cancel, so an agent cannot approve itself.

Kill switch. live_kill (or privi kill, the /live dashboard, or a WebSocket frame) stops mandate_spend, the organization's gateways and room messages for one agent or all of them on the very next call, and pushes agent.killed to the live channel. Audit logging is never blocked. live_resume lifts it.

Gateway. gateway_create puts any public HTTPS MCP server behind /gw/<id>/mcp (and wss://…/gw/<id>/ws, the same JSON-RPC over one persistent connection). Privi rate-limits each caller, can require a Passport (min_score: the caller proves a KYA wallet with a fresh personal_sign over Privi Gateway <id>\nTimestamp: <ts>), meters every tools/call, writes each call to your log, and forwards the request unchanged, including x402 payment headers, so the upstream's own paywall keeps working. The kill switch stops it instantly. Upstreams that resolve to private, loopback or link-local addresses are refused. Free plan: 1,000 metered calls and 2 gateways; Pro: unlimited calls, 50 gateways. Per-tool stats: gateway_stats.

Rooms. room_open creates a live, hash-chained conversation between two organizations' agents (wss://…/rooms/<id>/ws; invite by org id or one-time join code). Optionally charge the guest per message, paid under their human-signed Mandate (budget, cap, payee list, approval policy and kill switch all apply). Closing a room seals the transcript: signed with Ed25519 and ML-DSA-87, anchored on the Privi chain, and written into both organizations' logs. room_verify (free) checks a transcript against the seal. Privi enforces and records the per-message charge; moving the money is between the two parties.

Privi AI Act Pack (EU AI Act register)

Every company that builds or uses AI in the EU needs to know each system's tier and prove its obligations. ai_act_system_save registers a system, screens it against the Article 5 bans, classifies it (prohibited / high-risk / transparency / general-purpose / minimal) and lists the obligations for its role with dates (Annex III high-risk from 2 Dec 2027, Annex I from 2 Aug 2028, per the Digital Omnibus, Regulation (EU) 2026/1744). ai_act_check flags gaps; ai_act_export returns a register sealed on chain that anyone checks free with ai_act_verify_export. Workflow aid, not legal advice.

Privi Supplier Proof (buyers require it, suppliers join)

A buyer publishes what suppliers must prove (supplier_requirement_create, shareable invite page at /supplier/requirements/<id>). Suppliers answer from their own Privi org with document fingerprints only (supplier_proof_submit). On approval (supplier_proof_decide) Privi issues a certificate naming both companies and the evidence hashes, sealed on chain, with a public page /certs/<id> and badge /certs/<id>/badge.svg. supplier_cert_verify is free and can confirm a specific document is covered.

Privi Content Seal (real vs AI-made)

seal_content seals the SHA-256 of a file or text with who made it and whether AI was involved (human, ai_assisted, ai_edited, ai_generated + tool); a batch of up to 50 is one on-chain anchor. Anyone checks free with seal_verify, GET /seal/<sha256>, a badge, or the drag-and-drop page /seal/check (the file is hashed in the browser and never uploaded).

Privi Handshake

A dealing between two companies, such as a payment, a data transfer, a delivery or an agreement, gets recorded by both of them, with neither able to deny or rewrite it alone.

  1. Company A's agent calls ledger_handshake_offer with the other company's org_id and the terms. A's log records the offer.
  2. Company B's agent sees it in ledger_handshake_inbox and calls ledger_handshake_accept, or ledger_handshake_reject with a reason.
  3. On acceptance, B's log records the same terms with A's entry hash, A's log records the confirmation with B's entry hash, and a pair hash binding the terms and both entries is anchored on the Privi blockchain.
  4. Anyone can run ledger_handshake_verify to see both parties, the status, whether both entries still exist, and the on-chain seal, without seeing the terms.

Handshakes only work between organizations on Privi Ledger.

On-chain checkpoints

Every 5 minutes the server anchors the latest fingerprint of each stream that changed on the Privi blockchain through Privi Anchor. Audit results include onchain_checkpoint: the anchored position, transaction, and Merkle proof, plus an anchor_verify call anyone can run. If stored history no longer matches what was anchored, the audit fails even when every local hash was recomputed consistently. Set LEDGER_ANCHOR_KEY (an Anchor API key) to turn it on; LEDGER_ANCHOR_INTERVAL changes the period (seconds, default 300).

Payments

Same x402 v2 MCP flow as Privi Verify: an unpaid call returns PaymentRequired; the agent retries with a signed USDC authorization in _meta["x402/payment"]; the server verifies, runs the audit, settles, and returns the receipt in _meta["x402/payment-response"]. Funds go straight to LEDGER_PAY_TO.

Run, test, deploy

pip install -e ".[dev]"
cp .env.example .env
pytest
privi-ledger-mcp            # HTTP :8000, MCP at /mcp
privi-ledger-mcp --stdio    # local clients; set LEDGER_LOCAL_ORG_KEY

The Dockerfile runs on Railway with a volume at /data. Start on base-sepolia; switch to base only with a production facilitator.

Roadmap

  • Subscription billing per organization
  • Retention policies and exports to customer storage

License

MIT © 2026 Dario Canoy, Privi World Co

Dual-payment groundwork: USDC production billing + valueless PRVI_TEST simulation

The existing USDC via x402 payment tools are unchanged. The additive MCP tool privi_payment_options reports two clearly distinct paths:

  • USDC_X402: the existing real/staging payment rail, depending on LEDGER_NETWORK and LEDGER_PAYMENTS_ENABLED. All settlement still passes the existing facilitator.
  • PRVI_TEST_SIMULATION: a strictly off-chain, no-value developer simulator. It cannot pay for a service, issue or move PRVI, grant Ledger Pro, add Guard credits, activate any financial chain, or be used as a settlement attestation.

The simulator is disabled by default. To enable it in a disposable development or isolated staging service, set PRVI_TEST_PAYMENT_MODE=1 and LEDGER_NETWORK=base-sepolia. When LEDGER_NETWORK=base, simulation is always forced off even if the flag is set. Keep the flag at 0 in production.

A verified existing Ledger organization with its API key can run:

  1. privi_payment_options (no key required; lists methods and launch status).
  2. privi_test_payment_quote with sku=ledger_upgrade_pro (API key required).
  3. privi_test_payment_simulate with the returned quote ID and acknowledgement="VALUELESS TEST ONLY" (same organization key).

A simulated receipt says SIMULATED_NOT_PAID, paid: false, settled: false, service_unlocked: false and real_transaction_hash: null. Quotes expire after 10 minutes, are bound to one organization, are one-use only, and are held in ephemeral process memory. Real USDC billing continues exclusively through existing tools such as ledger_upgrade_pro and the original x402 facilitator.

Native PRVI real settlement is not enabled. The PRVI mainnet release, fee and token economics, security audit, independent validators, legal review, chain ID, oracle/quote policy, custody and payment replay protections must pass separately reviewed launch gates before any real-value PRVI path is designed.

Run the isolated developer safety suite:

cd ledger-server && python -m pytest tests/test_dual_payments.py