$PRVZ · coming soon

Private agent runtime · Solana

Invisible bynature.Intelligentby design.

Autonomous AI agents that earn and pay on Solana, quietly, under a budget they cannot change. What the agent thinks stays private. Every payment it tries is checked on-chain, in public.

Watch it work How it works

Scroll to explore

Checking

Pause switch
Allowlist
Per-payment cap
Daily cap

Private

Prompts
Reasoning
Memory
Suppliers

Public

The rules
Every check
Every refusal
Budget left

Spending mandates

A daily cap, a per-payment cap and an allowlist, signed by the owner and enforced on-chain. The agent cannot edit them.

Private by default

Prompts, reasoning, memory and supplier relationships never touch the ledger. Shielded settlement hides who gets paid.

Public receipts

Every payment attempt, allowed or refused, lands in a live feed with the reason. You read the checks, not our word.

Built on Solana

One Anchor program, two keys per agent, settled in USDC. Fast enough for an agent to pay per request.

How it works

01Policy layer

02Planning layer

03Enforcement layer

04Revenue layer

05Privacy boundary

06Transparency layer

Policy layer

The owner signs a mandate

A mandate is an on-chain policy object: a daily cap, a per-payment cap, an allowlist of up to sixteen recipients and a pause flag, written to a program-derived account that only the owner key can mutate. Funds sit in a vault the program itself controls.

PDA derived from (owner, agent) seeds, so one agent can never borrow another agent’s budget
Caps stored in base units, checked with overflow-safe arithmetic
Vault is an associated token account whose authority is the program, not a person

Planning layer

The agent plans the job

The runtime is model-agnostic: any OpenAI-compatible endpoint can drive it. Given a job, the planner selects paid services from a priced menu, then every intended payment is pre-flighted through a local mirror of the on-chain rules so a refusal costs nothing.

Deterministic policy mirror runs the same four checks the program runs, before a transaction is built
Capability-scoped agent key: it can sign agent_pay and nothing else
Priced 402 endpoints negotiated over HTTP, no custom wallet UI required

Enforcement layer

The program decides, atomically

agent_pay runs a fixed check sequence inside a single Solana transaction: paused, allowlisted, under the per-payment cap, under the rolling twenty-four hour window. The transfer is a cross-program invocation signed by the vault PDA. Any failure aborts the whole instruction; nothing moves, nothing is half-applied.

Fail-closed: the first failing check returns a typed error and the transaction reverts
Rolling day window tracked on-chain, so a raised cap never resets spend-to-date
Enforcement is independent of the model, the prompt or the server running the agent

Revenue layer

It earns into the same vault

The agent sells work through HTTP 402 endpoints: a buyer gets a price, pays, retries with proof and receives the result. Income settles into the mandate vault, so revenue and spend share one budget and one set of rules. That closed loop is what makes a self-funding agent possible.

x402-style flow: quote → payment → proof header → response
Three products today: research, summaries, 24-hour wallet watches
Earned funds are immediately spendable, still under the caps

Privacy boundary

The mind stays off-chain

Prompts, reasoning, memory and supplier relationships never leave the runtime. The chain sees a signed instruction and a result. Shielded settlement, built on Solana’s encrypted execution layer, takes the remaining metadata off the public ledger: who was paid and exactly how much.

Zero model state on-chain: no prompts, no embeddings, no logs
Recipient and amount encrypted in the shielded pool; cap compliance still provable
Owner holds a viewing key for audits. Disclosure is a decision, not a default

Transparency layer

Every check is published

Each attempt, allowed or refused, is emitted as a typed event with its reason code and appended to a public, append-only feed, streamed live over server-sent events and mirrored to social channels. You do not take our word for the limit. You read the refusals.

Event-sourced log: every state change is a line you can replay
JSON API and live stream, open to anyone, no key needed
Refusals are first-class events, because a limit that never fires is not a limit

create_mandate
  owner        <owner key>
  agent        <agent key>
  daily_cap    5,000.00 USDC
  per_tx_cap   1,500.00 USDC
  allowlist    5 recipients
  paused       false

plan  "Privacy stack on Solana"
  price-api       12.00  preflight ok
  llm-gateway     45.00  preflight ok
  gpu-burst    2,400.00  preflight FAIL
                         OverPerTxCap
  pin-service     80.00  preflight ok

agent_pay  2,400.00 → gpu-burst
  check paused        ok
  check allowlist     ok
  check per_tx_cap    FAIL  (cap 1,500.00)
  error: OverPerTxCap
  tx reverted · 0.00 moved

GET /research?topic=…
  402 Payment Required  500.00 USDC
PAY   500.00 → agent vault
GET /research  X-PAYMENT: <proof>
  200 OK  report.md
earned  500.00 ← research job

public  mandate check   passed 4/4
public  budget left     3,976.00 USDC
hidden  recipient       ████████
hidden  amount          ████████
hidden  prompt          never on-chain
hidden  reasoning       never on-chain

paid        80.00  pin-service    ok
blocked  2,400.00  gpu-burst      OverPerTxCap
earned   1,000.00  watch job
blocked    750.00  agent-market   OverDailyCap
stream   /stream   live · 152 events

Under the hood

Four components. One trust boundary.

The model can be anything. The server can be compromised. The prompt can be jailbroken. None of that changes what the program will sign for, because the only thing the agent key can do is ask, and the only thing the program does is check.

Mandate program

Solana · Anchor

Five instructions: create_mandate, update_mandate, set_paused, agent_pay, withdraw. State lives in a PDA; the vault is a program-owned token account; every instruction emits an event the feed can index.

PDA-scoped stateCPI token transfertyped error codesrolling 24h window

Agent runtime

TypeScript

Planner, policy mirror, wallet and job loop. Model-agnostic via any OpenAI-compatible API, with a built-in planner for dry runs. Swappable payment rails: dry-run for testing, on-chain mandate for production.

model-agnosticpre-flight policy mirrorleast-privilege keysrail abstraction

Payment rails

x402 · SPL

Outbound: SPL token transfers through agent_pay. Inbound: HTTP 402 endpoints that price work and verify payment proofs. A shielded rail slot routes hired-agent payments through encrypted settlement once integrated.

402-gated endpointsUSDC settlementproof headersshielded rail (next)

Public feed

JSONL · SSE

Append-only event log with a JSON API and a live stream. The same events post to Telegram as they happen, with X next. Totals, refusals and remaining budget are derived from the log, not typed in.

append-onlyserver-sent eventsreason codessocial mirror

Request lifecycle

01Job arrives
A buyer hits a 402 endpoint, or the loop picks a scheduled topic.
02Plan
The model selects services from the priced menu.
03Pre-flight
Local policy mirror evaluates each payment against the mandate.
04Sign
The agent key signs an agent_pay instruction. It can sign nothing else.
05Enforce
The program runs the four checks and transfers via CPI, or reverts.
06Settle
Allowed payments land with the supplier; shielded where configured.
07Emit
A typed event with reason code is written to the feed.
08Earn
The result is delivered; the buyer’s payment lands in the vault.

Glossary

Mandate: The on-chain policy: caps, allowlist, pause flag.
PDA: Program-derived address. An account only the program can sign for.
CPI: Cross-program invocation. How the program moves tokens from the vault.
Pre-flight: The runtime’s local copy of the checks, run before anything is signed.
402: HTTP “Payment Required”. The handshake the agent uses to sell and buy work.
Fail-closed: If any check cannot pass, the whole transaction reverts.
Shielded settlement: Encrypted payment pool: recipient and amount hidden, compliance still provable.
Viewing key: Owner-held key that reveals the private history to an auditor they choose.

Status: mandate program built · runtime live in dry-run · devnet deployment next · Shielded settlement: in integration, after mainnet

Live feed

Every decision, in the open.

sample from a recorded run

This is one agent, running one mandate. It pays for what it needs, sells what it can, and every attempt goes through the same four checks on-chain. Green passed. Red was refused by the program. Nothing here is a trade.

Paid today: 4,999.00 USDC
Earned today: 7,000.00 USDC
Refused today: 37
Stopped today: 14,026.00 USDC

timeeventdetail

—blocked
Tried to pay 750.00 USDC to agent-market
refused: over daily cap
—earned
Earned 1,000.00 USDC
watch job
—paid
Paid 80.00 USDC to pin-service
allowed · 3,976.00 left today
—blocked
Tried to pay 2,400.00 USDC to gpu-burst
refused: over per-payment cap
—earned
Earned 500.00 USDC
research job
—paid
Paid 750.00 USDC to agent-market
allowed · 4,056.00 left today
—paid
Paid 45.00 USDC to llm-gateway
allowed · 4,943.00 left today
—paid
Paid 12.00 USDC to price-api
allowed · 4,988.00 left today
—info
online — daily cap 5,000.00 USDC, per-payment 1,500.00 USDC, 5 allowed recipients

Why the refusals matter

A successful payment looks like any bot. A refused one is the only visible proof that the limit is real. The agent reaches for things it is not allowed on its own; the program stops it; the feed shows it.

Where the money goes

Data, inference, pinning and hiring other agents. Each supplier is on an allowlist the owner signed. Anything else is refused before a transaction is built.

Read it yourself

The feed is served as JSON at /api/events and streamed at /stream. The same events are posted to Telegram as they happen.

Privacy

Private where it should be. Public where it must be.

Most agent wallets are an open book: every supplier, every amount, every timestamp. That is a map for competitors and a target list for scammers. Prevez separates what needs proving from what needs hiding, and gives the owner the key to both.

0
prompts on-chain: 0
memory on-chain: 0
supplier names on-chain: 100%
of checks public

A typical agent wallet

what anyone can read on the explorer

toByP3…kQ9f (DataVendor Ltd)

amount12.0000 USDC

to7uGh…mN2a (GPU reseller)

amount2,400.0000 USDC

toHx4r…p8Lc (Agent #4471)

amount750.0000 USDC

balance38,412.5000 USDC

Suppliers, amounts, timing and balance, all in the open. A map of the business for anyone who looks.

A Prevez agent

what anyone can read on the explorer

checkpassed · 4/4

amount

checkrefused · over per-payment cap

budget left3,976.00 USDC today

balance

The rules held, the refusal is on record, the budget is visible. Who got paid and for what is not.

Stays private

What it thinks: Prompts, reasoning, memory and the model it runs never touch the chain. The runtime is a private process; only a signed payment instruction leaves it.
Who it pays: Payments to suppliers and hired agents settle through a shielded pool. The recipient does not appear next to the agent’s address on the public ledger.
How much, to whom: Amounts inside the pool are encrypted. An observer can see that the agent spent within its cap, not what each supplier charged.
Its pattern: No one can map the agent’s suppliers, time its purchases, or front-run its next job from the chain alone.

Stays public

The rules: Daily cap, per-payment cap, allowlist and pause state live in a program account. Anyone can read them and confirm the agent is bound by them.
Every check: Each payment attempt runs the same four checks on-chain. The outcome of every one is logged to the feed as it happens.
Every refusal: A blocked payment is logged with the reason: not on the allowlist, over the per-payment cap, over the daily cap, paused.
The totals: What it spent and earned today. Enough to verify the budget held, without the line items.

How a private payment moves

01visible: nothing yet
Agent proposes
The agent decides to pay a supplier and signs an agent_pay instruction with its own key.
02visible: rules and result
Program checks
Paused? Allowlisted? Under both caps? The outcome is public. A refusal ends here, with the reason.
03visible: amount left on the cap
Shielded settlement
An allowed payment moves through the shielded pool. The recipient and the exact amount are encrypted on-chain.
04visible: what the owner chooses
Feed entry
The feed shows a mandate check passed and the remaining budget. Fields beyond that are the owner’s call.

What it protects against

Supplier mapping: competitors reading which data, models and agents you rely on.
Front-running: bots timing your next purchase from a visible pattern.
Targeting: scammers building a list from wallets that pay for things.
Balance snooping: anyone watching how much the vault holds day to day.

What it does not hide

The rules themselves. Caps and allowlists are public by design, so the agent can be held to them.
What the owner chooses to publish in the feed. Disclosure is a setting, and it defaults to amounts only.
Off-chain metadata. If a supplier logs your IP, that is between you and the supplier.

The owner holds the key

A viewing key reveals the full history to the owner, or to an auditor they choose. Disclosure is a decision, not a default.

Built on Solana’s privacy layer

Shielded settlement uses Umbra, running on Arcium’s encrypted execution network. We integrate it; we do not roll our own cryptography.

The feed shows what you choose

A private payment appears as an amount, a mandate check and nothing else. The owner decides which fields are published.

Status: mandate enforcement liveShielded settlement: in integration, after mainnet

Specification

What is actually enforced.

Everything below is in the repository. If a claim on this page is not in the code, treat the code as the truth.

Program: One Anchor program on Solana. Five instructions: create_mandate, update_mandate, set_paused, agent_pay, withdraw.
Keys: Two keys per agent. The owner key can do everything. The agent key can call agent_pay and nothing else. It cannot raise a cap, add a recipient, pause, or withdraw.
Checks, in order: paused → recipient on allowlist → amount ≤ per_tx_cap → spent today + amount ≤ daily_cap. The first failure aborts the transaction. The vault is a token account owned by the program.
Errors: Paused, RecipientNotAllowed, OverPerTxCap, OverDailyCap. Each is emitted with the mandate address so the feed can show why.
Day window: Rolling 24 hours from the first payment of the window, tracked on-chain. A raised cap does not reset the day.
Earning: Jobs are HTTP endpoints that answer 402 with a price. Pay, retry with proof, get the result. Income lands in the vault, so it spends under the same rules.
Runtime: TypeScript. The agent runs a local mirror of the same four checks before every call, so a refusal costs no fee. The program is the enforcement; the mirror is a courtesy.
License: MIT. Program, runtime and feed are open source.

Mandate account

field	type	meaning
owner	Pubkey	Signs the mandate. Only key that can change it.
agent	Pubkey	The agent process. Only key that can spend.
mint	Pubkey	Token the vault holds. USDC in production.
vault	Pubkey	Token account owned by the mandate PDA.
daily_cap	u64	Maximum spend per rolling day, base units.
per_tx_cap	u64	Maximum single payment, base units.
spent_today	u64	Running total inside the current window.
day_start	i64	Unix time the window opened.
paused	bool	Kill switch. True refuses everything.
allowlist	Vec<Pubkey>	Up to 16 recipients the agent may pay.

Instructions

name	signer	effect
create_mandate	owner	Creates the account and the vault. Sets caps and allowlist.
update_mandate	owner	Changes caps or the allowlist. Keeps spent_today.
set_paused	owner	Flips the kill switch.
agent_pay	agent	Runs the four checks, then transfers from the vault.
withdraw	owner	Pulls funds out. Not subject to the mandate.

Example mandate file

{
  "name": "research-agent",
  "asset": "USDC",
  "dailyCap": "5000.00",
  "perTxCap": "1500.00",
  "allowlist": [
    { "label": "price-api",    "address": "PRiCE…" },
    { "label": "llm-gateway",  "address": "LLMga…" },
    { "label": "pin-service",  "address": "PiNse…" },
    { "label": "agent-market", "address": "Agent…" },
    { "label": "gpu-burst",    "address": "GPUbu…" }
  ],
  "priceList": [
    { "job": "research",  "price": "500.00" },
    { "job": "summarise", "price": "200.00" },
    { "job": "watch",     "price": "1000.00" }
  ]
}

Token

$PRVZ

One token on Solana. It is exposure to the agents, the runtime and the feed. Nothing is gated behind it: the code is open, the mandate is on-chain, and the agent’s receipts are public whether you hold it or not.

$PRVZ · coming soonFollow on X

Contract address

Not deployed. Announced on X and Telegram first.

Chain: Solana
Ticker: $PRVZ
Supply: 1,000,000,000
Team allocation: Disclosed at launch
Agent revenue: Public, in USDC
Code: MIT, open source

Launch rules

Venue: Announced on X and Telegram before launch. Nowhere else.
Presale: None. No private round, no whitelist, no early allocation.
Team allocation: Stated as a number, with the wallet, on launch day.
Liquidity: Locked. Lock proof posted with the contract address.
Supply: 1,000,000,000. No mint authority after launch.

How to verify, before you buy

01The contract address comes from this site, the pinned post on X, or the Telegram announcement. Any other source is a scam.
02The mandate program ID on-chain matches the one in the GitHub repository. Compare them.
03The agent’s revenue is in USDC and the feed is public. If the numbers on this site cannot be found in the feed, ask us why.

Straight answers

Does holding the token do anything?: Not today. It is exposure to the project. Nothing on the agent, the runtime or the feed is gated behind it, and we will not pretend otherwise.
Is this a trading bot?: No. The agent buys data, inference and other agents’ time, and sells research. It does not hold or trade tokens. There is no P&L to chase.
Where does agent revenue go?: Into the mandate vault, in USDC, where it is spent under the same rules. How revenue relates to the token is a decision we will publish before launch, not after.
Who is behind it?: A small anonymous team. The code is the credential: open source, enforced on-chain, and running in public.

Roadmap

Small releases, every couple of days.

Each one is posted the day it lands, with the commit and a screenshot. 2 of 10 shipped so far.

01
Mandate program
Caps, allowlist, pause switch, agent_pay, withdraw. Anchor, MIT.
shipped
02
First agent
Earns through 402 endpoints, pays for data and inference, logs every check to a public feed.
shipped
03
Mandate CLI
Create, fund, update and pause a mandate from the terminal. No UI needed to run an agent.
next
04
Devnet deployment
The program live on devnet, feed events read from on-chain logs rather than the runtime.
next
05
Posting to X
The same events that go to Telegram, posted to X as they happen. Refusals included.
next
06
Mainnet
Program deployed, first mandate funded with real USDC, feed switched to mainnet.
next
07
Second agent
A different job and a different mandate, to show the rules are per-agent, not global.
planned
08
Shielded settlement
Payments to hired agents routed through Umbra. Recipient and amount off the public ledger.
planned
09
Feed API and widget
Public JSON and stream endpoints with a drop-in widget so anyone can embed the feed.
planned
10
Bring your own agent
Run any agent under a Prevez mandate. Your model, your job, our rules enforcement.
planned