ERC-8150: Zero-Knowledge Agent Payment Verification

ERCs
, ,
1

Inspired by ERC-8004, this proposal introduces a standard for pre-execution zero-knowledge verification of agent-mediated payments. Users sign off on an agent’s batch of transactions, and agents must submit a zero-knowledge proof that their transactions match the user’s signed intent. Only after the zero-knowledge proof is verified can any funds be transferred.

PR: https://github.com/ethereum/ERCs/pull/1520

Open Questions for Discussion

We have some opening questions that we welcome feedbacks and different angles on:

  • Proof verification gas costs: We recommend Groth16, and verification costs ~200-500k gas. Is this acceptable for the security guarantees provided, or should we explore batched verification approaches?
  • Cross-chain intent bundles: Agents will be paying each other across different chains. The current spec includes chainId per action but doesn’t fully address bridge interactions or multi-chain execution atomicity.
  • Extension to non-payment actions: What’s the right path for extending beyond ERC-20 transfers to swaps, staking, and arbitrary contract calls? That would be great to implement for affordable customization of agent behavior.
  • Compatibility to the Frame Transaction: We’ve noticed the newest core EIP-8141 on the frame transaction, which shall allow us to use a protocol-native VERIFY Frame for the zk proof.

We acknowledge in advance for the technical feedback and contributions from Parth Gargava (Fidelity Lab), Max Resnick (Anza), Alan Du (Microsoft), Luciana Silva (Nethermind), Scott Shi (Kite AI), Tomasz Stanczak (EF), Victor Zhou (NameFi), Kun Peng (Stanford), Zakie Twaine (BNY Mellon), Brian Seong (Polygon Miden)

3 Likes
2

@fulldecent Hey William, please feel free to make any comment here!

1 Like
3

Please correct the syntax errors in your PR so that you can get a published draft URL

1 Like
4

All checks passed! The published draft should come out in a moment

6

Hey @vincentcaptain, really interesting proposal. I’ve been working on ZK privacy for DeFi (built a ZK privacy DEX on Uniswap V4 hooks using Groth16) so a few thoughts on the open questions:

On proof verification gas costs (200-500k):
For individual transactions this is steep, but for agent-mediated batches it’s actually reasonable — you’re amortizing the cost across multiple actions. That said, I’d suggest exploring recursive proof composition (e.g. Nova/SuperNova) for large batches. You get one constant-cost verification regardless of batch size. Groth16 is the right call for v1 though — battle-tested and well-supported.

On cross-chain intent bundles:
This is the hardest problem here. Atomic cross-chain execution without a trusted bridge is still an open research area. A pragmatic approach: define a IntentBundle struct that includes per-chain proofs with a shared nullifier/nonce, and let each chain verify independently. Not truly atomic, but gives you fraud detection if an agent executes partially. Full atomicity probably needs something like shared sequencing or EIP-8141 frames across chains.

On extension to non-payment actions:
I’d suggest an ActionType enum in the intent schema — start with TRANSFER, APPROVE, SWAP, and make it extensible. The ZK circuit just needs to verify that the encoded calldata matches what the user signed. For arbitrary contract calls, you’d need the user to sign the full calldata hash, not just amounts/recipients.

Would love to contribute to the spec and reference implementation. Happy to help with the ZK circuit design specifically — I have experience with Groth16 circuits for privacy-preserving DeFi transactions.

7

Hi @zexoverz, thanks for the feedback. Just to reply to some of your thoughts:

That said, I’d suggest exploring recursive proof composition (e.g. Nova/SuperNova) for large batches.

Yes, this is something we considered, but we left it out of the spec because for our use case, most intent bundles will probably be small enough that the overhead introduced by Nova isn’t worth it. But for large bundles (especially with more complex actions) it might be a good idea.

A pragmatic approach: define a IntentBundle struct that includes per-chain proofs with a shared nullifier/nonce, and let each chain verify independently.

Good point. As you mentioned, full cross-chain atomicity is really difficult and that’s why we didn’t take a pass at it. But the shared nonce and cross-chain verification is sufficient and that’s exactly what we had in mind.

I’d suggest an ActionType enum in the intent schema — start with TRANSFER, APPROVE, SWAP, and make it extensible.

We are actually working on implementing this right now! The original use case for this proposal was just agentic payment, but we’re hoping to extend it to more complex actions like swapping (as you mentioned) and also interactions with lending protocols. Keep an eye out for our changes!

1 Like
8

Awesome, glad the ActionType extension is already in the works — that’s the right direction.

Will definitely be following the updates. Happy to review or test when you have a draft :raising_hands:

9

I’m currently building an AI agent system that relies heavily on intent-based execution, so this proposal is particularly interesting. Combining user-signed intents with zero-knowledge verification of agent behavior seems like a promising direction for making autonomous agents economically accountable.

A few thoughts and questions from the perspective of intent infrastructure:

1. Intent abstraction vs. calldata verification

The current design appears to verify that the executed transaction matches the user-signed intent. In many intent-based systems, however, the user typically signs a high-level constraint rather than a specific transaction structure. For example:

  • “Swap up to X tokens for Y with ≤ Z slippage”

  • “Execute arbitrage if profit ≥ P”

  • “Route through any protocol”

In such cases, the agent may legitimately produce many different calldata patterns that all satisfy the same intent.

Would the ZK circuit verify constraint satisfaction rather than strict calldata matching?
If so, the specification might benefit from clearly separating:

  • Intent constraints

  • Execution witness

This distinction could make the standard more compatible with solver-style architectures.

2. Multi-step execution and solver networks

In solver networks or agent marketplaces, a single intent may be fulfilled through multiple steps:

  • DEX swap

  • bridge

  • secondary swap

  • staking or settlement

Instead of verifying a single transaction, it may be useful to verify that a sequence of actions satisfies the original intent constraints.

This raises a question:
Should the standard explicitly support a batched execution proof, where the agent proves that the entire execution graph satisfies the intent?

That approach might align well with recursive proving strategies mentioned earlier.

Overall, I think the proposal addresses a critical gap for agent-driven execution. ZK-verified intent fulfillment could become an important primitive for autonomous DeFi systems.

Happy to contribute further if the discussion moves toward reference circuits or execution models.