Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Trust‐and‐ERC‐8004

Clo edited this page Mar 30, 2026 · 1 revision

Trust Layer & ERC-8004

Why Agentic Payments Need a Trust Layer

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: The On-Chain Trust Standard

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:

1. Identity Registry

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.

2. Reputation Registry

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.

3. Validation Registry

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?

Trust Evaluation Framework

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

Why Continuous Scoring Matters

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

Key On-Chain Signals for Trust Evaluation

High-Signal Indicators

  • 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

Adversarial Behavior Detection

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

Audit Requirements: CEX vs DEX vs Agentic

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

The Third Column: Authorization Chain Audit

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:

  1. Every transaction was initiated by a registered agent with a verifiable identity
  2. That agent was operating under an explicit operator policy
  3. The policy was evaluated and satisfied before execution
  4. The trust score was computed and fell within acceptable thresholds
  5. 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.

Integration with OmniClaw Payment Flow

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

Further Reading

Clone this wiki locally

AltStyle によって変換されたページ (->オリジナル) /