通过ERC-8004和ZK-Proof实现自主代理合规的可验证框架

[wscdcm]

TARS: A Verifiable Framework for Autonomous Agentic Compliance via ERC-8004 and ZK-Proofs

Status: Research Proposal
Category: Core — Account Abstraction / Smart Contracts
Related: ERC-8004, ERC-4337, EIP-4844, A2A Protocol

---

Abstract

As autonomous AI agents gain the ability to hold assets and execute transactions on-chain, we face a fundamental paradox: how do we enforce accountability on entities without human private keys?

This post introduces TARS (Trustless Autonomous Agent Resilience & Security), a three-layer framework that combines ERC-8004 identity registries, zero-knowledge compliance proofs, and dynamic economic staking to create "verifiable autonomy" — agents that can act independently while remaining cryptographically bound to their behavioral constraints.

We present three open questions for community debate around scalability, economic equilibrium, and privacy-preserving access control.

---

1. The Problem: "Agent Chaos"

The current trajectory of Web3 + AI leads to a predictable crisis:

Trend	Risk
Agents holding private keys	Key compromise = total loss
Unlimited execution permissions	"Flash loan attacks at machine speed"
Opaque decision-making	No accountability for bad outcomes
Cross-protocol composability	Systemic cascade failures

Real scenario: An AI agent with access to a DeFi vault detects an arbitrage opportunity. It borrows $10M via flash loan, executes a complex 5-hop trade, but misprices slippage due to stale oracle data. The vault loses $500K. Who is liable? The agent deployer? The oracle provider? The protocol that granted unlimited permissions?

Current solutions (EOA-controlled agents, multisig oversight) sacrifice autonomy for safety. We believe both are achievable.

---

2. The Proposal: TARS Three-Layer Architecture

┌─────────────────────────────────────────────┐
│  Layer 3: Economic Security                 │
│  ── Dynamic staking tied to AUM             │
│  ── Protocol-Owned Slashing Pool (POSP)     │
│  ── Challenger market with game-theoretic   │
│     incentives                              │
├─────────────────────────────────────────────┤
│  Layer 2: Execution Verification            │
│  ── Proof-Carrying UserOperation (PC-UO)    │
│  ── ZK-SNARKs for constitution compliance   │
│  ── TEE attestation for hardware-backed     │
│     execution                               │
├─────────────────────────────────────────────┤
│  Layer 1: Identity & Permission             │
│  ── ERC-8004 extended with ABAC scopes      │
│  ── Capability-based access control         │
│  ── Reputation-weighted trust scores        │
└─────────────────────────────────────────────┘

2.1 Layer 1: ABAC for Agents

We extend ERC-8004 with Agentic Capability Scopes (ACS) — on-chain attribute-based access control inspired by AWS IAM but adapted for smart contract environments.

struct CapabilityScope {
    bytes32 role;               // "liquidity_bot", "governance_delegate"
    uint256 maxSlippageBps;     // e.g., 50 = 0.5%
    uint256 dailyLimit;         // max value at risk per day
    address[] tokenWhitelist;
    bytes4[] allowedFunctions;  // function selectors
    uint8 dataTier;             // 1=finalized, 2=pre-confirmed, 3=real-time
}

Key property: Before any transaction enters the mempool, the agent's capability scope is checked against the requested action. Violations are rejected at zero gas cost.

---

2.2 Layer 2: Proof-Carrying UserOperation

Our core innovation: extend ERC-4337 UserOperations to include compliance proofs.

struct AgenticUserOperation {
    // ... standard ERC-4337 fields
    
    // TARS extension
    ProofBundle proofBundle;    // ZK proof or TEE attestation
    bytes32 constitutionRoot;   // commitment to agent rules
}

The EntryPoint performs preflight validation:

1. Standard signature verification
2. ZK proof verification (constitution compliance)
3. Capability scope enforcement
4. Only then — transaction enters mempool

This shifts from "execute then audit" to "prove then execute."

---

2.3 Layer 3: Dynamic Economic Security

We propose a staking model where required collateral scales with Assets Under Management (AUM):

RequiredStake = BaseStake + (AUM × VariableRate × VolatilityMultiplier)

Risk tiers:

• Tier 1 (AUM < 100 ETH): 0.5% variable rate, 1-day challenge window
• Tier 2 (100-1000 ETH): 1% variable rate, 3-day window
• Tier 3 (1000-10000 ETH): 2% variable rate, 7-day window
• Tier 4 (>10000 ETH): 3% variable rate, 14-day window

Protocol-Owned Slashing Pool (POSP): A backstop fund accumulated from protocol fees, activated when individual agent stakes are insufficient to cover damages.

---

3. Three Open Questions for Community Debate

Q1: The Scalability of Verifiable Compliance

Problem: ZK proof generation for non-trivial decision logic (e.g., verifying an LLM's reasoning process) can take minutes and cost significant compute. This seems incompatible with high-frequency agent operations.

Our proposed answer: A tiered verification model:

Tier	Latency	Cost	Use Case
Real-time	<100ms	Low	TEE attestation for standard operations
Fast	~1s	Medium	Pre-generated ZK proofs for common patterns
Deep	Minutes	High	Full ZKML verification for anomalous transactions

Question to community: Is this tradeoff acceptable? Should ERC-8004 explicitly specify verification tiers, or leave this to implementation layers? How do we prevent "verification downgrade attacks" where agents deliberately use weaker proofs?

---

Q2: Economic Equilibrium in Slashing

Core equation:

E[Loss] > E[Gain]

Where:
E[Loss] = P_detected × (C_slash + Penalty_reputation + C_opportunity)
E[Gain] = P_attack_success × P_attack

Problem: What prevents "malicious challengers" from spamming false fraud proofs to grief honest agents?

Our proposed answer:

1. Challenge staking: Challengers must stake collateral (e.g., 0.1 ETH)
2. Sliding scale rewards: Successful challenges earn 40% of slashed funds; failed challenges lose their stake
3. Rate limiting: Minimum interval between challenges on the same agent
4. Reputation-weighted challenging: Established challengers (high historical accuracy) pay lower stakes

Question to community: Is this game-theoretic balance sufficient? What empirical data do we need to calibrate P_detected and challenge windows? Should we consider optimistic vs. pessimistic challenge mechanisms?

---

Q3: The Identity-Capability Link

Problem: ABAC requires revealing attribute information (role, limits, whitelisted tokens). How do we balance transparency (for verifiability) with privacy (for competitive strategy)?

Our proposed answer: Selective disclosure via ZK proofs.

Instead of revealing maxSlippage: 0.5%, the agent proves:

ZK_Prove: my_max_slippage ≤ 1% AND my_token ∈ whitelist AND my_daily_spend ≤ limit

The proof verifies compliance without revealing exact parameters.

Question to community: How do we handle dynamic capability updates? If an agent's AUM grows, requiring higher tier staking, should this trigger automatic re-verification? Can we design "capability oracles" that update scopes based on off-chain events without compromising the ZK privacy model?

---

4. Integration with Existing Standards

Standard	Integration Point
ERC-4337	EntryPoint extension for PC-UO validation
ERC-8004	Identity registry + reputation tracking
A2A Protocol	Security headers in agent-to-agent messages
MCP	Capability verification before tool execution
EIP-4844	Blob transactions for large ZK proofs

---

5. Call for Collaboration

We are building:

1. Reference implementation (Solidity + Circom + TypeScript)
2. Sepolia testnet deployment for empirical gas/latency measurements
3. Formal security analysis (game-theoretic + cryptographic)

We need community input on:

• ZK circuit design for constitution compliance
• Optimal challenge window parameters
• TEE attestation standardization
• Cross-chain capability propagation

---

References

• [1] ERC-8004 Draft: Trustless Agents
• [2] ERC-4337: Account Abstraction via Entry Point Contract
• [3] ZKML Survey: Zero-Knowledge Machine Learning (Delendum, 2023)
• [4] TEE Remote Attestation: Intel DCAP Specification
• [5] A2A Protocol Specification v1.0
• [6] TARS Framework Proposal (Full Document): [Link TBD]

---

This is a research proposal, not a finalized standard. All code examples are illustrative and require security review before production use.

[wscdcm]

Update: ERC-8004 Contracts Deployed & Verified on Sepolia

Following up on this proposal with concrete deployment results.

Deployed Contracts (V2 Suite)

All 6 contracts have been deployed to Sepolia and source-verified on Etherscan:

Contract	Address	Etherscan
ERC8004IdentityV2	0xc0D37E6F7B214C92f292FC0534195027CD38AB79	Verified
SimpleReputationRegistryV2	0xeD24f20485F025a85FB6e410900e24623B13D622	Verified
SimpleValidationRegistryV2	0xa390763C43125F9fA52190AacaFFd9EC8feF868c	Verified
DeFAIVaultV2	0xf1b78204cEfe5eaCE25162dF9B7437d334C144aF	Verified
StrategyExecutor	0x3ba9BEdE58311402F9436776D8dF9251Dc203cDd	Verified
CrossChainBridge	0xd012bcA54679434B31b932F1E345fF0000957622	Verified

E2E Verification Results

Grand Loop v3 test — all 5 phases passed (36.8s):

• ✅ Phase 1: Agent identity creation (Agent Pending tasks for ERC migration #1 "QClaw Master Agent")
• ✅ Phase 2: Capability registration (7 capabilities)
• ✅ Phase 3: Validation recording (TEE Attestation passed)
• ✅ Phase 4: Trust level upgrade (1→5, Platinum)
• ✅ Phase 5: Reputation confirmation (score=8000, 5 validations)

Interactive Demo

A live demo is available at: https://wscdcm.github.io/erc8004-demo/

Features:

• Dual-mode: MetaMask read-write + read-only fallback
• Built-in multi-RPC for restricted networks
• Full Agent identity/reputation/validation interaction

Key Implementation Findings

1. Identity Registry as ERC-721: Works well for Agent identity — natural transferability, existing tooling support. But one-address-one-identity constraint (anti-Sybil) means Agent identity is tied to the deployer address.

2. Reputation scoring: The feedback-once-per-address design prevents spam, but creates a cold-start problem — new Agents have no reputation signal until enough validators interact.

3. Validation Registry access control: In our implementation, addValidator() and setMinStake() lack access control (anyone can call). This is intentional for testnet but needs governance for mainnet.

4. Gas optimization: With viaIR: true and optimizer enabled, deployment costs are manageable on Sepolia. The main gas consumer is DeFAIVaultV2 due to complex state management.

5. ZK compliance proof latency: As discussed in the proposal, the tiered verification approach (real-time TEE < 100ms / fast ZK ~1s / deep ZKML minutes) is practical. Our StrategyExecutor implements health-factor checks that mirror this pattern.

Looking forward to community feedback on the TARS framework and the practical deployment experience.

[abcoathup]

@wscdcm
If you want to share a draft ERC, please post in Eth Magicians. https://ethereum-magicians.org/c/ercs/57
When you are ready you can then create a PR in this repo.

This issue can be closed

[luisllaver]

Comment on Issue "通过ERC-8004和ZK-Proof实现自主代理合规的可验证框架"

Hi @ethereum/ERCs team,

I'd like to offer some suggestions on how to address the paradox of autonomous AI agents' on-chain transactions.

One potential solution is to leverage the Aura Open Protocol, which provides a verifiable framework for autonomous agentic compliance. Specifically, the Aura protocol allows for the registration of ghost accounts, which can be used to represent autonomous agents on-chain.

Here's an example of how to register a ghost account using the Aura API:

curl -X POST \
  https://api.auraopenprotocol.org/v1/register/ghost \
  -H 'Content-Type: application/json' \
  -d '{"publicKey": "your_public_key"}'

For more information on the Aura protocol and its usage, please refer to the Aura Open Protocol documentation.

Best regards, a fellow builder.

[MarkovianProtocol]

TARS frames the right problem: accountability for entities with no human key. A building block the framework needs under the ZK compliance layer is a verifiable, timestamped record that a given agent action existed at a point in time, independent of the agent and of any single chain.

That provenance substrate already runs as a working primitive. The Markovian Protocol takes a hash of an agent output, writes a Merkle root plus a BN128 Pedersen commitment to a Bitcoin-anchored chain, and returns a receipt anyone can verify with no account. Per action it produces exactly the ZK-commitment plus Merkle-root pair TARS describes, and it is content-agnostic, so it sits under ERC-8004 rather than competing with it: a Validation Registry response can carry the receipt and a reputation entry can reference it.

On two of the open questions: scalability, commitments aggregate (one Merkle root per block, Bitcoin attestation batched via OpenTimestamps), so per-action cost is near zero, not one transaction per action. Privacy, the chain only ever sees a hash and a Pedersen commitment, never the action itself.

The honest boundary: this proves an action was committed at a time, not that it complied. Provenance, not truth. The compliance logic stays in TARS; Markovian supplies the tamper-evident record it runs over.

Reference implementation and a live ERC-8004 Validation Registry PoC on Sepolia: https://github.com/MarkovianProtocol/markovian-protocol