ERC-8150
Pre-e

A standard for verifying that an autonomous agent is authorized, solvent, and acting within mandate - before any transaction settles on chain.

Contents

A verification step between intent and settlement.

ERC-8150 defines a standard interface for pre-execution zero-knowledge verification of payments initiated by autonomous agents. It lets a payment processor, wallet, or rollup confirm - without revealing private mandate data - that an agent has been properly authorized, has sufficient solvency, and is operating within its stated intent bounds.

In plain terms: a signature proves an agent wanted to do something. ERC-8150 proves that the thing they want to do is valid, before anyone executes it.

Signatures aren't enough for autonomous capital.

As AI agents begin to transact on behalf of users, businesses, and treasuries, the trust model that underpins today's signed transactions - "whoever holds the key is authorized" - breaks down. Agents hold ephemeral keys, make thousands of micro-decisions per minute, and can be coaxed into actions their principals never intended.

ERC-8150 introduces a verification layer that sits between the agent's signed intent and the settlement rail. It turns three core properties into verifiable claims:

Authorization - the agent has a mandate from its principal covering this action.

Solvency - the principal has funds to back the action at the moment of execution.

Intent-conformance - the action falls within the declared intent (counterparties, limits, time windows).

The verifier interface.

Implementations MUST expose a verifier contract conforming to the following interface:

interface IERC8150 {
  struct AgentProof {
    bytes32 mandateRoot;    // commitment to principal's mandate
    bytes32 intentHash;     // hash of this specific action intent
    bytes  zkProof;         // groth16 / plonk / halo2 proof blob
    uint64 notBefore;
    uint64 notAfter;
  }

  /// Pre-execution verification: returns true iff the proof witnesses
  /// authorization, solvency, and intent-conformance.
  function verify(AgentProof calldata p) external view returns (bool);

  /// Optional: emit a structured log for post-hoc audit.
  event Verified(bytes32 indexed mandateRoot, bytes32 indexed intentHash,
address indexed agent);
}

The proof circuit MUST witness:

membership of the agent's signing key in the principal's mandate Merkle tree;

that intentHash is within the mandate's declared action set;

a solvency commitment ≥ the payment amount, sourced from a trusted balance oracle;

the proof was generated inside the [notBefore, notAfter] window.

From mandate to settled transfer.

  1. 1. Mandate issuance. Principal commits a mandate Merkle root on-chain; the leaves encode permitted action classes, counterparties, and limits.
  2. 2. Intent proposal. Agent composes a concrete intent (e.g. "pay 200 USDC to vendor X for invoice Y") and signs it.
  3. 3. Proof generation. Agent's runtime produces a zk proof that the intent satisfies ERC-8150's three properties relative to the mandate root.
  4. 4. Verification. The settlement rail (rollup, payment processor, bank API) calls verify() before execution. Invalid proofs revert before any funds move.
  5. 5. Settlement & audit. On success, the rail executes the payment and emits Verified for downstream audit tooling.
Principalmandate
commit
Agentintent
sign + prove
ERC—8150verifier
verify
Settlerail
execute
Auditlog

Why a new ERC.

Existing standards (EIP-712 typed signatures, EIP-7702 account abstraction, EIP-4337 user operations) handle who signed a message and how it is dispatched. None of them answer the question "should this have happened at all?" before settlement.

ERC-8150 is deliberately minimal: a single verify() call, a canonical proof struct, and a simple event. It is designed to be wrapped by higher-level systems - agent registries, circuit libraries, rollup pre-confirmers - without prescribing their internals.

What the proof does not say.

A valid ERC-8150 proof attests to authorization, solvency, and intent-conformance at proof time. It does not attest to the correctness of the underlying oracle, the mandate's suitability for the agent's actual purpose, or the behavior of the rail after verification. Implementers SHOULD treat the proof as a necessary but not sufficient condition, and pair it with rail-side enforcement of the notAfter window.