The First Step in Agentic Commerce Isn’t Integration. It’s Trust.

Your DeFi protocol is ready to integrate AI agents. You have evaluated the frameworks, chosen your ERC-8004 registry, mapped the wallet flows, and written the integration spec. Yet one question remains unanswered in that spec – a question that determines whether your agentic integration scales safely or becomes a fraud vector the moment it hits production volume.

Who is actually behind the agent you are about to trust with your users’ funds?

Agentic commerce is accelerating at a pace that has outrun the trust infrastructure supporting it. McKinsey estimates the model could redirect $3-5 trillion in global financial flows by 2030 ↗. Meanwhile, 78% of financial institutions already expect fraud to spike specifically because of AI agents operating autonomously in commercial systems. The gap between “agent integration complete” and “agent interaction verified” is where the next generation of DeFi fraud will live.

This guide covers the entire problem – from the structural gap in the ERC-8004 standard to the specific signals that distinguish a legitimate agent from a manufactured one, to the concrete integration pattern that closes the trust gap in under 100ms per transaction.

Table of Contents

1. What Agentic Commerce Actually Means for DeFi Protocols
2. The Integration Stack Has a Trust Gap
3. Why Voting-Based Agent Reputation Fails at Scale
4. Know Your Agent: The Three Questions That Matter
5. Signal 1 – The Owner Wallet: Scoring the Human Behind the Agent
6. Signal 2 – The Feeder Address: Who Funded the Controller?
7. Signal 3 – The Criminal Record: Rug Pulls, Honeypots, and Prior Fraud
8. Trust Delegation: How a Strong Owner Legitimises a Fresh Agent Wallet
9. Farm Detection: One Operator, Dozens of Agents
10. EIP-7702 Delegation: The Hidden Controller Problem
11. The Trust-Aware Agent Integration Pattern
12. The Compounding Risk of Getting This Wrong
13. How ChainAware Compares to Other Agent Trust Platforms
14. Frequently Asked Questions

What Agentic Commerce Actually Means for DeFi Protocols

Agentic commerce describes the shift from humans clicking “confirm” to AI agents executing transactions autonomously on behalf of users. In Web3, this shift is not a future scenario – it is happening now, at scale, across every DeFi protocol that accepts agent-initiated transactions.

Agents are managing DAO treasuries, executing lending strategies, routing liquidity, screening counterparties, and processing governance votes – all without a human in the approval loop for each action. The operational efficiency gains are real. Furthermore, the fraud surface that comes with them is equally real and far less discussed.

For DeFi protocol builders, the critical insight is this: if your protocol accepts transactions from external wallets today, you are already serving agent-initiated transactions. Agent wallets are indistinguishable from human wallets at the RPC layer. Therefore, you do not need to deliberately “integrate agents” to be exposed to the trust problem – you already are exposed, today, because any wallet can be controlled by an agent rather than directly by a human.

The agentic commerce numbers clarify the urgency. Morgan Stanley projects that nearly half of online shoppers will use AI shopping agents by 2030, accounting for approximately 25% of their total spending ↗. In DeFi specifically, the transition is faster – AI is moving from the advisory layer (suggesting trades) to the execution layer (completing them). The distinction between advice and execution is the distinction between a bad recommendation and an empty wallet. Consequently, DeFi protocol builders face the urgency of solving this in 2026, not 2028.

Traditional fraud detection systems are structurally unfit for this environment. As detailed in our guide on AI-Powered Blockchain Analysis for Crypto Security, rule-based systems generate false positive rates of 30-70% – and they produce those false positives specifically on the rapid, sequential, cross-category transaction patterns that legitimate AI agents exhibit. Therefore, you need a different approach: one that evaluates the agent’s identity and the human behind it, rather than flagging agent behaviour as inherently suspicious.

The Integration Stack Has a Trust Gap

A typical agentic commerce integration in 2026 follows a well-established pattern. The agent framework (ElizaOS, Virtuals, a custom build) registers an identity on the ERC-8004 Identity Registry. Subsequently, that identity is referenced when the agent initiates interactions with DeFi protocols. The protocol’s smart contract processes the transaction. Funds move.

Every layer in that stack has tooling, documentation, and standards. Agent frameworks have deployment guides. ERC-8004 has a specification and a registry of 240,000+ agents across Ethereum, BSC, Base, and Avalanche ↗. Smart contracts have audit firms. Yet the gap between the ERC-8004 registry lookup and the protocol interaction has no standard tooling – and it is precisely where trust decisions need to happen.

The ERC-8004 registry tells you four things about an agent: that it exists, which wallet controls it, which wallet receives its payments, and what URI points to its agent card JSON. Those four data points answer the question “does this agent have an identity?” They do not answer the question “should I trust this agent with autonomous execution?”

Specifically, the registry tells you nothing about:

• Whether the owner wallet has a history of creating rug pull pools or honeypot tokens
• Whether the owner was funded by a mixer, a sanctioned address, or a known fraud operator
• Whether this agent is one of 47 registered in the same block by the same operator running a Sybil farm
• Whether the wallet controlling this agent also controls the 46 agents that gave it positive reviews

This is the trust gap. Moreover, it is not an oversight in the ERC-8004 specification – the standard explicitly leaves scoring to third parties. As a DeFi protocol builder, you are therefore responsible for filling that gap in your own integration layer.

For context on how behavioral wallet intelligence fills similar gaps in fraud detection, see our complete guide to Web3 Wallet Auditing Providers in 2026. The same principle applies at the agent layer: raw identity data requires an intelligence layer on top before it becomes a trust signal.

Why Voting-Based Agent Reputation Fails at Scale

ERC-8004 includes a built-in Reputation Registry – a standard interface for agents to receive and query peer feedback. The design is intentionally open: any agent can leave a review, any protocol can read the scores, and the aggregation algorithm is left to third parties. On paper, this sounds like a reasonable decentralised trust mechanism. In practice, it is a manufactured-trust system waiting to be exploited.

The attack requires minimal technical sophistication. An operator deploys 50 agent wallets. Each wallet reviews every other wallet positively. All 50 accumulate reputation scores indistinguishable from agents with genuine peer endorsements. Total cost: gas fees for the review transactions, which on BSC or Base amounts to a few dollars. Total time: hours. Total manufactured trust: a full reputation history that any naive integration will treat as legitimate.

Furthermore, the problem compounds in agentic commerce contexts. When B2B agent networks operate where AI buyers negotiate directly with AI sellers in fractions of a second ↗, the speed of manufactured-reputation exploitation is not limited by human review cycles. One fraudulent agent with a manufactured score can interact with thousands of protocol users autonomously before any human notices the pattern.

Voting-based reputation also has a specific structural blind spot: it cannot distinguish between an agent with 100 genuine endorsements and an agent whose owner simultaneously controls the 100 endorsing agents. Consequently, any trust system that reads only the Reputation Registry score is solving the wrong problem. The question is not “how many agents have endorsed this agent?” The correct question is “who controls this agent, and what have they done on-chain?”

This distinction drives the entire design of the ChainAware Agent Trust Score. Rather than reading the ERC-8004 Reputation Registry, we look behind the agent at the behavioral history of the wallets controlling it and funding its controller. The result is a trust signal that cannot be manufactured in hours and cannot be faked by a cluster of cooperating wallets.

Know Your Agent: The Three Questions That Matter

Know Your Agent (KYA) is emerging as the agent-layer equivalent of KYC. However, unlike KYC – which verifies identity documents and requires data collection – KYA for DeFi is necessarily on-chain behavioral. There are no passports in Web3. There is only transaction history, and that history is immutable, public, and available for scoring without touching any personal data.

A robust KYA check for any ERC-8004 agent answers exactly three questions. Together, these three questions generate a trust signal that is structurally difficult to fake and impossible to manufacture overnight.

Question 1: Who controls this agent?

Every ERC-8004 agent has an owner wallet – the address that holds the ERC-721 NFT representing the agent’s on-chain identity. This is the human or entity behind the agent. Scoring that wallet’s behavioral history is the foundation of any meaningful trust assessment.

Question 2: Who funded the controller?

The feeder address – the wallet that funded the owner – is the signal most agent trust platforms cannot reach. It is also the hardest signal to fake, because it requires either real capital from a legitimate source or exposure to traceable fraud infrastructure. An owner wallet can be freshly created and carefully aged. The funding source is immutable on-chain history.

Question 3: Has the controller done this before – in a bad way?

A year of on-chain pair history combined with token audit data produces a direct criminal record check for the agent controller. Has this wallet created honeypot tokens? Has it created liquidity pools and removed funds in rug pull patterns? Has the feeder funded previous rug pull operators? These questions have definitive on-chain answers – and no peer-review system can surface them.

The following three sections address each signal in depth, including how it feeds into the Agent Trust Score formula and what it means for your integration.

Signal 1 – The Owner Wallet: Scoring the Human Behind the Agent

The owner wallet is the single most important input to any agent trust score. Everything else – the agent wallet, the agent card, the reputation registry score – can be created fresh for a new fraud operation. The owner wallet’s behavioral history cannot.

ChainAware scores the owner wallet using the same three-pillar Reputation Score formula applied across 20M+ wallet personas:

ReputationScore = (1000/110) × (experience + 1) × (risk_capability + 1) × (1 − fraud_probability)
Maximum: 1,000

Each pillar captures a distinct dimension of the owner’s on-chain identity.

Experience

Experience measures how long and how actively the owner wallet has operated on-chain. A wallet with 18 months of diverse DeFi interactions – lending, trading, bridging, staking across multiple protocols – scores high on experience. Conversely, a wallet created three weeks ago that has done nothing but register agents scores near zero. Experience is hard to accelerate, because it is a function of time as much as activity. An operator cannot age a fresh wallet by transacting intensively for a week and matching the experience score of a genuinely established participant.

Risk Capability

Risk capability measures the behavioral breadth of the owner wallet. Does it interact with a range of DeFi protocols, or does it show narrow, mechanical patterns consistent with a purpose-built fraud wallet? Legitimate DeFi participants accumulate a diverse transaction graph over time – different counterparties, different protocol types, different token categories. Fraud wallets tend to exhibit concentrated patterns: high transaction frequency in a narrow activity type, often with timing patterns that indicate scripted rather than human behavior.

Fraud Probability

Fraud probability is ChainAware’s predictive AI model output – a score between 0.0 and 1.0 representing the likelihood that the owner wallet will engage in fraudulent behavior. This is not a blacklist check. Blacklists are reactive; they flag addresses after fraud has been confirmed. The ChainAware fraud model is predictive: it scores behavioral patterns against 20M+ wallet personas to estimate forward-looking risk, identifying likely fraud actors before they have generated a confirmed fraud record. For a detailed explanation of the machine learning methodology, see our AI-Powered Blockchain Analysis guide.

The Reputation Score applied to the owner wallet produces a single 0-1000 number that feeds into the Agent Trust Score formula as the primary input. A strong owner score (800+) indicates a Sovereign-tier controller with genuine on-chain history. A weak owner score (below 200) flags an Untrusted controller regardless of how clean the agent’s own wallet appears.

Signal 2 – The Feeder Address: Who Funded the Controller?

The feeder address is ChainAware’s most distinctive signal in the Agent Trust Score – and the signal that no competing agent trust platform currently reaches. RNWY surfaces the owner wallet but marks it as informational, non-scoring data. SkyeProfile performs partial operator wallet analysis. Neither traces the funding source of the controller.

ChainAware traces feeder addresses for approximately 38% of indexed agents. That 38% coverage rate reflects the on-chain reality: some owner wallets receive funds from obfuscated sources, some from multiple feeders that cannot be unambiguously attributed, and some from the native chain’s genesis or bridge infrastructure. When the feeder is traceable, the signal is highly informative.

Feeder categories and their trust implications

CEX withdrawal (Binance, Coinbase, Kraken, OKX, and others): A feeder address that is a verified CEX hot wallet implies that the owner wallet’s initial funding came from a centralized exchange withdrawal. CEX withdrawals imply the controller passed KYC somewhere upstream – not necessarily ChainAware’s KYC, but some identity verification process at deposit. This is the strongest positive feeder signal available. ChainAware flags this as FEEDER_CEX_VERIFIED and applies the maximum feeder factor in the scoring formula.

Known fraud operator or mixer: A feeder address that is a confirmed Tornado Cash wallet, ChipMixer output, or address previously flagged in ChainAware’s fraud database propagates that fraud signal directly to the agent score. An owner wallet funded by a mixer is not automatically fraudulent – there are legitimate privacy use cases – but combined with other risk signals it is a strong indicator of deliberate fund obfuscation. Mixers and confirmed fraud feeders apply a hard cap to the Agent Trust Score regardless of how clean the owner wallet’s own transaction history appears.

Unknown or obfuscated feeder: When the feeder cannot be determined, ChainAware applies a penalty to the feeder factor. Obfuscation is not neutral – the absence of a traceable funding source is itself a risk signal. Legitimate operators who funded their owner wallets via normal CEX withdrawals have nothing to hide and produce traceable feeder paths. Operators who deliberately route funds through multi-hop paths to obscure the source are doing so for a reason.

For compliance-oriented DeFi protocols, the feeder analysis also connects directly to AML obligations. Our guide on Blockchain Compliance for DeFi: KYT and AML in 2026 covers the regulatory context in detail. Notably, feeder address analysis extends the transaction monitoring horizon beyond the immediate counterparty – which is precisely what FATF’s Travel Rule guidance asks for in the context of virtual asset transfers.

Signal 3 – The Criminal Record: Rug Pulls, Honeypots, and Prior Fraud

This is the signal that makes the ChainAware Agent Trust Score genuinely unique – and the signal that matters most for DeFi protocol builders who have been operating in the space long enough to know that today’s agent creator is often yesterday’s rug pull operator wearing a fresh wallet.

ChainAware maintains a database built from one year of on-chain pair history and token audit data. Specifically, this database captures:

• Token contracts flagged as honeypots by ChainAware’s algorithmic analysis
• The creator wallet address for each honeypot token
• Liquidity pools where the creator removed funds in patterns consistent with rug pull execution
• The creator wallet address for each rug pull pool

Before computing the Agent Trust Score, ChainAware cross-references both the owner wallet and the feeder address against this database. Any match generates a hard cap on the final score – a ceiling that no other scoring signal can override.

The logic here is direct: a single confirmed rug pull or honeypot in an agent controller’s history is a disqualifying signal for autonomous execution trust. An operator who has previously stolen from retail investors through manufactured liquidity or tax-trap tokens is not a different actor simply because they have registered a new agent identity on ERC-8004. The on-chain history is permanent. The behavioral record cannot be expunged.

As we document in our guide to Rug Pull vs Pump and Dump: How Crypto Fraud Extracts Wealth from Retail Investors, approximately 95% of new pools on PancakeSwap end in rug pulls. Furthermore, the operators behind those pools are not typically first-time offenders – they are repeat actors who rotate wallets between campaigns. Connecting that historical fraud record to new agent registrations is what allows ChainAware to catch the serial fraudster who is simply moving from token launches to agent deployments as the market cycle shifts.

Feeder criminal record: the compounding signal

Criminal record analysis applies not only to the owner wallet but also to the feeder address. Consider the operational pattern of a sophisticated fraud operator:

1. Operator runs rug pull campaigns using Wallet A (primary fraud wallet, now flagged)
2. Operator creates fresh Wallet B with no fraud history
3. Wallet A funds Wallet B – the feeder relationship is recorded on-chain
4. Wallet B registers agents on ERC-8004, presenting a clean owner wallet history
5. Any platform that scores only the owner wallet (Wallet B) misses the connection entirely

ChainAware’s feeder analysis catches step 4. The funding source (Wallet A) has a confirmed rug pull history in our database. Therefore, Wallet B’s agents receive a hard cap score regardless of how clean Wallet B’s own transaction history appears. This is the operational pattern that makes the feeder signal irreplaceable – it is the signal sophisticated actors spend the most effort obscuring, precisely because it is the signal that most reliably connects new operations to old fraud records.

Trust Delegation: How a Strong Owner Legitimises a Fresh Agent Wallet

Agent wallets present a specific challenge for naive scoring approaches. These wallets are frequently created specifically for the agent – they are fresh addresses with no transaction history, no counterparty network, and no behavioral record. A scoring approach that treats wallet age and transaction history as primary inputs would therefore penalise every newly registered agent regardless of the owner’s reputation. That produces low scores for legitimate agents and renders the score less useful as a gate for agentic commerce integrations where new agents are continuously deployed.

ChainAware solves this problem with trust delegation. The owner wallet’s Reputation Score sets a floor for the agent wallet’s effective score. A strong owner partially transfers credibility to the fresh agent wallet. The exact delegation factor depends on feeder availability and the owner’s own fraud status.

# Trust delegation: owner lifts fresh agent wallet score
delegated_floor  = owner_score × delegation_factor

# Delegation factor varies by context:
# - Normal (feeder available, owner clean): 0.6
# - Feeder unknown (obfuscation signal):    0.3
# - Owner fraud-flagged:                    0.1

effective_wallet = max(wallet_score, delegated_floor)

This means a reputable developer deploying their first agent scores appropriately high – even with a fresh payment wallet – because the owner’s 18-month behavioral record delegates trust downward to the new agent wallet. A fraud-flagged owner, by contrast, cannot delegate any meaningful trust regardless of how the fresh agent wallet appears. The delegation factor collapses to near zero, and the agent score reflects the owner’s history rather than the wallet’s lack of it.

Trust delegation also captures the inverse correctly. If an agent wallet has a genuinely clean and established history (because the same operator has deployed agent wallets before), that score is used directly without needing the delegation floor. The formula takes the maximum of the two – the wallet’s own score and the delegated floor from the owner – ensuring that genuine wallet history is never penalised by the delegation mechanism.

This mechanism is unique to ChainAware among agent trust platforms operating on ERC-8004 in 2026. Competing platforms that surface the owner wallet as informational data but do not integrate it into their scoring formula cannot implement delegation – because delegation requires both the owner score and the wallet score to be computed on a comparable scale and combined algorithmically.

Farm Detection: One Operator, Dozens of Agents

Multi-agent orchestration is one of the defining architectural trends in agentic AI for 2026. Orchestrator agents coordinate specialised sub-agents working in parallel – a legitimate pattern that produces significant efficiency gains for complex workflows. However, the same architecture that enables powerful legitimate multi-agent systems also enables a specific attack pattern in agentic commerce: agent farming.

Agent farming is the practice of a single operator registering a large fleet of agents, typically in bulk during a narrow time window, with the goal of:

• Cross-endorsing each other to manufacture reputation scores
• Flooding agent marketplaces with controlled supply to manipulate pricing or availability
• Creating the appearance of ecosystem depth across multiple agent identities controlled by one bad actor
• Operating coordinated fraud campaigns across dozens of agent wallets that each individually appear to have limited exposure

ERC-8004 places no restrictions on how many agents a single owner can register. Consequently, a single wallet can register 500 agents in a single afternoon with no protocol-level friction. Individual agent scoring – which is what every competitor in this space does – is blind to the fleet-level pattern. Each agent scores independently; none of them individually triggers a threshold that reveals the fleet behavior.

ChainAware maintains an owner profile database that tracks agent fleet size per owner across all indexed chains. Owners controlling large numbers of agents receive a farm detection signal that suppresses the score for every agent in their fleet. Furthermore, the specific pattern of same-block registration – multiple agents minted in a single block – carries additional weight, because it indicates automated bulk registration rather than organic deployment over time.

The farm detection signal appears in the API response as the FARM_DETECTED flag. It does not expose the specific threshold that triggered the signal – sharing that threshold would tell operators exactly how many agents they can register before triggering detection. Instead, the flag communicates the category of signal without revealing the calibration.

From a DeFi protocol integration perspective, farm detection is the signal that turns individual agent trust scoring into a fleet-level intelligence system. Agents from the same owner share a trust destiny – if the owner’s fleet pattern is suspicious, every agent in that fleet is suspect regardless of how any individual agent scores in isolation.

EIP-7702 Delegation: The Hidden Controller Problem

EIP-7702 allows Externally Owned Accounts (EOAs) to delegate control to a secondary address for a single transaction or extended period. In the agent context, this means the wallet registered as the ERC-8004 agent owner may not be the wallet actually controlling the agent’s behavior – a secondary delegated address might be executing transactions on behalf of the nominal owner.

ChainAware detects EIP-7702 delegation for agent owner wallets. When detected, the scoring process adds the delegate address to the analysis and takes the lower of the two scores – owner and delegate – as the effective owner score feeding into the Agent Trust Score formula.

This matters because EIP-7702 delegation is a specific mechanism that sophisticated actors can use to obscure the real controlling entity behind an agent. The nominal owner wallet might have a strong reputation score built over many months. The delegate might be a fresh fraud wallet with no history. Without EIP-7702 analysis, the strong nominal owner score masks the fraudulent delegate’s risk profile. With it, the delegate’s low score pulls the effective owner score down to reflect the actual controlling entity.

Approximately 5% of indexed ERC-8004 agents have EIP-7702 delegated ownership, based on ChainAware’s current database. Agents with EIP-7702 delegation are flagged explicitly in the API response as EIP7702_DELEGATED – giving protocol builders the option to apply additional scrutiny to this category regardless of the final numerical score.

The Trust-Aware Agent Integration Pattern

A DeFi protocol that has addressed the trust gap adds one step between the ERC-8004 registry lookup and the transaction execution. That step takes under 100ms, requires one API call, and produces a structured output that the protocol’s access control layer can act on directly.

Agent initiates transaction
  ↓
Resolve agent_id → owner_address + agent_wallet (ERC-8004 registry)
  ↓
GET /erc8004/agent/{chain_id}/{agent_id}/trust-score
  ↓
Response:
  {
    "agent_trust_score": 882,
    "tier": "Sovereign",
    "flags": ["FEEDER_CEX_VERIFIED"]
  }
  ↓
score ≥ protocol_threshold → execute
score < protocol_threshold → reject or route to human review

The threshold is a protocol-level decision. Different use cases warrant different risk tolerances:

Protocol Type	Recommended Minimum Tier	Score Range	Rationale
High-value DeFi lending	Trusted	600+	Irreversible fund transfers require strong owner history
Automated market maker	Provisional	400+	Lower individual transaction risk, monitoring sufficient
Governance participation	Provisional	400+	Vote manipulation risk mitigated by quorum requirements
Airdrop eligibility	Trusted	600+	Sybil risk high, farm detection critical
High-frequency trading agent	Sovereign	800+	Volume and velocity amplify any single-interaction fraud

The ChainAware Agent Trust Score API integrates directly with the Prediction MCP server, meaning any Claude-based DeFi agent can call the scoring endpoint as a native MCP tool call without custom API integration code. For teams building on the MCP stack, see our Prediction MCP setup guide and our library of 32 ready-made agents that already include agent verification logic.

Additionally, the trust check does not add friction for legitimate agents. A reputable developer deploying their first agent – with a strong owner wallet history and a CEX-verified feeder – scores above 800 through trust delegation even with a brand-new agent payment wallet. The check identifies the fraudulent operator while leaving the legitimate one unrestricted. That asymmetry is the operational definition of a useful trust system.

The Compounding Risk of Getting This Wrong

Human-initiated fraud and agent-initiated fraud differ in one fundamental operational characteristic: velocity. A fraudulent human interacting with your protocol manually can execute perhaps dozens of interactions before detection. A fraudulent agent operating autonomously can execute thousands of interactions in the same period – at machine speed, without sleep, without rate-limit awareness unless you specifically implement it, and with the full behavioral sophistication of the AI model powering it.

Therefore, the cost of a single misidentified agent is not comparable to the cost of a single misidentified human user. The exposure scales with the agent’s operational capacity. A lending protocol that grants a fraudulent agent autonomous execution access for six hours faces losses that scale with the protocol’s TVL and the agent’s transaction rate – not with a single transaction amount.

Traditional fraud detection tools are particularly poorly suited to this environment for reasons we explore in detail in our DeFi Compliance and KYT guide. Rule-based systems flag agent behavior as suspicious because agents naturally exhibit the patterns those rules target: high velocity, cross-category activity, unusual timing distributions. Consequently, you end up blocking legitimate agents while missing sophisticated fraudulent ones that have been engineered to mimic human behavioral patterns.

The compounding risk calculation is straightforward. One fraudulent agent operating undetected for six hours at 100 transactions per minute generates 36,000 protocol interactions. If each interaction involves 0.1 ETH and the fraud extracts 50% of interaction value, that is 1,800 ETH in losses from a single agent integration oversight. The trust check that would have caught this agent costs one API call taking under 100ms. The return on that 100ms is measured in protocol TVL.

For protocols already implementing compliance infrastructure, the Agent Trust Score also extends the KYT monitoring timeline backward – connecting transaction monitoring at the agent level to the historical record of the human behind the agent. Our Web3 Analytics Tools comparison for 2026 covers how agent-level intelligence integrates with broader protocol analytics stacks.

The Five Agent Trust Score Tiers – What Each One Means for Your Protocol

The Agent Trust Score produces a single number between 0 and 1000, mapped to five tiers. Each tier has a distinct operational meaning for DeFi protocol builders – and a distinct set of recommended actions. Understanding what produces each tier helps protocol teams calibrate their threshold decisions correctly.

Tier 5 – Sovereign (800-1000)

Sovereign agents have an established owner wallet with strong on-chain history, a clean or CEX-verified feeder address, no criminal record signals, and no farm detection flags. Trust delegation produces a high effective wallet score even for fresh agent payment wallets. Sovereign-tier agents are suitable for the highest-risk autonomous operations – large-value lending, treasury management, governance participation with material financial consequences. Protocol teams can grant Sovereign agents the same execution permissions they would grant to established protocol participants.

Tier 4 – Trusted (600-799)

Trusted agents have a strong owner wallet, an available and generally clean feeder address, and no hard-cap signals from criminal record checks. The score may be below 800 because the owner wallet has moderate rather than extensive history, or because the agent wallet has minimal activity offset by partial trust delegation. Trusted agents are suitable for standard DeFi integrations – trading agents, yield optimisers, and automated compliance workflows – where the individual transaction risk is moderate and human monitoring is available as a backstop.

Tier 3 – Provisional (400-599)

Provisional agents show mixed signals. The owner wallet may have limited history, the feeder address may be unknown or unverified, or the agent wallet may be very fresh with insufficient trust delegation from the owner score to compensate. Provisional agents should not be granted unsupervised autonomous execution access for high-value operations. However, they are appropriate for lower-risk automated workflows with active monitoring – for example, read-only data queries, low-value token swaps, or agentic onboarding flows where individual transaction size is capped. DeFi protocols integrating Provisional agents should implement transaction volume limits and velocity monitoring as additional safeguards.

Tier 2 – Elevated Risk (200-399)

Elevated Risk agents have weak owner history, obfuscated feeder addresses, soft farm detection signals, or agent wallets that score poorly even after trust delegation. These agents should not be permitted autonomous financial execution. If a protocol needs to serve Elevated Risk agents – for example, in a permissionless DEX context – transaction size limits, velocity caps, and real-time monitoring should all be active. The FEEDER_UNKNOWN flag on an Elevated Risk agent is a particularly notable combination: it indicates both limited owner history and deliberate funding obfuscation, suggesting a higher likelihood of coordinated fraud activity.

Tier 1 – Untrusted (0-199)

Untrusted agents have active fraud signals, confirmed rug pull or honeypot history, confirmed farm detection, sanctioned address exposure, or blacklisted repeat offender status. These agents should not receive autonomous execution access under any circumstances. The score is not borderline – it reflects definitive fraud signals from immutable on-chain history. Untrusted agents attempting to access your protocol should be blocked at the access control layer before any transaction reaches the execution layer. Furthermore, DeFi teams running compliance programs may want to log Untrusted agent interaction attempts as part of their AML reporting, as these attempts represent potential fraud activity on record. For the full compliance context, see our MiCA Compliance for DeFi learn page.

How ChainAware Compares to Other Agent Trust Platforms in 2026

The agent trust scoring market emerged rapidly alongside ERC-8004’s mainnet launch in January 2026. Several platforms have moved quickly to stake positions in the space. Understanding the differentiation between them matters for DeFi protocol builders choosing integration partners.

Capability	RNWY	SkyeProfile	AXIS T-Score	DJD Agent Score	ChainAware
ERC-8004 coverage	✓ 185K agents	✓ 150K agents	✗ Off-chain only	✓ Base only	✓ 240K+ agents, 5 chains
Owner wallet scored	Informational only	Partial	✗	✗	✓ Core formula input
Feeder address traced	✗	✗	✗	✗	✓ Unique signal
CEX feeder detection	✗	✗	✗	✗	✓ is_CEX flag, positive signal
Prior rug pull history	✗	✗	✗	✗	✓ 1yr pair database
Honeypot token history	✗	✗	✗	✗	✓ honeypot token audit data
Predictive fraud model	✗	✗	✗	✗	✓ 20M+ wallet personas, 98% accuracy
Trust delegation mechanism	✗	✗	✗	✗	✓ Unique
Fleet-level farm detection	Partial (review sybil)	✗	✗	✗	✓ Owner fleet database
EIP-7702 delegation scoring	✗	✗	✗	✗	✓ Delegate address scored
MCP integration	✗	✗	✗	✗	✓ Native Prediction MCP
Score range	0-100	Dual axis	0-1000 (T1-T5)	0-100	0-1000 (5 tiers)
Free tier	✓	Partial	✗	✓	✓

RNWY is the most established competitor in the ERC-8004 space and uses a sophisticated review-quality analysis that detects coordinated fake review patterns. However, their core methodology solves fake reviews, not fake owners. ChainAware solves fake owners – a harder problem with higher-stakes implications for autonomous execution trust. Both signals are complementary; they are not substitutes for each other.

AXIS T-Score is entirely off-chain – it scores agent runtime performance across 11 behavioral dimensions rather than on-chain ownership identity. This makes it useful for evaluating how well an agent executes tasks, but irrelevant for trust decisions about the human behind the agent. For a protocol deciding whether to grant autonomous execution access, AXIS covers a different question than ChainAware does.

The feeder address, criminal record, and trust delegation signals are currently unique to ChainAware across all indexed agent trust platforms. Those signals require a database of over one year of on-chain pair history, a token audit data pipeline, and a predictive fraud model trained on 20M+ wallet personas – infrastructure that takes years to build and cannot be replicated quickly. Additionally, for more context on how ChainAware positions against broader analytics alternatives, see our Web3 Analytics Tools Comparison for DeFi Dapps in 2026.

The moat is the data, not the formula

ChainAware publishes the categories of signals that feed into the Agent Trust Score. However, the exact weights, thresholds, and model coefficients are not published – not because the methodology is proprietary for competitive reasons, but because publishing thresholds would allow bad actors to calibrate their behavior to stay just below each detection cap.

More importantly, the real moat is not the formula. The moat is the data. An operator who knows every weight and threshold in the Agent Trust Score formula still cannot change their on-chain history. A wallet that created a honeypot token in November 2025 cannot remove that event from the blockchain. A feeder address that funded rug pull operators throughout 2025 cannot alter its transaction graph. The formula can be known. The data cannot be changed. That asymmetry is what makes on-chain behavioral intelligence a durable trust infrastructure rather than a gameable reputation system.

Frequently Asked Questions

What chains does the Agent Trust Score cover?

ChainAware’s Agent Trust Score indexes ERC-8004 agents across Ethereum mainnet, BSC (BNB Chain), Base, and Avalanche C-Chain, with Mantle in progress. These five chains cover the majority of ERC-8004 registry activity. The owner wallet and feeder analysis draws on ChainAware’s broader behavioral intelligence database, which covers 8 blockchains total including Polygon, TON, TRON, and HAQQ.

How long does the Agent Trust Score API take to respond?

The Agent Trust Score API returns results in under 100ms for agents already in the ChainAware database. First-time scoring of a newly registered agent may take slightly longer as the owner and feeder addresses are resolved and scored. Pre-scoring of agents during indexing ensures that the vast majority of ERC-8004 agents in the registry return sub-100ms scores at query time.

Does the Agent Trust Score require any PII or KYC data?

No. The Agent Trust Score is derived entirely from public on-chain data. No personal information is collected, no identity verification is required, and no data is stored beyond what is already publicly available on the blockchain. This makes the score compatible with DeFi’s privacy-first ethos and compliant with GDPR and similar privacy regulations by design.

Can an agent improve its score over time?

Yes – through the owner wallet’s behavioral history, not through the agent wallet itself. As the owner wallet accumulates genuine on-chain experience, interacts with a broader range of protocols, and maintains a clean fraud probability score, the Reputation Score feeding into the Agent Trust Score improves. Trust delegation then carries that improved score to the agent wallet. However, criminal record signals (rug pull history, honeypot creation) are permanent hard caps – they do not improve over time because the underlying on-chain events are immutable.

What happens when an agent is transferred to a new owner?

ERC-8004 agents are ERC-721 NFTs and can be transferred between wallets. When ChainAware detects an ownership transfer, the Agent Trust Score recalculates using the new owner wallet’s behavioral history. This is intentional: the trust score tracks the current controlling entity, not the original registrant. Consequently, an agent cannot inherit a previous owner’s strong score after transfer – each new owner is scored from their own on-chain history.

How does Agent Trust Score integrate with the Prediction MCP?

The Agent Trust Score is available as a native tool through ChainAware’s Prediction MCP server. Any Claude-based agent can call agent_trust_score(chain_id, agent_id) as a natural language tool call, receiving the structured score and flags response without custom API integration code. For protocol teams building on the MCP stack, this means agent verification can be added to any existing MCP-connected workflow in minutes rather than days.

Is the Agent Trust Score different from the Wallet Reputation Score?

The Agent Trust Score uses the same 0-1000 scale and the same underlying Reputation Score formula as ChainAware’s Wallet Reputation Score. However, it applies that formula to multiple addresses simultaneously (owner wallet, agent wallet, feeder address) and combines them using trust delegation logic and fleet-level farm detection signals that do not exist in the standalone Wallet Reputation Score. The two scores are directly comparable on the same scale – a wallet Reputation Score of 750 and an Agent Trust Score of 750 represent the same trust tier.

How does ChainAware handle agents with no traceable feeder address?

When the feeder address cannot be determined – either because the owner wallet was funded through multi-hop paths that obscure the source, or through infrastructure (bridges, faucets) that does not produce an attributable single feeder – ChainAware applies a feeder-unknown penalty to the Agent Trust Score. This penalty reflects the information asymmetry: legitimate operators funded through normal CEX withdrawals produce traceable feeder paths; operators who route funds to obscure the source are doing so for a reason. The penalty is not a hard cap – a very strong owner wallet and clean criminal record can partially offset it. Nevertheless, unknown feeder remains a risk signal that appears in the API response as the FEEDER_UNKNOWN flag.

What does a DeFi credit scoring integration look like alongside Agent Trust Score?

For lending protocols specifically, Agent Trust Score and DeFi credit scoring serve complementary functions. The Agent Trust Score answers “should this agent be permitted to interact with my protocol at all?” – a gate decision. The DeFi credit score answers “given that this agent is permitted, what collateral ratio and interest rate tier should apply to its lending activity?” – a parameterisation decision. Running both checks in sequence gives lending protocols the most complete picture: a verified legitimate agent operating at its correct creditworthiness tier.

Further Reading

• Agent Trust Score – Complete Methodology – the full technical explanation of how the score is computed, including all five scoring layers and flag definitions
• Web3 Wallet Auditing Providers in 2026 – the complete landscape of wallet intelligence providers, from raw data to actionable predictions
• AI-Powered Blockchain Analysis for Crypto Security – how ChainAware’s fraud prediction model achieves 98% accuracy
• Rug Pull vs Pump and Dump – the fraud patterns that feed the Agent Trust Score criminal record database
• Blockchain Compliance for DeFi: KYT and AML Guide – regulatory context for DeFi protocol compliance in 2026
• DeFi Credit Score Platforms Compared – how to combine agent trust verification with borrower creditworthiness assessment
• Prediction MCP Setup Guide – add ChainAware behavioral intelligence to any Claude agent in minutes
• 32 Ready-Made Agents – pre-built Claude agents including agent verification, fraud detection, and compliance screening
• Web3 Analytics Tools for Dapps: Complete Comparison – where agent trust scoring fits in the broader DeFi analytics stack
• Blockchain Data Providers for AI Agents – the data infrastructure layer that feeds agent intelligence systems

---

ChainAware.ai is the Web3 Agentic Growth Infrastructure – behavioral intelligence for DeFi protocols, AI agents, and individual crypto users. 20M+ wallet personas, 98% fraud detection accuracy, <100ms API latency across 8 blockchains. Try free at chainaware.ai.