ERC-8004 Alignment

How zkde.fi maps to the ERC-8004 agent trust framework — identity, reputation, and validation registries implemented as Starknet-native Cairo contracts.

The mapping

ERC-8004 defines three core registries for autonomous agent systems. zkde.fi implements all three on Starknet Sepolia with ZK-native extensions:

ERC-8004 Component	zkde.fi Contract	What we added beyond the spec
Identity Registry (ERC-721)	AgentIdentity (SRC-721)	Poseidon identity commitment for sybil resistance, ZK circuit skill binding, LLM provider hash
Reputation Registry	ReputationRegistry	Proof-backed scoring (not attestation-only), tiered access with collateral staking, daily rate limits
Validation Registry	ValidationProofRegistry	Multi-lane proof support (groth16/stark/risc_zero), agent-scoped proof history, authorized verifier whitelist

Identity: AgentIdentity

Contract: 0x7847f732db68d030526fdc9e461cfe4a0857d25303dc6635cf661206d0f06e8 (Starknet Sepolia)

An SRC-721 NFT contract — each agent gets a unique token representing its identity. The metadata struct carries everything the system needs to evaluate the agent:

AgentMetadata {
  owner:                ContractAddress
  name:                 felt252
  identity_commitment:  felt252  ← Poseidon hash of cross-chain addresses
  reputation_tier:      u8       ← 0=Strict, 1=Standard, 2=Express
  model_count:          u8
  skill_count:          u8       ← bound ZK circuit skills
  llm_provider_hash:    felt252  ← hash of LLM config (0 = none)
  active:               bool
  total_executions:     u64
}

Why the identity commitment matters: ERC-8004 uses standard ERC-721 for identity. We extend this with a Poseidon hash over the agent operator's cross-chain addresses (Starknet + Ethereum). This makes the identity commitment sybil-resistant — you can't create duplicate identities across chains without detection, because the commitment links them.

Key functions:

Function	ERC-8004 role
mint_agent(name, identity_commitment, model_ids)	Register new agent identity linked to operator wallet
get_agent_metadata(token_id)	Query agent identity, reputation tier, skill count
record_execution(token_id)	Update execution counter (called after every agent action)
get_agents_by_owner(owner)	Discovery — find all agents for a given operator
get_agent_by_commitment(commitment)	Cross-chain identity lookup via Poseidon commitment

Source: contracts/src/agent_identity.cairo

Reputation: ReputationRegistry

Contract: 0x10d00b33b5683afd776c58638a222aa10605d7eeafa95979b5246312b7e022 (Starknet Sepolia)

ERC-8004 specifies a reputation registry for discoverable agent scoring. Our implementation goes further — reputation isn't just attestation, it's proof-backed and has real economic consequences:

Three tiers with enforced constraints:

Tier	Deposits/day	Withdrawals/day	Max position	Relayer delay	Fee
Strict (0)	2	1	10 ETH	none	0.5%
Standard (1)	10	5	50 ETH	1 hour	0.3%
Express (2)	255	255	unlimited	1 second	0.1%

Discoverable scoring (ERC-8004 alignment):

Function	What it does
get_reputation_score(user)	Composite score: tenure + txns + collateral + proof count
get_top_users(limit)	Leaderboard — highest reputation scores
get_user_rank(user)	Your rank in the global registry
get_users_by_tier(tier)	All users at a given tier
get_total_users()	Total registered users

What we added beyond ERC-8004:

• Collateral staking for tier 2 (Standard) — stake_collateral(), slash_collateral()
• Daily rate limiting enforced at contract level
• Proof-gated tier upgrades — request_tier_upgrade(upgrade_proof) requires a valid ZK proof
• Collaborative credit graph (v6) — set_collaborative_score() for cross-agent reputation

Source: contracts/src/reputation_registry.cairo

Validation: ValidationProofRegistry

Contract: 0x20ea9a32eae3fe6fe5137ca9f576383f8723913e1619f17120cf1aeb7e06305 (Starknet Sepolia)

ERC-8004's validation registry stores proof attestations. Our implementation supports multiple proof systems natively:

Proof record structure:

ProofRecord {
  agent_id:         felt252
  fact_hash:        felt252
  proof_type:       felt252  ← 'groth16', 'risc_zero', 'stark'
  action_type:      felt252  ← 'deposit', 'withdraw', 'rebalance', 'init'
  verifier_address: ContractAddress
  verified_at:      u64
  submitter:        ContractAddress
  is_valid:         bool
}

Discovery functions (ERC-8004 alignment):

Function	What it does
get_agent_proofs(agent_id)	All proof IDs for a specific agent
get_agent_proof_count(agent_id)	Total proofs submitted by agent
get_proofs_by_type(proof_type)	Filter by proof system (groth16, stark, etc)
get_recent_proofs(limit)	Latest N proofs across all agents
get_total_proofs()	Global proof count

What we added beyond ERC-8004:

• Multi-lane proof support (Groth16 via Garaga, STARK via Stone, RISC Zero, Halo2/KZG)
• Agent-scoped proof history — every proof is linked to an agent identity
• Authorized verifier whitelist — only registered verifier contracts can submit proofs
• Batch proof registration — register_proofs_batch() for efficiency
• Proof invalidation — invalidate_proof() for contested proofs

Source: contracts/src/validation_proof_registry.cairo

The agent loop

ERC-8004 requires "autonomous agent architecture with planning → execution → verification → decision loop." Here's ours:

flowchart TD
  A["<b>1. Planning</b><br/>AgentRebalancer.analyze_portfolio()<br/>Scan positions, compute drift"] --> B["<b>2. Inference</b><br/>LocalOrchestrator.execute_agent()<br/>22 zkML processors in parallel"]
  B --> C["<b>3. Verification</b><br/>Dual-lane: Garaga Groth16 +<br/>Stone STARK"]
  C --> D{"<b>4. Decision</b><br/>AND/OR logic across<br/>processor results"}
  D -->|Pass| E["<b>5. Execution</b><br/>AgentOrchestrator.submit_execution()<br/>Via AllocationRouter → Adapter"]
  D -->|Fail| F["Reject — no execution"]
  E --> G["<b>6. Receipt</b><br/>ReceiptRegistry (mainnet)<br/>ValidationProofRegistry (Sepolia)"]
  G --> H["ReputationRegistry<br/>trust state update"]

22 zkML processors run in parallel during inference:

risk_scoring, anomaly_detection, correlation_risk, twap_position, safety_diversification, credit_scoring, yield_forecast, impermanent_loss, yield_optimality, slippage_bound, solvency_proof, risk_passport, trader_performance, strategy_integrity, execution_integrity, mev_resistance, arb_check, liquidation_check, reputation_check, performance_attestation, il_predictor

Each processor returns {passed, score, threshold, proof_calldata, public_signals}. The decision stage applies AND/OR logic. If an LLM provider is configured, it reviews processor outputs and decides: execute, hold, or rebalance.

Supporting contracts

Beyond the three ERC-8004 registries, the agent system includes:

Contract	Address	Role
TieredAgentController	0x1c3e...1107	Gates agent execution by reputation tier
AgentSkillRegistry	0x6a03...ddda	Maps ZK circuit skills to agent capabilities
AgentPerformanceStore	0x67f1...c450	On-chain agent performance metrics
BatchVerifier	0x285f...b869	Batch proof verification
VaultController (v3)	0x2f29...b63	Proof-gated vault management

DevSpot manifests

• Agent manifest: devspot/agent.json — full agent definition, registry addresses, architecture description
• Agent log: devspot/agent_log.json — deployment events, adapter registration txs, loop description

Network note

All ERC-8004 registry contracts are on Starknet Sepolia. The mainnet deployment (ReceiptRegistry, ReceiptOS Archive, SelectiveDisclosure) handles receipt attestation and selective disclosure. The ERC-8004 agent system is the infrastructure being brought to mainnet as demand grows. See Contracts for the full address registry.