USE PRIVORA

AI agents

Agents are first-class on Privora. The Rust SDK proves in-process (fast enough for autonomous loops), and an MCP server exposes the full confidential session to an AI agent like Claude, deposit, place, cancel, manage, withdraw, all proven locally.

Because every surface proves locally and trades are unlinkable, an agent operates exactly like a human would, with no special trust, no hosted prover, and no account that can be tied to its orders.

The MCP server#

Point an MCP-capable agent at the Privora server and it gets a confidential session it can drive end to end. The agent reasons over the lit market and its own (locally-held) position, and acts through tools:

MCP tools
privora_market_info   market id, the agent's address + balance, vault TVL, held notes/orders
privora_book          the lit order book + funding-adjusted mark (public read)
privora_fund          faucet test-USDC (and, on devnet, a little SOL) to the agent
privora_deposit       shield collateral into a confidential balance note
privora_place         place a confidential resting order (long / short)
privora_cancel        pull a resting order, reclaim its escrow
privora_position      read a resting order's live state (filled / remaining)
privora_match_fill    permissionlessly cross a resting bid + ask
privora_withdraw      spend a held note back to tokens

The session holds the agent's note secrets locally and proves each action on the agent's machine, the same model as the browser, just driven by a model instead of a mouse.

Note
The MCP tools are the core loop (fund, deposit, place, cancel, position, book, withdraw). For the richer flows, closing a position (settle_offset), cross-margin pools, iceberg orders, and arming set-and-forget liquidation, drive the Rust or TypeScript SDK directly; the SDK surface is a superset of the MCP tool set.

The server runs against a local validator by default. Point it at the live devnet venue by setting PRIVORA_CONFIG_URL (the keeper's /config or /markets) and PRIVORA_ARTIFACTS (the circuit .wasm/.zkey directory). The agent's identity is a generated key the box faucet funds, it holds no SOL and never signs a trade, exactly like a browser user. The full deposit → place → cancel → read → withdraw loop runs on devnet; only the permissionless matcher is localnet (on devnet the keeper crosses the book).

Reference agents#

Two permissionless agents run the venue today and are worth reading as blueprints. Neither holds any special power, anyone can run them.

The keeper

  • Matching, reads the live book and crosses it by price-time priority, submitting fills. Permissionless: matching crossing orders is deterministic, so anyone can do it for the reward.
  • Funding crank, advances the cumulative funding index from the bound oracle. The oracle, not a key, is the trust root.
  • Liquidation watch, trial-unlocks owner-armed sealed bundles as the mark crosses, and liquidates with each position's own recovered proof. Set-and-forget; no owner online.

The quoter (a market maker)

A separate funded identity that posts a two-sided book around the mark and cancels/replaces its quotes as the mark moves, so the book ticks and a taker's order crosses real liquidity. It's just a participant: it never calls the matcher, and the keeper crosses its quotes like anyone else's.

Build your own#

Use the Rust SDK for an autonomous loop, it proves fast enough to deposit, place, and cancel on a tight cadence. A minimal market-watching agent:

rust
loop {
    let mark = read_mark(&indexer, market)?;        // public read
    let quote = price_quote(mark, size, maint, funding)?;

    let w = witness::place(&note, &tree, idx, &quote.params());
    let proven = prove("circuits/build_resting", "place_resting", "pr.zkey", &w.inputs)?;
    let ix = market.place_order_ix(payer.pubkey(), quote.args(), &proof_of(&proven));
    sign_and_submit(ix, &payer, &[], &mut sub)?;     // relayer-submitted

    sleep(interval);
}
Locked decision
An agent can only ever buy capital efficiency, a tighter re-arm, a faster reaction, a live two-sided book. It can never be load-bearing for solvency: liquidation and funding are enforced by the program and hold even if every agent goes offline. Build with that line in mind.