# zkAPI

Markdown version of https://l2beat.com/privacy/projects/zkapi

## Summary

**Warning:** The vault owner can block withdrawals until deposits expire and become sweepable to the treasury. The proofs rely on a single-party trusted setup.

- Total Value Locked: $2.33 K (+33.1% compared to seven days ago)
- Assets tracked: 1
- Buckets tracked: 1
- Deposits 7D: 13 (-81.9% compared to the previous seven days)
- Deposits 30D: 85
- Deposits Total: 85
- Tracked on: Ethereum
- Attributes: ZK, Any amount

### Risks

- Privacy: Link privacy. Public observer: Link private (sentiment: good); Chain analyst: Link private (sentiment: good); Network observer: Link private (sentiment: good); Privileged insider: Link at risk (sentiment: warning); Future adversary: Link at risk (sentiment: warning).
- Trusted setup: 1 participants (sentiment: bad). zkapi-v2-note-bound-v1 single-party setup: The published request and withdrawal keys were generated by one party. Retained setup secrets can allow forged proofs.
- Exit window: None (sentiment: bad). The owner can immediately pause cooperative closes and the start of escapes. An already pending escape can be finalized after 1 day, including during a pause. An active note becomes sweepable after its deposit expiry. This protocol fails the walkaway test: users cannot fully use it if every centralized participant disappears. Starting an escape needs an unpaused vault and the user's latest signed balance. The operator can cancel it with any request proof it holds for that balance, and only a new operator signature restores normal use.
- Reproducibility: Partially reproducible (sentiment: warning). The browser app and the local daemon have public source and build instructions. The verifier enclave image rebuilds from source and matches its hardware attestation. The hosted frontend, the daemon releases and the key stations remain unreproduced.

### About

Anonymous access to AI models, prepaid with ETH, that hides which deposit pays for which request.

### Links

- Website: https://chat.openanonymity.ai
- Docs: https://zkapi.openanonymity.ai
- Repository: https://github.com/ethereum/zkapi
- Contracts explorer (Disco): https://disco.l2beat.com/ui/p/zkapi

## Protocol description

zkAPI lets the user prepay AI usage with ETH and chat without revealing which deposit pays for which request. Deposits and withdrawals are public, and the model provider can read the user's prompts.

Users trust Open Anonymity, which runs the service and owns the vault, and the inference providers behind OpenRouter. The operator approves withdrawals and sees each request's time and budget. The owner can pause the vault, and expired deposits fall to its treasury. The user can leave without the operator through a 1 day escape, as long as their note has not expired.

### Architecture

Open Anonymity verifies request proofs before issuing API keys. Its signing keys are fixed in the vault. A new key requires proof that the user's balance covers a budget of at least 0.00005 ETH.

The user's app keeps the exact balance locally. The operator receives a commitment to the user's deposit. Initially, the balance equals the deposit.

The commitment is homomorphic: the operator can subtract a known charge without reading the balance. It signs the updated commitment. The local app checks the subtraction and signature, then stores the updated state.

The operator also runs the indexer and a challenger that disputes escapes from outdated balances.

### Flow

1. **Deposit** ETH from your wallet. The vault records its amount and an expiry about 1 month later.
2. **Request access.** The app proves an active note covers your chosen budget. The operator returns a short-lived OpenRouter key.
3. **Chat.** Send prompts to OpenRouter with that key.
4. **Settle.** The operator bills the key's usage.
5. **Withdraw.** A cooperative close needs the operator's clearance. The vault publishes the note id and remaining balance. It returns the remainder to your chosen address and pays usage to the treasury.

### Keys

Losing the note secret and latest signed balance that are saved by the app loses the funds.

### App

The ratings assume OA Chat, a hosted browser app with public source and local build instructions. It fetches the whole note tree and proves in the browser. It relays inference through a proxy at refraction.network by default, with a fallback to direct connections. The hosted build runs code beyond the public main branch, including analytics. zkapi-clientd is a local daemon with an OpenAI-compatible API. It asks the operator's indexer for the user's note path and reuses keys across requests, both of which can harm privacy.

### Providers and verifier

OpenRouter and the model provider can read prompts and responses and link requests under one key. Open Anonymity holds the OpenRouter accounts. A verifier running in an attestable Azure confidential container checks that OA's account has provider logging disabled. Its build reproduces from source and matches the attested measurement, see the verification steps. Both clients pin only the verifier's address, so the check only holds when the user verifies it personally.

### Exits

**Escape.** Without a cooperative close, the user starts an escape with their latest signed balance and finalizes it after 1 day. The operator can cancel it with a request proof for that balance, which publishes that request's link. While the owner pauses the vault, no one can start an escape, but one already started still finalizes.

### Compliance

The vault has no onchain screening. The operator can refuse keys or clearance.

### Fees

Usage is billed in USD and converted to ETH through a Chainlink feed, with no fee on top of the provider's price. The unused balance returns at withdrawal.

## Privacy

**What the protocol promises:** Hides which deposit pays for which API request. Deposits and withdrawals are public, and the provider can read prompts.

Ethereum is public by default. Each protocol is rated on its main privacy promise, like hiding who paid, who received, how much, or which deposit became which withdrawal. Against each adversary, the colour says whether it holds for a careful user with the app's own settings: green yes, yellow only with significant extra work, red no. Fields marked at risk stay private only under the condition in their note.

### Public observer

Link private (sentiment: good)

**Who:** Everyone with a block explorer and some basic tools. Sees every public onchain event, but does no correlation beyond following links. Examples: A curious counterparty, an employer, a journalist.

Requests stay offchain, so nothing onchain ties a request to the deposit that pays for it. A deposit publishes the funder, amount, note id and expiry. Closing the note publishes the payout address and the remaining balance, so each note's total spend is public.

**Inside**

- Sender: exposed
- Recipient: exposed. Payments go to the operator treasury.
- Amount: at risk. Charges per request stay offchain. Closing the note publishes the total.
- Asset: exposed
- Link: private. An escape dispute publishes the link for one request.

**Sources**

- [ZkApiVault](https://l2beat.com/privacy/projects/zkapi#ZkApiVault)
- [Deposit and close events](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/contracts/src/libraries/Events.sol#L6-L10)
- [Request circuit keeps note id, balance and state signature private](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/rust/crates/zkapi-proof/src/groth16.rs#L368-L485)

### Chain analyst

Link private (sentiment: good)

**Who:** Scrapes all public data and correlates it: timing, amounts, gas and wallet fingerprints, address clusters. Examples: Chain analytics firms, ZachXBT, data brokers.

Authorizations never reach the chain, so correlating public data adds nothing to the note record.

Inside, the same as for a public observer.

**Sources**

- [Authorization is an HTTP request to the operator](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/docs/api-spec.md)

### Network observer

Link private (sentiment: good)

**Who:** Sits between the user and the services and sees traffic only: ISPs, VPNs, Tor exits, public RPCs and relayers. Learns IP addresses, timing, fingerprints and ciphertext. Services the operator runs count as the insider. Examples: Infura or Alchemy, a Tornado relayer, a wallet vendor selling telemetry, Google captcha or analytics in the dapp frontend.

The app works in Tor Browser, the daemon has a Tor setting with a kill switch, and no third party sees both a deposit and a request. The RPC serving the user's wallet sees the deposit, while requests go to the operator and the provider. The app sends inference through a relay at refraction.network by default, which sees its timing. The hosted app reports feature use to Fathom, a cookieless analytics service.

**Advice:** Use the app in Tor Browser, or the daemon with its Tor setting, and send the deposit through a public RPC over Tor.

**Inside, compared with a public observer**

- Link: at risk. Private only over Tor, which keeps the user's IP off both sides.

**Sources**

- [Daemon Tor route has a kill switch](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/zkapi-clientd/docs/CLI_ZKAPI.md#L81-L97)
- [App relay on by default, direct fallback](https://github.com/OpenAnonymity/oa-chat/blob/60ed5be2957d984c70a7299474927becec47b61f/chat/services/networkProxy.js#L7-L10)
- [Hosted app loads Fathom Analytics (checked 2026-10-10)](https://chat.openanonymity.ai)

### Privileged insider

Link at risk (sentiment: warning)

**Who:** Holds an operator role, custodies funds, receives keys or plaintext by design, or delivers the client: upgrade admin, custodian, view key holder, enclave operator, association set provider, hosted prover, registry, frontend host. Examples: A compliance backdoor key, a DAO with an upgrade key, a KMS committee, an ASP operator, a custodial bridge.

The operator sees each request's time and budget but not its note, so the candidates are all active notes, a small set. The daemon reveals the note id to the operator's indexer before each request. An escape dispute lets the operator publish one request's link onchain. The provider can read prompts and responses and link requests under one key.

**Advice:** Use the browser app rather than the daemon, and wait a day or more between depositing and the user's first request. Run an inspected local build of the client instead of the hosted frontend.

**Inside, compared with a public observer**

- Recipient: exposed
- Amount: exposed. The operator bills each request and the provider meters it.
- Link: at risk. Timing narrows a small set, and daemon users reveal the note id.

**Sources**

- [Balance commitment re-blinded for every request](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/docs/note-bound-commitments.md)
- [Daemon fetches the note path by note id](https://github.com/ethereum/zkapi/blob/20aa542ae98e767c0507133fd34b12a56f5ccd3d/crates/zkapi-clientd/src/indexer.rs#L71-L80)
- [challengeEscapeWithdrawal publishes a request proof](https://l2beat.com/privacy/projects/zkapi#ZkApiVault)
- [Provider sees inference content](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/zkapi-clientd/docs/PRIVACY.md)

### Future adversary

Link at risk (sentiment: warning)

**Who:** Harvest now, decrypt later. Holds every byte ever written onchain plus any retained logs, and breaks all public-key cryptography, by quantum computer or new mathematics: elliptic curves, pairings, RSA, lattices and isogenies. Hashes, Poseidon included, and symmetric ciphers survive. Examples: An intelligence agency archiving chain data today, then anyone once a break is public.

Onchain data stays hashed, but retained operator transcripts and indexer logs would tie requests to deposits. Note leaves and nullifiers are Poseidon hashes. Whoever breaks elliptic-curve cryptography opens only the balance commitment that a published dispute carries.

**Advice:** Assume the operator and provider keep what the user sends.

**Inside, compared with a public observer**

- Amount: at risk. Per-request charges exist only in operator records.
- Link: at risk. Depends on what the operator retains.

**Sources**

- [Transcript store](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/crates/zkapi-serverd/src/nullifier_store.rs)
- [Note-bound commitments and assumptions](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/docs/note-bound-commitments.md)

## Value Locked

The interactive value chart is shown on [the HTML page](https://l2beat.com/privacy/projects/zkapi#privacy-tvl).

## Flows

The interactive flows chart is shown on [the HTML page](https://l2beat.com/privacy/projects/zkapi#privacy-flows).

## Assets Breakdown

| Asset | Deposits 7D | Deposits 30D | Deposits Total | Value Locked |
| --- | --- | --- | --- | --- |
| ETH | 13 ($1.07 K) | 85 ($3.03 K) | 85 ($3.03 K) | $2.33 K |
| Total | 13 ($1.07 K) | 85 ($3.03 K) | 85 ($3.03 K) | $2.33 K |

## Risk summary

### Funds can be stolen if

1. the owner pauses withdrawals until notes expire and anyone sweeps them to its treasury.
2. the single-party setup secrets or a circuit flaw allow forged withdrawal proofs.
3. malicious wallet code reads the note secret.

### Funds can be lost or frozen if

1. the note secret or the latest signed balance is lost.
2. a note expires before withdrawal.
3. the operator withholds a signed balance and cancels the escape with the request it received.

### Privacy can be lost if

1. the operator matches a deposit to its requests by timing, which few active notes make easy (see privileged insider).
2. a daemon user reveals the note id to the operator's indexer before each request (see privileged insider).
3. prompts identify the user to OpenRouter or the model provider (see privileged insider).
4. the operator keeps request transcripts and indexer logs, which later tie requests to deposits (see future adversary).

## Upgrades & Governance

The vault, verifier, signing keys and exit parameters are immutable. The owner EOA can set the treasury, pause deposits, cooperative closes and the start of escapes, and transfer or renounce ownership, all without delay. Pending escapes still finalize during a pause. An instant pause with a subsequent sweep after expiry would steal all funds whose escape was not started before the pause.

The operator's services, the hosted app and the daemon releases are controlled by Open Anonymity and can change without notice.

## Trusted setup

Risk levels follow the [Trusted Setups Risk Framework](https://forum.l2beat.com/t/the-trusted-setups-framework-for-zk-catalog/381). Yellow (medium risk): all contributions are published and the final output can be verified, the ceremony client is open source, there were at least 30 contributions, participation was open to the public and announced, and participants are publicly identified. Green (lowest risk): everything required for yellow, with at least 150 contributions. Red (highest risk): at least one requirement for yellow is not met. N/A: the proof system needs no trusted setup.

### zkapi-v2-note-bound-v1 single-party setup

- Risk: red (highest risk)
- Proof systems: Arkworks (Groth16)

The request and withdrawal Groth16 keys were generated by one party. There was no multi-party ceremony. Security requires that this party erased the setup secrets, otherwise it can forge withdrawal proofs. Matching public artifacts cannot prove erasure. [Setup implementation](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/rust/crates/zkapi-proof/src/compact.rs#L288-L383), [provenance](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/setup/v2/README.md).

## Verifier IDs

### zkapi note-bound request and withdrawal verifier

- Verifier ID: `0xd31acf861825869e6a84b6b0025cb6940077f5981a10e73d2e4e8e5d7417c853`
- Source: https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/rust/crates/zkapi-proof/src/groth16.rs
- Verification: not verified
- Used in: [zkAPI](https://l2beat.com/privacy/projects/zkapi)

**Known deployments**

- [0x8e92013Dd7cc86f75b539DBD3814B2e603e0F9C1](https://etherscan.io/address/0x8e92013Dd7cc86f75b539DBD3814B2e603e0F9C1#code) on Ethereum, used in: [zkAPI](https://l2beat.com/privacy/projects/zkapi)

#### Verification steps

##### Contracts and proof artifacts

Reviewed [ethereum/zkapi revision](https://github.com/ethereum/zkapi/tree/045b444ea1b52538d1b40273c7cb6ed09468a052), whose vault, adapter and circuits match the deployment revision reported by the production manifest. Compile with the checked-in configuration: solc 0.8.28, optimizer 200, viaIR and Prague.

```bash
git clone https://github.com/ethereum/zkapi.git
cd zkapi
git checkout 045b444ea1b52538d1b40273c7cb6ed09468a052
cd demo/contracts
forge build --skip test --build-info
cast tx 0xf753fd93c7e672f7b851f261f600e06930e502bdfd73be29ce8a065643df6985 --json --rpc-url "$ZKAPI_RESEARCH_RPC_URL" > vault-tx.json
cast tx 0x45f2f5259476afd5f64a6a62a36c9012c3a26efcdd35b048a7fac5ae1ba43780 --json --rpc-url "$ZKAPI_RESEARCH_RPC_URL" > verifier-tx.json
```

The adapter creation bytecode matches exactly, including metadata. The vault matches after linking the discovered Poseidon address. Decode its ten constructor arguments from the remaining transaction input. Sources are verified on Etherscan: [vault](https://etherscan.io/address/0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe#code), [adapter](https://etherscan.io/address/0x8e92013Dd7cc86f75b539DBD3814B2e603e0F9C1#code), [Poseidon](https://etherscan.io/address/0xc6B55e86668d8c446B3D81273AAb9CBb20F28c7f#code).

The deployed verification-key coordinates and public inputs match the [published setup artifacts](https://github.com/ethereum/zkapi/tree/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/setup/v2), and the proving-key hashes match the SDK and production pins. A single-party setup with fresh randomness yields different keys each time, so matching artifacts show that the deployed keys are the published ones. Only the setup party knows whether its secrets were erased.

##### Frontend and local client

The [browser frontend](https://github.com/OpenAnonymity/oa-chat/blob/60ed5be2957d984c70a7299474927becec47b61f/README.md#quick-start) and the [local API daemon](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/zkapi-clientd/README.md) have public source and build instructions. Both still depend on the operator's authorization and inference services.

##### Verifier enclave

The mainnet verifier is `verifier-production-20260917.openanonymity.ai`, pinned in the hosted app's [browser config](https://chat.openanonymity.ai/zkapi/browser-config.json). It runs in an Azure confidential container on AMD SEV-SNP and serves a hardware attestation. Its source, [OpenAnonymity/oa-verifier](https://github.com/OpenAnonymity/oa-verifier), is pinned to commit `4299cfa` by the [production rollout](https://github.com/OpenAnonymity/oa-verifier/blob/86b7031c2f15d01d19efb77f547812e29992d4d9/deploy/production/rollout.py#L27-L29).

```bash
curl -sS "https://verifier-production-20260917.openanonymity.ai/attestation?nonce=$(date +%s)" > attestation.json
# 1. the JWT in .token is signed by Azure Attestation (.verify_at), its x-ms-sevsnpvm-hostdata equals sha256 of the decoded .policy
# 2. the policy lists one dm-verity layer hash for the verifier container
git clone https://github.com/OpenAnonymity/oa-verifier && cd oa-verifier
git checkout 4299cfa136c90550737dd46c89dba586c213159b
nix build .#container && docker load < result
# 3. push oa-verifier:latest to a local registry, then
go install github.com/Microsoft/hcsshim/cmd/dmverity-vhd@v0.12.9
dmverity-vhd roothash -i localhost:5000/oa-verifier:latest
```

The rebuilt image matches the published `ghcr.io/openanonymity/oa-verifier@sha256:60f9892b…` in nix store path, config and layer, and its layer root hash equals the attested policy. Pushing through a different docker version changes the compressed manifest digest, while the measured layer hash stays. The attestation also binds the TLS key of the live endpoint. Both clients pin only the verifier's address, so repeat the check when it matters.

## Ossification & Updates

Each date links the update on the HTML page, which also shows its contract diffs.

### [2026-10-07 11:41 UTC](https://l2beat.com/privacy/projects/zkapi?update=193c1624) (3 changes)

Initial discovery of the active native ETH vault, its Groth16 proof adapter and linked Poseidon library. All three contracts were verified from public source. The owner can pause new exits and change the treasury.

## Permissions

Explore these contracts and permissions in Disco, L2BEAT's contract explorer: https://disco.l2beat.com/ui/p/zkapi

### Ethereum

#### Actors

##### EOA 1

Addresses: [0x83f7eA47811A288f2052Bc31aaAE0803c761D156](https://etherscan.io/address/0x83f7eA47811A288f2052Bc31aaAE0803c761D156)

- Can interact with ZkApiVault
  - pause and unpause deposits, cooperative withdrawals and new escape withdrawals, and change the treasury receiving consumed balances and expired notes. Pausing can prevent users from exiting before their notes become sweepable

## Smart contracts

Explore these contracts and permissions in Disco, L2BEAT's contract explorer: https://disco.l2beat.com/ui/p/zkapi

### Ethereum

#### ZkApiVault

Addresses: [0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe](https://etherscan.io/address/0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe#code)

Escrows ETH for anonymous API authorizations as publicly numbered notes. A Groth16 proof closes a note with operator clearance, or starts a delayed escape that any request proof with the same nullifier cancels. Closing reveals the note id, payout address and remaining balance and sends the used part to the treasury. Anyone can sweep an expired note entirely to the treasury, also while paused.
- Roles:
  - **owner**: EOA 1

#### Groth16ProofAdapter

Addresses: [0x8e92013Dd7cc86f75b539DBD3814B2e603e0F9C1](https://etherscan.io/address/0x8e92013Dd7cc86f75b539DBD3814B2e603e0F9C1#code)

BN254 Groth16 verifier containing the request and withdrawal verification keys for zkapi-v2-note-bound-v1. Request proofs hide the note identity, exact balance and state signature. Withdrawal proofs expose the note id, destination, final balance and nullifier. The published circuit-specific keys were generated in a single-party setup. Retained setup secrets can allow forged proofs.

#### Bn254Poseidon

Addresses: [0xc6B55e86668d8c446B3D81273AAb9CBb20F28c7f](https://etherscan.io/address/0xc6B55e86668d8c446B3D81273AAb9CBb20F28c7f#code)

Linked Poseidon hash library used by the vault for active-note leaves and Merkle updates. Its BN254 parameters must agree with the request and withdrawal circuits.