Anonymous Credentials for Trustless Agents (ACTA)

zulu0echo · May 5, 2026, 9:50am

Anonymous Credentials for Trustless Agents (ACTA) - A Privacy Layer for the On-Chain Agent Economy

Special Thanks to Davide, Nam, Marco, Thore, and Vivian for feedback and reviews.

May 2026

TL;DR

ERC-8004 (Trustless Agents) produces a permanent, public interaction graph between AI agents and their clients - every reputation signal, every credential check, every delegation is immutably on-chain.
Whilst ERC-8004 is useful for agent deployments where transparency is needed, a privacy-preserving solution will be essential for cases where the interaction graph is itself sensitive data.
ACTA proposes a composable privacy layer above ERC-8004 using Anonymous Credentials, so agents can prove claims - personhood, audit score, model provenance, reputation, jurisdiction - without revealing underlying data.
ACTA also addresses the principal layer: agents can prove they are acting under a verified human principal using personhood credentials (Adler et al., 2024), enabling governance and DeFi protocols to exclude fully autonomous bots without exposing any participant’s real-world identity.
The ICircuitVerifier Abstraction intentionally decouples ACTA from any specific proof system: SNARKs, STARKs, zkVMs, and future post-quantum constructions are all first-class backends, swappable per policy without changing the ACTA contract.
This post introduces the draft, walks through seven concrete on-chain use cases deployable today, and invites collaboration from the ecosystem, builders, DeFi protocol developers, and ERC-8004 authors.

Introduction

Consider a DeFi protocol that routes execution through specialised AI agents - a liquidity routing agent, a risk assessment agent, and a liquidation agent. Each is registered on-chain via ERC-8004, building reputation through verifiable feedback as trades settle. The routing agent calls the risk agent fifty times a day. The liquidation agent receives quality scores every block. Every one of these interactions is permanently and immutably public: the calling address, the agent’s identifier, the feedback score, and the task endpoint tag. Anyone running an event indexer can reconstruct exactly which protocol is using which execution layer, how often, with what quality outcomes, and which agent vendors are winning the market. For a protocol whose edge is its execution strategy, that interaction graph is the alpha. Publishing it by default to a global public ledger is not just a privacy concern, it is an immediate economic attack surface.

This is not confined to DeFi. Any onchain interaction where participants are routing resolution queries through AI agents will expose their workflows. The accountability properties that make on-chain agent trust valuable - verifiable reputation, auditable credential claims, and composable feedback- are also the properties that make the current ERC 8004 design incomplete for many real on-chain use cases.

Zero-knowledge proofs can be used to allow an agent to prove it satisfies a score threshold, holds an approved model hash, and operates outside a sanctions list - privately. Anonymous credential schemes allow reputation feedback to be submitted without linking it to the submitter’s address. Nullifier mechanisms prevent double-use without identity disclosure. ACTA brings all of this to the on-chain agent economy as a composable, privacy layer that sits above ERC-8004 without modifying it.

Background

ERC-8004 addresses an infrastructure gap: how do agents and clients establish trust across organisational boundaries without any pre-existing relationship? It proposes three on-chain registries.

The Identity Registry gives every agent a portable ERC-721-based identifier.
The Reputation Registry provides a standard interface for posting and reading feedback signals, composable with any scoring system.
The Validation Registry allows agents to request and record independent verification of their outputs.

For an agent economy that needs an open, interoperable trust layer, this is the right foundation. ACTA is an extension of that foundation.

The Privacy Gap

ERC-8004’s current design creates five specific, exploitable vulnerabilities for any deployment where the interaction graph carries personal, economic or regulatory sensitivity:

Permanent public interaction graph. The NewFeedback event emits clientAddress, agentId, value, and task tags in plaintext, immutably on-chain. Attack scenario: A competing DeFi protocol indexes these events to identify which execution agents a rival is using, how frequently, and with what quality ratings - reconstructing their AI execution strategy in real time.
No unlinkability across sessions. The readAllFeedback() function enumerates every interaction for any given client address and agent. Multiple interactions by the same client are trivially linkable, enabling statistical inference about trading patterns or analytical workflows.
No selective disclosure of credentials. An agent’s agentURI registration file exposes all capabilities, endpoints, DID, ENS name, and wallet address simultaneously. A counterparty asking “is this agent compliant for my jurisdiction?” receives the agent’s full operational profile, including potentially commercially sensitive details.
Sybil resistance requires reviewer identification. ERC-8004 acknowledges that getSummary() requires a non-empty clientAddresses[] filter because unfiltered results are vulnerable to Sybil spam. The intended mitigation requires reviewers to be identifiable on-chain.
Cross-registry fingerprinting. The combination of agentId (ERC-721 token), agentWallet (explicitly linked on-chain), and the optional DID field in the registration file creates a unique three-dimensional fingerprint that collapses separated identity contexts into a single traceable profile, across on-chain and off-chain systems.

The Core Idea: Anonymous Credentials for Trustless Agents

With anonymous credentials in real life, you could present a cryptographic proof that says only “this person’s birthdate, attested by a government issuer, satisfies the predicate age ≥ 18”

Scale this to on-chain AI agents. Example: A DeFi protocol’s risk management contract needs to verify that the execution agent it is about to delegate a trade to has a sufficient audit score, an approved model version, and the operator is not on an OFAC list. With anonymous credentials:

The agent generates a proof that its credential satisfies all three predicates simultaneously.
The protocol verifies the proof on-chain.
One event is emitted: an unlinkable nullifier and the policy ID that was satisfied.

The agent’s actual audit score, model hash, and jurisdiction are never published anywhere.

ACTA: Possible Components

Credential Anchoring (IOpenACCredentialAnchor). Before an agent can make anonymous presentation proofs, it registers a cryptographic commitment to its credential on-chain. This is a blinded hash of the agent’s master secret combined with its credential attributes — it proves the credential exists and was validly issued without revealing any attribute value. The anchor contract verifies a zero-knowledge proof of correct commitment formation (using whichever ICircuitVerifier the operator selects), then stores only the commitment hash, the issuer key commitment, the credential schema identifier, and an expiry timestamp. No credential details appear on-chain. This is the prerequisite that all downstream proof flows depend on.

Policy Registry (IPolicyRegistry )- a verifier (a DeFi protocol, a DAO, an on-chain compliance oracle) registers a policy as a boolean predicate program: audit_score >= 80 AND operator_jurisdiction_not_in(OFAC_LIST). The policy lives on-chain as a hash. The PolicyDescriptor includes the predicate program hash, the credential schema, the issuer commitment, a validity window, and critically, the address of the ICircuitVerifier implementation to use for proof verification. Policies are immutable once registered.

Predicate Verification (IPredicateVerifier) - when an agent presents a proof that its credential satisfies a registered policy, this contract handles the per-call verification. It reads fromIPolicyRegistry, delegates verification to the registered ICircuitVerifier, registers the resulting nullifier, and emits a PresentationAccepted event containing only the policy ID, the nullifier, and an expiry timestamp. No agent identity, no attribute values, no wallet address are revealed.

Nullifier Registry (INullifierRegistry). Nullifiers are context-scoped: each is derived from the agent’s master secret combined with a context hash that includes the verifier’s address and a session nonce. The same agent’s nullifier for verifier A is computationally unrelated to its nullifier for verifier B. Within a single session context, double-use is detected and rejected, providing per-session Sybil resistance without global identity disclosure.

ZK Reputation Accumulator (IZKReputationAccumulator). Clients submit reputation feedback as a zero-knowledge proof demonstrating they hold a valid interaction credential and have not already submitted feedback in this context. Feedback values are stored as blinded Merkle tree leaves — committing to the nullifier, value, whilst hiding the value from the event log.

The accumulator writes its Merkle root back into ERC-8004’s existing Reputation Registry using the standard giveFeedback() interface with a reserved tag, maintaining composability with any ERC-8004-aware reputation aggregator. An agent can later prove its aggregate anonymous score exceeds a threshold without revealing any individual feedback entry.

Example: Protocol Flow

Actors Created: Issuer, Agent, and Verifier each get a did:ethr identity anchored to an Ethereum address.
Schema Configured: The Issuer defines what an AgentCapabilityCredential contains fields like auditScore, operatorJurisdiction, and capabilities.
Credential Issued: The Issuer issues the agent wallet a signed JWT-VC, the credential stays off-chain.
On-Chain Anchor: The agent computes a commitment and Merkle root over its credential and writes them to OpenACCredentialAnchor, specifying the ICircuitVerifier implementation it will use for proofs.
Predicate Built: The Verifier defines its compliance rules as a structured predicate (e.g. auditScore ≥ 80 AND caps ⊇ 'evm-execution'), compiles it using the OpenAC generalized-predicates package [GP-PACKAGE-API: substitute actual compiler call], and derives a deterministic predicateProgramHash [GP-PACKAGE-API: substitute actual hash computation method].
Policy Registered: The Verifier calls IPolicyRegistry.registerPolicy() on-chain, locking in the predicate hash, trusted issuer commitment, and the address of the chosen ICircuitVerifier under a policyId.
Presentation Request: The Verifier sends the agent the policyId, a fresh sessionNonce, and its address — scoping the proof to this interaction only.
Proof Generation: The agent’s OpenAC wallet compiles the predicate via the generalized-predicates package [GP-PACKAGE-API], generates a ZK proof client-side, with public outputs nullifier, contextHash, and predicateHash but no credential values.
Verified: The Verifier submits the proof to IPredicateVerifier.verifyPresentation(). The contract delegates entirely to the registered ICircuitVerifier, registers the nullifier, and emits PresentationAccepted(policyId, nullifier, expiryTimestamp).
Access Granted: The agent presents its nullifier to AgentAccessGate — granted on first use, reverted with NullifierAlreadyActive on replay.

*Revocation is considered out of scope for this post. PSE has extensive research on revocation design strategies, they can be found here.

Use Cases: On-Chain Applications

DeFi Protocol Agent Delegation

As DeFi protocols increasingly route execution through specialised AI agents, the question of how a protocol’s smart contracts should trust those agents becomes urgent. Under ERC-8004, every delegation check and every quality rating a protocol posts is permanently public. Under ACTA, the protocol registers a capability policy in IPolicyRegistry and the agent presents an anonymous predicate proof against it via IPredicateVerifier. The protocol chooses its ZK backend when it registers the policy. The protocol contract calling verifyPresentation is indifferent to which backend was chosen; it reads the same policyId and receives the same PresentationAcceptedevent either way.

Censorship-Resistant Agent Reputation

Prediction markets, lending protocols, and any system that relies on agent quality signals face the same problem: under ERC-8004, meaningful reputation can only be submitted by identified reviewers. Because getSummary() requires a non-empty clientAddresses[] filter to prevent Sybil attacks, anonymous sources cannot contribute. Any actor — a dominant protocol, a well-resourced competitor — who can identify and pressure a reviewer can suppress their feedback entirely. The participants best placed to identify misconduct are silenced because speaking up is economically self-destructive: a prediction market participant flagging a biased resolution agent permanently links their address and therefore their open positions. ACTA’s ZK reputation accumulator resolves this directly. Any credential holder can submit feedback without their address appearing on-chain; the nullifier mechanism prevents double-voting; the accumulator root is anchored back into ERC-8004’s Reputation Registry as a composable signal.

Private Credential Verification for Agent-to-Agent and Agent-to-Protocol Interactions

As AI agents begin executing on-chain transactions — swaps, loans, transfers, contract calls — on behalf of human principals, regulated protocols face a new compliance challenge: how do you verify that the agent acting in a transaction has an operator who has passed credential checks, operates in a permissible jurisdiction, and is not on a sanctions list — without requiring the agent to broadcast its operator’s identity to the entire chain for every transaction? Under ERC-8004, there is no mechanism for this; the agent’s public registration links its agentId to its operator’s wallet directly. With ACTA, the agent anchors a credential issued by a compliant identity provider, registers a capability policy requiring operator_jurisdiction_not_in(sanctionsList) AND credential_tier >= required_tier, and presents anonymous predicate proofs to regulated protocols for verifiable compliance. This maps directly to how FATF’s Travel Rule is expected to apply to autonomous agents under emerging guidance.

Self-Sovereign Agent Identity Across Protocols

A credential-verified agent operating on Uniswap’s agent delegation framework should be able to carry its reputation and compliance proofs to Aave, to any ERC-8004-compatible protocol, without reconstructing its interaction history from scratch for each protocol. Under ERC-8004, this cross-protocol portability exists but exposes the agent’s full interaction history across all protocols to anyone who correlates the agentId across registries. The agent’s operational history, vendor relationships, and credential profile become permanently legible. Under ACTA, the agent presents fresh anonymous predicate proofs to each protocol, scoped by context-specific nullifiers. Each protocol gets the verification it requires; no cross-protocol interaction graph is constructible from the chain data. An agent’s identity is something its principal has the final say over and more importantly, portable without being linkable.

Permissionless Agent Reputation Bootstrapping

A new agent entering the ERC-8004 ecosystem faces a cold-start problem: no reputation, no history, no social proof. The current solution — accumulate public feedback — requires the agent to transact publicly, exposing its entire early interaction history to permanent indexing before it has any meaningful market position to protect. Under ACTA, an agent can bootstrap reputation through the ZK accumulator from its first interaction, accumulating anonymous but verifiable reputation signals without publishing a permanent interaction graph. When the agent later proves to a prospective DeFi protocol that its aggregate score exceeds a trust threshold, that proof is valid regardless of whether the underlying feedback was submitted under ERC-8004’s public model or ACTA’s anonymous model — because the accumulator’s Merkle root is anchored back into ERC-8004’s Reputation Registry as a standard feedback signal.

Personhood Credentials and the Human-Behind-the-Agent Problem

The use cases above all concern the agent’s credentials — its audit score, model provenance, jurisdictional compliance. But there is a parallel and equally urgent problem at the principal layer: how does a DeFi protocol, a prediction market, or a DAO governance contract know that the agent submitting a transaction is acting on behalf of a real human, rather than a fully autonomous bot with no accountable principal behind it? Adler, Hitzig, Jain et al. (2024) define this as the personhood credential problem. A personhood credential (PHC) certifies that its holder is a real person without revealing any further identifying information, using the same unlinkable pseudonymity and zero-knowledge proof properties that ACTA applies to agent capability claims. The paper identifies verified delegation to AI agents as one of the three primary use cases for PHCs:

A principal links their personhood credential to an agent they control.
Agents are able to prove to services that a real human is accountable for the agent’s actions without disclosing who that human is.

This matters acutely for governance today: a DAO that wants to restrict voting or proposal rights to agents backed by real humans, rather than autonomous bots, currently has no privacy-preserving mechanism to enforce this.

Open Questions for the Community

Anonymity set sizing. The anonymity guarantee of a predicate proof is bounded by the number of other agents whose credential satisfies the same predicate, and each additional attribute constraint in a policy compounds the problem, potentially deanonymising an agent even when each individual constraint seems benign. What minimum threshold is appropriate for different risk contexts? One promising direction is using a VOPRF network (Verifiable Oblivious Pseudorandom Function).
Privacy-preserving on-behalf-of (OBO) delegation. The OpenID Foundation’s 2025 whitepaper on agentic AI identity identifies the move from agent impersonation to explicit delegated authority as the most urgent unsolved problem in the space. A proper OBO flow requires a credential encoding two distinct identities — the delegating human principal and the acting agent — but publishing both on a public chain permanently creates a delegation graph that is itself sensitive data. ACTA’s principal_vc_satisfies() predicate offers a ZK path: an agent proves its delegating principal holds a valid credential satisfying a policy without revealing who that principal is. How should this interact with existing OAuth 2.0 Token Exchange flows off-chain? For recursive delegation — where an agent delegates to a sub-agent — what is the minimum predicate expressiveness needed to verify the entire chain without a trusted intermediary?
Issuer bootstrapping and centralisation risk. In practice, who issues AgentCapabilityVCs? Audit firms, and TEE attestation services are the obvious candidates, but a small number of trusted issuers quickly becomes a trust bottleneck, and centralised issuers can de-anonymise credential holders by logging issuance. Is there a credible path to decentralised issuer registries for agent capability credentials that remain Sybil-resistant without reintroducing a trusted party at the registry layer? What are potential approaches for decentralized credential issuance?
Threshold decryption as a standard extension. ACTA is fully anonymous by default - a nullifier on-chain cannot be linked to its agent without the agent’s master secret. This is the right default, but it creates a gap for abuse cases: a malicious agent operating anonymously has no accountability mechanism. Should ACTA define a standard extension for threshold-committee de-anonymisation - where a multi-sig or threshold signature scheme among nominated trustees can, upon on-chain proof of demonstrated abuse, reveal the agent behind a specific nullifier? What governance mechanism selects and rotates the committee without recreating centralisation?
Cross-chain credential portability with unlinkability. Bridging credential Merkle roots across chains naively re-creates a linkability vector - the same root appearing on multiple chains can be correlated with the original anchoring transaction. Is there a sound design for cross-chain credential portability that preserves unlinkability?
Client-side proving: What are the practical thresholds - in proof size, on-chain verification gas, and prover latency - at which zkVM-based ICircuitVerifier implementations preferable to circuit-based ones for the ACTA use cases?
Private trust graphs for agent-to-agent interactions. ACTA’s current credential model is agent-centric: an AgentCapabilityVC attests to what a single agent is. But in a multi-agent economy, trust increasingly depends on what two agents are to each other — whether they have a prior verified interaction, a delegated relationship, or a shared principal. The interesting open question is whether a network of such private credentials can form a trust graph that is locally verifiable — where each agent proves only its immediate relationships — while remaining unlinkable globally, so that an observer cannot reconstruct the broader network topology. How should these credentials be issued, by whom, and under what revocation model?

Call to Action

To the ERC-8004 authors: ACTA is intended as a complement, not a competitor. The Reputation Registry’s giveFeedback() interface and the Identity Registry’s operator/owner model are leveraged directly. We are seeking early alignment on two specific integration points - the zkReputationRoot tag convention in giveFeedback(), and the operator permission check in anchorCredential() - before the draft hardens. Any concerns about design compatibility are best surfaced now.

To DeFi protocol developers, prediction market teams, and infrastructure builders: The six use cases in this post are our best guess of where the demand might be - but we may have missed specific deployment blockers that are obvious to you. If the model of “agent proves predicate, protocol verifies on-chain, no identity disclosed” doesn’t fit your actual architecture or regulatory constraints, that feedback is more valuable at the draft stage than at final review. Please engage in the discussion thread.

To EIP editors: We intend to submit ACTA as a formal Standards Track draft in the near term. Given that ERC-8004 is itself still in Draft status, there is a sequencing question about whether ACTA should wait for ERC-8004 to advance to Review before being formally submitted, or whether the two drafts should progress in parallel given that ACTA requires ERC-8004 but does not modify it. We would welcome guidance on the preferred process.

We are looking for proposals and submissions for protocol designs. Please reach out to the Private Proving team at PSE or comment below.