-
Notifications
You must be signed in to change notification settings - Fork 43
Trust‐and‐ERC‐8004
In human-driven payments, trust is established through identity verification (KYC) and institutional reputation. In agentic payments, an autonomous agent initiates transactions without human intervention — and the counterparty may be another autonomous agent.
The fundamental question shifts from "is this person who they say they are?" to "does this agent's behavior pattern warrant automatic transaction approval?"
OmniClaw integrates ERC-8004 trust evaluation into the payment flow so that every pay() call carries a trust assessment — not bolted on after the fact, but evaluated before funds move.
ERC-8004 is an Ethereum standard (live on mainnet since January 2026) that provides on-chain identity, reputation, and trust registries for autonomous agents. It consists of three core registries:
Minimal on-chain identity based on ERC-721. Each agent gets a registered handle that resolves to its registration file — who created it, what operator controls it, and what capabilities it claims.
A standard interface for posting and fetching feedback signals. Operators, other agents, and verifiers can leave structured reputation data — creating a decentralized "credit history" for agents.
Standardizes how agent actions are independently verified on-chain. This addresses a critical question: how do you know an agent actually did what it claims to have done?
OmniClaw's trust evaluation maps to a structured assessment framework — similar to how AML investigations follow a multi-section analysis from identity through to recommendation:
| Assessment Layer | What It Evaluates | Signals Used |
|---|---|---|
| Agent Identity | Is this agent registered? Who created it? | ERC-8004 Identity Registry, operator endorsement, registration age |
| Behavioral Patterns | Does this agent behave normally? | Transaction frequency, amount distribution, time patterns, consistency |
| On-Chain Footprint | Where has this agent been? | Cross-chain paths, funding sources, interaction graph, mixer/sanction exposure |
| Reputation Signals | What do others say about this agent? | ERC-8004 Reputation Registry feedback, operator ratings, peer endorsements |
| Risk Aggregation | What's the composite trust score? | Weighted combination of all signals into a continuous score |
| Trust Decision | Should this transaction proceed? | Auto-approve / hold for review / block — based on score vs. operator thresholds |
Trust scores are continuous, not binary. An agent isn't simply "trusted" or "untrusted" — it exists on a spectrum, just like a credit score. This matters because:
- An agent with a score of 0.85 might be auto-approved for transactions under 100ドル but held for review above 1,000ドル
- The same agent's score changes over time based on new behavioral data
- Different operators can set different threshold policies for the same trust score
- Gray zone decisions — where the score falls between clear-approve and clear-block — are where the real compliance judgment happens
- Account age + activity ratio: New addresses with large-volume transactions are higher risk (same pattern banks use for new customer monitoring)
- Interaction graph analysis: Connections to known high-risk addresses (mixers, sanctioned wallets, flagged entities) reduce trust scores
- Behavioral consistency: Sudden pattern changes — from small steady transactions to large bursts — trigger anomaly flags
- Operator endorsement depth: Agents backed by well-established operators with strong track records score higher
- Cross-chain path complexity: Funds that traverse multiple chains through multiple hops before arriving carry higher risk — complexity often signals obfuscation
The hardest trust problems aren't the obvious bad actors. They're the gray zone — technically legal but economically harmful patterns:
- Sybil attacks: Multiple agent identities controlled by the same entity, designed to circumvent per-agent limits. Signals: synchronized timing, shared funding source, identical behavioral fingerprints
- Airdrop farming: Agents gaming incentive structures through high-volume low-value interactions. Signals: minimum-viable-activity patterns, identical transaction templates across addresses
- Wash trading patterns: Circular transactions between related agents to inflate volume or reputation scores. Signals: closed-loop fund flows, timing correlation, amount matching
OmniClaw occupies a unique position in the audit landscape — it's neither a CEX nor a DEX, but agentic payment infrastructure that requires elements of both audit approaches plus a novel third dimension:
| Dimension | CEX | DEX | OmniClaw (Agentic) |
|---|---|---|---|
| Core audit | Proof of Reserves — assets >= liabilities | Smart contract code audit — no vulnerabilities | Both + authorization chain audit |
| Who audits | Traditional auditors (Big 4, PoR specialists) | Security firms (Hacken, CertiK, Trail of Bits) | Hybrid: code audit + compliance audit |
| KYC model | Mandatory user KYC | Typically none (self-custody) | Operator-level KYC + ERC-8004 agent identity |
| What they prove | "We have the money" | "The code is safe" | "Every transaction has a provable authorization chain" |
| Transaction monitoring | Traditional AML systems | On-chain transparency (inherently auditable) | Policy engine + trust scoring + audit logs |
| Verification model | Periodic (monthly/quarterly) | Pre-deployment + continuous bug bounty | Real-time per-transaction + periodic review |
What makes agentic payment audit unique is the need to prove authorization traceability — not just that funds are sufficient (CEX) or that code is secure (DEX), but that:
- Every transaction was initiated by a registered agent with a verifiable identity
- That agent was operating under an explicit operator policy
- The policy was evaluated and satisfied before execution
- The trust score was computed and fell within acceptable thresholds
- The complete chain — from instruction to settlement — is reconstructible
This is the layer that traditional finance compliance understands but crypto infrastructure hasn't yet built. OmniClaw's trust layer and audit architecture are designed to close this gap.
Agent calls pay()
|
v
[ERC-8004 Identity Check] --> Is this agent registered? What's its history?
|
v
[Trust Score Computation] --> Aggregate behavioral, on-chain, and reputation signals
|
v
[Policy Engine] --> Does the score meet the operator's threshold for this transaction?
|
v
[simulate()] --> Pre-execution check: will this transaction succeed?
|
v
[Execute or Hold] --> Auto-approve, hold for review, or block
|
v
[Audit Log] --> Record full authorization chain for compliance
- Compliance Design — regulatory alignment, CLARITY Act, ERC-3643 vs X402
- Architecture — system design overview
-
API Reference —
pay(),simulate(), and trust evaluation methods - ERC-8004 specification — the Ethereum standard