Cloak.

Abstract

AI agents operating on Ethereum face a structural privacy problem: every payment, every attestation, and every on-chain action is publicly linkable. An agent that pays for API access, settles a trade, or asserts a credit tier reveals its full behavioral graph to any observer. This is not a theoretical risk — it is the default state of every public chain.

Cloak is a privacy infrastructure layer that lets AI agents transact, attest, and build reputation on Ethereum without exposing the underlying data. It is not a privacy coin, a mixer, or a data marketplace. It is a set of composable primitives — zkPay, zkAttest, zkScore, and zkPolicy — built on Groth16 zero-knowledge proofs, anchored on-chain via Poseidon commitments, and callable from a TypeScript SDK.

The protocol is designed to be the privacy rail that other agent protocols plug into — an ERC-8004 compatible, x402-adjacent, composable primitive that any agent wallet can call without requiring a trusted intermediary.

The Problem

Public-by-default chains expose agents

Ethereum is a public ledger. Every transaction, every event log, every storage slot is permanently visible. For humans making occasional payments this is an acceptable tradeoff. For AI agents — which may execute hundreds of payments per day across structured behavioral patterns — it is a critical vulnerability.

An agent paying for inference via x402, purchasing API access from multiple data providers, settling on-chain trades, and asserting a credit tier to access capital: each action is innocuous alone. Together they form a detailed behavioral fingerprint that counterparties, competitors, and adversaries can exploit.

Existing solutions are not composable

Privacy solutions exist — RAILGUN, Aztec, Tornado Cash — but they are built for humans making discrete transfers, not agents executing policy-governed, structured workflows. They offer no native concept of attestations, credit tiers, spending policies, or reputation. They cannot be called from a TypeScript SDK in three lines of code.

Reputation requires proof, not disclosure

Agents need to prove they are creditworthy, KYC-compliant, or policy-governed without disclosing the underlying data. A human proves they are over 18 by showing an ID; the verifier learns "yes" or "no" only. Agents deserve the same primitive.

Architecture

Cloak is structured as four composable modules sharing a common commitment and proof layer. The system separates the data plane (off-chain, private) from the verification plane (on-chain, public-but-opaque).

System components

Data flow

All sensitive data stays off-chain. What reaches the chain is only a Poseidon hash of the commitment and a nullifier preventing replay. The ZK proof travels from the prover to the verifier, where it is checked against the on-chain verification key — revealing nothing about the private inputs.

zkPay — Private Payment Intents

zkPay is an x402-compatible intent layer that lets agents pay without creating a traceable payment graph.

Flow

An agent creates a payment intent specifying the recipient, amount, chain, and a policy manifest — a signed set of constraints (max amount, allowed receivers, cooldown window, deadline). The gateway anchors a hash of the intent on-chain. At settlement the agent submits a nullifier — a single-use token proving payment completion — without linking the settlement back to the original intent on-chain.

Policy manifest fields

On-chain footprint

The chain records only: a Keccak256 hash of the intent, a nullifier on settlement, and an optional policy root. No amount, no counterparty address, no timing correlation.

zkAttest — Private Attestations

zkAttest lets agents prove properties about themselves — credit tier, KYC status, score range — without revealing the underlying data.

Commitment scheme

The prover commits to a claim using Poseidon, a ZK-friendly hash function designed for arithmetic circuits. The commitment is registered on-chain in the AttestationRegistry, along with a nullifier to prevent replay. The raw claim never leaves the prover.

Proof generation

The prover runs a Groth16 circuit taking the raw claim as a private input and outputting only the proof and public signals (e.g., the band string "gold"). The on-chain ZKVerifier checks the proof against the pre-deployed verification key without learning the private input.

Supported claim types (Phase 1)

zkScore — Private Credit (Phase 2)

zkScore is an off-chain credit scoring service that produces band proofs — Bronze, Silver, Gold — without exposing the underlying numeric score. It is the reputation primitive for agent-native credit markets.

An agent's on-chain history (payment patterns, settlement times, nullifier frequency) is processed by a scoring oracle. The oracle produces a signed score, used as a private input to a Groth16 circuit. The circuit outputs only the band, never the score itself.

zkScore proofs are valid inputs to zkAttest, allowing credit reputation to compose with payment policy and identity attestations in a single verification step.

zkPolicy — Agent Guardrails (Phase 2)

zkPolicy introduces signed capability manifests — structured access control documents specifying what an agent is authorized to do, provably, without trusting the agent's self-report.

A manifest specifies: spending caps (per-transaction and per-period), allowed counterparties, required attestation tiers (e.g., "must have gold credit band"), cooldown rules, and expiry. Manifests are signed by an issuer key (the agent owner, a DAO, or an employer contract) and verified by the protocol — not the agent.

Manifests are composable: a top-level policy can delegate sub-policies to specialized agents, with constraints that tighten at each level. The ZK proof ensures compliance without revealing the full policy tree to counterparties.

Cryptography

Commitment scheme: Poseidon

Cloak uses Poseidon, a ZK-friendly algebraic hash function designed for arithmetic circuits. Unlike SHA-256 (which requires thousands of constraints per hash), Poseidon requires ~240 constraints on BN128 — making it practical for nested commitments and batch proofs.

Proof system: Groth16

Proofs are Groth16 zk-SNARKs on the BN128 curve. Groth16 produces constant-size proofs (~128 bytes), constant-time verification (one pairing check), and is supported natively by Ethereum via the EIP-197 BN128 precompile. A per-circuit trusted setup ceremony is required. For production, this is conducted as a multi-party computation (MPC) so no single party knows the toxic waste.

Anti-replay: nullifiers

Every intent and attestation includes a nullifier — a value derived deterministically from the prover's private key and the commitment nonce. Nullifiers are stored on-chain and checked before any settlement or verification. Each nullifier can only be consumed once.

Circuit inventory

All circuits are authored in Circom 2.x and compiled to R1CS + Wasm prover via snarkjs 0.7.x. Verification keys load from disk at gateway startup — dropping in a ceremony-generated VK requires no code changes.

$CLOAK Token

$CLOAK is an ERC-20 utility and governance token on Ethereum. It is the economic layer of the Cloak protocol, accumulating value through protocol activity rather than a pre-minted treasury.

Token economics

Fair launch

$CLOAK launches via Uniswap V3 with no presale, no team allocation, and locked liquidity provider tokens. There is no VC round, no whitelist, no insider advantage. The development fund accumulates via protocol fees only — no pre-mint.

Utility

Token holders can: stake to earn ecosystem rewards, vote on circuit upgrades and fee parameters, and pay for premium API tiers at a discount. In Phase 3, proof workers and oracle operators will be required to stake $CLOAK to participate in the network.

Threat Model

What Cloak protects against

Behavioral fingerprinting: an observer watching on-chain activity cannot link individual payments or attestations to a specific agent. The commitment scheme and nullifier pattern break the payment graph.

Data disclosure: raw claim data (credit scores, KYC details, score values) never appears on-chain or in API responses. The ZK proof is the only artifact that travels between prover and verifier.

Current limitations (Phase 1)

The API gateway is a trusted intermediary in Phase 1 — it processes cleartext intents before commitment. Agents under strong threat models should run a local gateway instance. Phase 3 decentralizes the gateway role via a relayer network with staking requirements.

Groth16 requires a trusted setup ceremony. Phase 1 uses placeholder verification keys for development. Production circuits require an MPC ceremony so no single party holds the toxic waste. Until the ceremony runs, the proof path accepts only placeholder-mode test proofs and correctly rejects real proofs.

Out of scope

Cloak does not protect against: compromise of the agent's private key, side-channel attacks on the prover environment, or network-level traffic analysis linking API calls to an IP address.

Roadmap

Conclusion

AI agents are becoming economic actors on Ethereum. They pay for services, build reputation, and operate under policy constraints — but they do so in public, with no privacy primitive designed for their use case.

Cloak is that primitive. zkPay removes the payment graph. zkAttest proves properties without disclosing them. zkScore builds credit reputation without revealing the score. zkPolicy enforces agent governance without trusting the agent's self-report.

The protocol is composable, chain-native, and designed to plug into the emerging agent economy: ERC-8004 registered agents, x402 paywall flows, and any system where agents need to transact without becoming surveillance targets.

For API access, integration support, or partnership inquiries: zkagentcloak@gmail.com  |  agent-cloak.com