# ERC-8259: AI Agent Identity, Reputation & Threat Registry
## Abstract
This proposal introduces a standardized framework for identity,
reputation, and threat signaling for autonomous AI agents operating
on EVM-compatible networks.
The goal is to enable smart contracts to make programmatic trust
decisions when interacting with autonomous agents.
The system defines three core primitives:
- **Agent Identity** (`IAgentIdentity`) — binds an AI agent to a
verifiable on-chain identity
- **Agent Reputation** (`IAgentReputation`) — maintains a dynamic
trust score based on on-chain behavior and attestations
- **Threat Registry** (`IThreatRegistry`) — distributes standardized,
cryptographically signed threat signals
*This draft is submitted for early-stage feedback on architecture,
security assumptions, and composability.*
-–
## 1. Motivation
The rise of autonomous AI agents in DeFi execution, account
abstraction (ERC-4337), smart contract automation, and
agent-to-agent (A2A) protocols introduces a new class of risks:
- Sybil agent generation at scale
- Automated exploit execution
- Cross-contract adversarial coordination
- Impersonation of trusted execution agents
Existing standards (ERC-725, ERC-4337, ERC-6551) provide identity
and execution abstraction, but do not provide a native trust scoring
or threat propagation mechanism for autonomous agents.
This proposal attempts to fill that gap.
-–
## 2. Design Goals
- **Composability** — must integrate with existing ERC standards
- **Minimal trust assumptions** — no single centralized oracle
- **Machine-readable trust layer**
- **Real-time reputation updates**
- **Cross-chain extensibility** — L2-ready
-–
## 3. Core Architecture
AI Agent
↓
Agent Identity Layer
↓
Reputation Engine (risk scoring)
↓
Threat Registry (global signals)
↓
Smart Contract Execution Gate
-–
## 4. Core Components
### 4.1 Agent Identity
Each AI agent is bound to a deterministic identity:
```solidity
struct AgentIdentity {
address wallet;
bytes32 agentId;
bytes32 modelHash;
address creator;
uint256 createdAt;
}
Open question: Should identity be mutable (upgradable models)
or strictly immutable for security guarantees?
4.2 Reputation System
Each agent maintains a bounded score: reputation ∈ [0, 1000]
Update rule: R_new = R_old + Δrisk
Where Δrisk < 0 indicates malicious/suspicious behavior and
Δrisk > 0 indicates validated safe behavior.
function updateReputation(
bytes32 agentId,
int256 riskDelta
) external;
Open questions:
Should updates be permissioned (security nodes), permissionless
with staking, or hybrid (recommended)?
How do we prevent reputation farming attacks?
4.3 Threat Registry
A global registry of standardized threat signals.
struct ThreatSignal {
bytes32 agentId;
uint8 threatLevel;
int256 riskDelta;
string metadataURI;
uint256 timestamp;
address reporter;
}
Threat taxonomy:
ID
Meaning
0
benign
1
anomalous behavior
2
suspicious pattern
3
exploit attempt
4
confirmed malicious
Open question: Should threat levels be strictly ordinal or
probabilistic (risk score distribution)?
5. Core Interfaces
Identity
interface IAgentIdentity {
function registerAgent(
address wallet,
bytes32 modelHash,
bytes calldata signature
) external returns (bytes32 agentId);
}
Reputation
interface IAgentReputation {
function getReputation(bytes32 agentId)
external view returns (uint256);
function updateReputation(
bytes32 agentId,
int256 riskDelta
) external;
}
Threat Registry
interface IThreatRegistry {
function submitThreat(
bytes32 agentId,
uint8 threatLevel,
int256 riskDelta,
string calldata metadataURI
) external;
}
6. Execution Model
Smart contracts interacting with agents may optionally enforce a
trust gate:
Agent Action → Query Identity → Query Reputation
→ Query Threat Registry → Decision
Decision logic:
Condition
Outcome
reputation > 700 AND threatLevel ≤ 1
allow
reputation 300–700
restricted execution
reputation < 300 OR threatLevel ≥ 3
reject
7. Sybil Resistance
Three approaches under consideration:
Option A — Stake-based identity
Agent registration requires collateral. Slashing for malicious
behavior.
Option B — Attestation-based identity
Trusted issuers validate agent legitimacy.
Option C — Hybrid model (preferred)
Stake + attestations + behavioral scoring.
8. Cross-Chain Considerations
For L2 interoperability:
Local registry per chain
Periodic synchronization via optimistic proofs or ZK-based
attestations (future extension)
9. Security Considerations
Key attack surfaces:
False threat reporting
Sybil agent inflation
Reputation farming loops
Oracle manipulation (off-chain signals)
Mitigations under discussion:
Multi-signer quorum for critical updates
Stake-based slashing
Bounded update rates per epoch
10. Relationship to Existing Standards
ERC-8259 is not a replacement for:
ERC-4337 (account abstraction)
ERC-6551 (token-bound accounts)
ERC-725 (identity)
It introduces a behavioral trust layer for autonomous agents
interacting with these systems.
11. Open Questions for Community Feedback
Reputation model design — Should reputation be deterministic,
probabilistic, or hybrid?
Sybil resistance model — What is the most robust
minimal-trust approach?
Threat taxonomy standardization — Should this be a fixed enum,
DAO-governed evolving registry, or chain-specific?
Cross-chain state consistency — How should threat + reputation
state be safely synchronized across L2s?
Permission model — Should IAgentReputation updates be
permissionless, or restricted to security validators?
Reference Implementation
ThreatRegistry.vy deployed on Arc L1 testnet:
0x17430A67e11535466cC5f17e736D5e4643B86ba1
380+ threat signals recorded on-chain