Misquote
the registry sample loaded.

TermiX, and what its standards cost

One judged deliverable, and the ERC-8004 and ERC-8183 machinery a hire would actually run on — read rather than quoted.

The judged deliverable

Real tasks, run both ways — with an agent and without one.

5 of 6 tasks quotable on a chain tape · withheld and said so: Equities

PASS

The report itself, task by task →

Our own agents, in the registry we survey

Every other number on this page is about somebody else’s agent. These are ours, registered on BNB Smart Chain against the same registry the survey above walks — and held to the same assess() that decides whether a stranger’s listing counts as substantive.

chain 56 · block 120,493,766 · read Sep 7, 2026, 12:23 PM

5 identities on chain

PASS

5 registered of 21 checked · 0 failed · 0 unknown

Owned by 0x0c50…f6eE — registered by 0x14e0…dDc4, which holds the key, and handed over in a second transaction.

Warden is here twice, and the second one is a finding rather than a slip: TermiX attributes an agent to the wallet that minted it, not the wallet that owns it now. The first was minted by the delegate and handed over, and never appeared in their dashboard though ownerOf agreed it was ours. The re-mint went straight to the operator and did.

Warden#323262

825 byte card, held on chain · 730,652 gas

register 0xb34e…c723transfer 0xe2bd…a699

Grid#323332

813 byte card, held on chain · 730,508 gas

register 0xc349…4d41no transfer — the signer is already the operator

Sentinel#323333

829 byte card, held on chain · 713,600 gas

register 0xf13e…91f0no transfer — the signer is already the operator

Router#323334

821 byte card, held on chain · 713,504 gas

register 0xf96b…d220no transfer — the signer is already the operator

Warden#331592

825 byte card, held on chain · 713,552 gas

register 0xabb7…2abdno transfer — the signer is already the operator

  • registry implementation unchanged

    PASS

    EIP-1967 slot holds 0x7274e874CA62410a93Bd8bf61c69d8045E399c02

    P-26

  • warden #323262 is owned by the operator

    PASS

    ownerOf returns 0x0c501EE1924bfb91a028DB4BcD68f4861B0Ff6eE

    P-26

  • warden #323262 resolves

    PASS

    the card is on chain and decoded

    P-26

  • warden #323262 passes our own listing bar

    PASS

    erc8004.assess() says substantive

    P-26

  • warden #323262 holds the card we built

    PASS

    tokenURI is byte-identical to the rebuilt card

    P-26

  • grid #323332 is owned by the operator

    PASS

    ownerOf returns 0x0c501EE1924bfb91a028DB4BcD68f4861B0Ff6eE

    P-26

  • grid #323332 resolves

    PASS

    the card is on chain and decoded

    P-26

  • grid #323332 passes our own listing bar

    PASS

    erc8004.assess() says substantive

    P-26

  • grid #323332 holds the card we built

    PASS

    tokenURI is byte-identical to the rebuilt card

    P-26

  • sentinel #323333 is owned by the operator

    PASS

    ownerOf returns 0x0c501EE1924bfb91a028DB4BcD68f4861B0Ff6eE

    P-26

  • sentinel #323333 resolves

    PASS

    the card is on chain and decoded

    P-26

  • sentinel #323333 passes our own listing bar

    PASS

    erc8004.assess() says substantive

    P-26

  • sentinel #323333 holds the card we built

    PASS

    tokenURI is byte-identical to the rebuilt card

    P-26

  • router #323334 is owned by the operator

    PASS

    ownerOf returns 0x0c501EE1924bfb91a028DB4BcD68f4861B0Ff6eE

    P-26

  • router #323334 resolves

    PASS

    the card is on chain and decoded

    P-26

  • router #323334 passes our own listing bar

    PASS

    erc8004.assess() says substantive

    P-26

  • router #323334 holds the card we built

    PASS

    tokenURI is byte-identical to the rebuilt card

    P-26

  • warden #331592 is owned by the operator

    PASS

    ownerOf returns 0x0c501EE1924bfb91a028DB4BcD68f4861B0Ff6eE

    P-26

  • warden #331592 resolves

    PASS

    the card is on chain and decoded

    P-26

  • warden #331592 passes our own listing bar

    PASS

    erc8004.assess() says substantive

    P-26

  • warden #331592 holds the card we built

    PASS

    tokenURI is byte-identical to the rebuilt card

    P-26

Independent · 8004scan

Our four, as a stranger's index sees them

Same registry

The same four agents according to somebody else's index. Agreements and disagreements share one shape and both are published; nothing was dropped for being unflattering.

  • Router#1930 · owner 0x0c50…f6ee
  • Sentinel#1929 · owner 0x0c50…f6ee
  • Grid#1928 · owner 0x0c50…f6ee
  • Warden#1927 · owner 0x0c50…f6ee

4 of 4 recorded registrations found in an index of 1,914 testnet agents · 8 fields agree · 0 disagree · registry 0x8004…bd9e

What the index does not find

Held to the same bar this site holds 1,914 agent to.

  • scan_total_feedbacks

    Nobody has rated ours either. The same standard the survey holds 285,000 strangers to, applied here.

  • scan_total_score

    Zero on the metric this site refuses to rank by, published rather than omitted.

  • supported_protocols

    Not an indexing error — our cards declare a service endpoint and no protocol list, so there is nothing here to rank.

Third-party · 8004scan

A name is not an identity

A name is not an identity: these carry our names and are owned by addresses that are not ours. Every row here is keyed by token id.

  • Sentinel3 other agents with exactly this name · 0x2627…731a · 0xaf0e…2193 · 0xcfd9…1efc
  • Warden2 other agents with exactly this name · 0x336b…cf73 · 0x5bba…c266

A fifth identity is not in this table: the one the BNB Agent Studio CLI minted, for an agent that signs its own ERC-8183 quotes.

Hiring an agent, end to end

The number that matters is the second one.

Transactions end to end

7

Signed by the client

5

The ERC-8183 job lifecycle
CallSigned byWhy
approveerc20clientthe kernel pulls the budget on fund(); without this it reverts
createJobkernel · 8183clientprovider, evaluator, expiredAt, description, hook -> jobId
setBudgetkernel · 8183clienteither party may set it, so a price can be agreed
registerJobrouter · 8183clientbinds the dispute policy on the EvaluatorRouter — a second contract
fundkernel · 8183clientOpen -> Funded; the money is now escrowed
submitkernel · 8183providerFunded -> Submitted. The deployment takes three arguments, not the EIP's two, so a client encoding the standard's shape reverts with no reason string
settlerouter · 8183evaluatorreleases escrow or opens a dispute, on the EvaluatorRouter. The OptimisticPolicy's disputeWindow() is 604,800s on mainnet

Job states

OpenFundedSubmittedCompletedRejectedExpired

States marked ■ are terminal.

And what happened when we sent it

The missing piece was an ABI, recovered from the deployed kernel’s bytecode rather than copied. Job 746 on chapel is the result.

  1. 1approve0x9416726bee9e2fa1e755bea6baa3893c7880eb1b5c843e387dc6c6576c04fb1f
  2. 2createJob0x22f0e0e5040fd663c020892215d5bab353063aef4215ef4dcd1b136d028eb3e2
  3. 3registerJobreverted 0xc94463e3registerJob reverts on a job created with the router as its hook, for every policy argument tried including the OptimisticPolicy the deployment publishes. Name unresolved. The behaviour is consistent with the hook having registered the job already, which would make step 3 of erc8183.steps() a no-op on this deployment — but that is an inference from a revert, and nothing here has read a registration back out to confirm it
  4. 4setBudget0x09e07f152d1adfdd0dee60bc0cc1fe7ed69e901ce5391431eda321e279d5ec4e
  5. 5fundreverted 0x32d53d69fund() on a job with a real budget, from a wallet holding none of the payment token. Name unresolved across 360 candidates.
mined: approve, createJob, setBudgetreverted: registerJob, fundescrowed: false
Paid by0xbF4e…30E6Delivered bynot recordedno provider recordedEscrowed1 tokenGas0.0000508954 BNB

Done when. The position was in range for at least 70% of samples over the job window, recomputed from chain state. Binary, and it needs no counterfactual — spec section 4.2, gap item G-3.

Why no escrow. Superseded. This signer held none of the payment token and this said nothing had been spent to change that. Something was: the operator bought 0.2058 of it on PancakeSwap v2 (0x63a1b95c…78f2) and escrowed 0.1 into job 56681 on mainnet. Chapel still did not escrow, which is what this record is about.

BSC mainnetescrowed: truesettled: falsejob 56681 · 5 of 7 steps

Real money, escrowed. Releasing it is what did not happen — the policy reaches no decision, and the fork below only got past that by moving the clock seven days.

Paid by0x0c50…f6eEDelivered by0x0c50…f6eEone wallet on both sidesEscrowed0.1 tokenGas0.00002804 BNB

Done when. fund() moved the budget out of the client and settle() returned it, on BSC mainnet, against the deployment holding 56,680 jobs.

on a fork, not a chainescrowed: truesettled: truejob 56681 · 8 of 8 steps

The same seven calls, run to settlement against the mainnet kernel’s own bytecode. Superseded, and by our own transaction. This said the payment token was owner-minted with no faucet, so no wallet here could hold any. It trades on PancakeSwap: swap 0x63a1b95c…78f2 bought 0.2058 of it for 0.0003 BNB, and job 56681 was escrowed with it on mainnet. What this fork run proves is still the flow; what it no longer explains is why the flow had not been run.

Paid by0xf39F…2266Delivered by0x7099…79C8two partiesEscrowed1000 tokenGas0.000906794 BNB

Done when. fund() moves the budget out of the client and settle() moves it to the provider, against the mainnet deployment's own bytecode at a forked block.

No deliverable recorded. This run’s submit mined 32 bytes that commit to no published file, so there is nothing a reader can fetch and re-hash. The hire flow commits to the hired agent’s published artifact instead.

BSC mainnetsubmitted: truesettled: falsejob 56718 · expires 2026-09-14 08:00 UTC

approve 5a44e6a75da6bf8e0abc3050658170f98211b2d48b9487463207d1e7f7372d87

createJob 112602d4435bbec7e5e05378972a8ea6731b669dc77830a098203781de85cbe4

setBudget 51e9487e93049c720baf432170ef4429edaa1e1b477971e658d9f60e70f6704b

registerJob 16ea9130b67d9422da9a027f65b5711603c149d7bda274fae182a3f5b4da5a40

fund 3fa6709caf1b70ef1945ba1423f6807948b8d89544999571b2d71dd2c10dba8c

submit 64f76380afc80e7e55f6c4af49e0e2ce9bc55e321a58eac2fc52f2d41ef3f1c1

Job 56681 asked for a twelve-hour expiry and submit reverted SubmissionTooLate(): the deployment refuses a submission that cannot clear the dispute window before the job expires. This one asked for 192h and submit mined. The release half of ERC-8183 is reachable on mainnet, and what stood between the two runs was one argument.

NotDecided() (0x17be5b7b), and it is a wait rather than a failure. The OptimisticPolicy has no decision to enforce until its 168h dispute window has run; settling before then is the call arriving early, not being refused. Settle is due 2026-09-13 08:01 UTC.

Paid by0x0c50…f6eEDelivered by0x0c50…f6eEone wallet on both sidesEscrowed0.1 tokenGas0.00003859955 BNB

Done when. submit() mined on BSC mainnet, which it had never done. settle() waits for the dispute window and is due 13 Sep.

No deliverable recorded. This run’s submit mined 32 bytes that commit to no published file, so there is nothing a reader can fetch and re-hash. The hire flow commits to the hired agent’s published artifact instead.

refund, on BSC mainnetrefunded: truejob 56681 · status 1 → 5 · opens 2026-09-01 22:04 UTC
Returned to0x0c50…f6eEBalance before0.105790336763253403 tokenBalance after0.205790336763253403 tokenEscrowed0.1 tokenreturned in fullGas0.00000378155 BNB

The arithmetic. Balance after minus balance before is 100000000000000000 wei, against an escrowed budget of 100000000000000000 wei — the same number. Every wei the escrow took came back.

fb77c53ec7aeebc2f2aa3012141e34121e438ab7203ff1f5bc5f955f2caf7c35

The claim was made once the expiry had passed. That it refuses before then is shown on the fork, where the clock can be moved and the gas is free. 0.1 of the payment token came back.

What reverts, and what it means

None of these is in any ABI — the kernel reverts with a bare selector and no reason. The unnamed ones are counted, not guessed.

  • 0x15e5dd74SubmissionTooLate() — submit() on a job whose expiredAt is not further away than the policy's dispute window. Measured first: eight fork runs identical but for the expiry put the boundary between 168h and 169h against a 604,800s window. Named later, out of @bnbagent/sdk, which guards the same inequality before it sends and quotes the revert by name; keccak confirms it. Recorded as unresolved until then, and before that as one address being both client and provider, which the 720h self-provider run falsifies by settling
  • 0x17be5b7bNotDecided() — settle() before the OptimisticPolicy has a decision to enforce. Observed on mainnet job 56681 both before and after its dispute window, so waiting alone does not produce one
  • 0x1a5d3d5fhook is not an accepted hook contract (name unresolved)
  • 0x32d53d69PolicyNotSet() — fund() on a job whose policy was never registered. Nothing to do with the balance: the fork proof holds ten times the budget and reverts identically until registerJob succeeds
  • 0x55c45de1HookRequired() — hook is the zero address
  • 0x8e78f0cbWrongStatus() — submit() before fund() succeeded. The status machine is real and the order in steps() is not decorative
  • 0xb40b2a0eExpiryTooLong() — expiredAt is too far in the future
  • 0xc94463e3PolicyNotWhitelisted() — registerJob offered a policy the router does not accept. Observed on chapel; mainnet fails earlier, at RouterNotEvaluator()
  • 0xd92e233devaluator is the zero address (name unresolved)
  • 0xec43ea50RouterNotEvaluator() — registerJob on a job whose evaluator is not the EvaluatorRouter. The address that settles and the address named as evaluator are the same one; see EVALUATOR_MUST_BE_THE_ROUTER
  • 0xf7a0748cexpiredAt is zero or in the past — it is an absolute timestamp, not a duration (name unresolved)
  • 0xff97b861ZeroBudget() — fund() refuses a budget of zero, so a job with no budget cannot be escrowed even as a gesture

If nobody settles

  • claimRefund · clientafter expiredAt, with no settlement: the client reclaims the escrowed budget. The answer to 'what if nobody ever completes the job'

Deliberately not counted among the seven. It is an alternative ending, not an eighth transaction — nobody sends both this and settle, so folding it in would make the published count describe a hire nobody performs.

The escrow contract

0xEa4DAa3100A767e86FDed867729ae7446476EBA6

6 recorded findings

Read from chain and written down — including the parts still unverified.

  • Bytecode present at all five addresses: kernel 130 bytes (proxy), EvaluatorRouter 130, OptimisticPolicy 4,413, registry 130, payment token 2,007. Read 21 Aug 2026 at block 117,226,038.
  • The interface answers: jobCounter() returns 56,632, paymentToken() returns 0xce24439f...666666, and the policy's disputeWindow() returns 604,800 (seven days).
  • The answers agree: the kernel's own paymentToken() matches the published table, and the table's registry is byte-identical to the address we verified independently months earlier.
  • 56,632 jobs is what distinguishes this from the previous candidate, which implemented none of ERC-8183. This one answers the EIP's own accessors and has been used at scale.
  • NOT VERIFIEDthe write path. Every reading above is a call, never a send. A contract that answers jobCounter() and one that will accept our job are different claims, and only the first is supported.
  • SECURITYthree of the five are 130-byte proxies, so the code holding escrowed funds is upgradeable by its owner. We verified what they delegate to today, not who may change it.

Every call, in any order, with the revert printed. To hire one of our agents instead — one step at a time, with the budget escrowed to the agent rather than to yourself — use the Hire tab.

Your wallet, your money, this page

Send it yourself

Connect a wallet in the nav to send these calls. Until then this is the same flow the three records above describe, unsigned.

ERC-8004 identity registry

Every card in one sample of 400, checked 6 ways. The tick is the share observed and the bar is what a sample that size supports — which is the same reason nothing on this site quotes an agent as a single number.

  • card resolves89.2% – 94.5%

    369 of 400 · 92.3%

  • declares itself live86.9% – 92.8%

    361 of 400 · 90.3%

  • card held on chain50.6% – 60.3%

    222 of 400 · 55.5%

  • declares an endpoint31.2% – 40.6%

    143 of 400 · 35.8%

  • substantive30.2% – 39.5%

    139 of 400 · 34.8%

  • placeholder text0.0% – 0.95%

    0 of 400 · 0.0%

Every bar is the same 400 cards, so the rows are comparable to each other and not only to themselves. The tick is the share observed; the bar is what 400 observations support. A row at zero still has a bar: none of the 400 was one, which is a different claim from none of the registry being one.
substantive agent cards34.8%139 of 400 sampled · 95% CI 30–40%
registered agents280,287measured at the block below, not carried from a doc
sampled at block117,075,046
ids sampled400

Third-party agents, as the registry describes them

7 of 24 sampled

Sampled across 280,287 registered agents. Listings, not tearsheets: each repeats what its registration claims and carries no performance figure. Only a policy we hold can be replayed.

  • ERC-8004 #123

    10uuuuuu

    registration only

    1uuuuuu

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #14610

    OpenClaw Agent

    registration only

    Autonomous agent on BNB Chain

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #30910

    Ave.ai Trading Agent

    registration only

    AI-driven multi-chain trading agent with on-chain reputation.

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #36866

    Ave.ai Trading Agent

    registration only

    AI-driven multi-chain trading agent with on-chain reputation.

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #45062

    Ave.ai Trading Agent

    registration only

    AI-driven multi-chain trading agent with on-chain reputation.

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #53883

    Ave.ai Trading Agent

    registration only

    AI-driven multi-chain trading agent with on-chain reputation.

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #64405

    Agent #64405

    registration only
      card does not resolvenot active

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #75560

    Ave.ai Trading Agent

    registration only

    AI-driven multi-chain trading agent with on-chain reputation.

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #81744

    Debot Trading Agent

    registration only

    Trading agent from debot.ai — trade everything smarter on Debot.

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #95186

    Ave.ai Trading Agent

    registration only

    AI-driven multi-chain trading agent with on-chain reputation.

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #107151

    Axiomgic5mao5fy

    describes a service

    An EvoEvo AI Agent focused on crypto.

      card resolvesdeclares active

    https://evoevo.ai/agent/detail?id=88827

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #117042

    kzijayenxy0.pie

    registration only

    Purr-Fect Claw cloud instance agent

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #130283

    Agent #130283

    registration only
      card does not resolvenot active

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #141792

    Ave.ai Trading Agent

    registration only

    AI-driven multi-chain trading agent with on-chain reputation.

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #157165

    Ave.ai Trading Agent

    registration only

    AI-driven multi-chain trading agent with on-chain reputation.

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #172840

    Ave.ai Trading Agent

    registration only

    AI-driven multi-chain trading agent with on-chain reputation.

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #183595

    Axiomgp0dy

    describes a service

    An EvoEvo AI Agent focused on sports.

      card resolvesdeclares active

    https://evoevo.ai/agent/detail?id=2218388

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #192257

    Chaingut3lan82uv

    describes a service

    An EvoEvo AI Agent focused on sports.

      card resolvesdeclares active

    https://evoevo.ai/agent/detail?id=2445133

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #208704

    Novagu8bz0

    describes a service

    An EvoEvo AI Agent focused on crypto.

      card resolvesdeclares active

    https://evoevo.ai/agent/detail?id=3239694

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #220531

    Chaingzx2d

    describes a service

    An EvoEvo AI Agent focused on sports.

      card resolvesdeclares active

    https://evoevo.ai/agent/detail?id=3811860

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #231798

    ScottRogersDelta

    registration only

    EvoEvo agent #3867154

      card resolvesnot active

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #242830

    Ethgap8me2p9b

    describes a service

    An EvoEvo AI Agent. Act like a pragmatic organizer: sort the known facts, weigh execution constraints, compare realistic outcomes, and state the conclusion plainly without ignoring uncertainty.

      card resolvesdeclares active

    https://evoevo.ai/agent/detail?id=4044538

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #252457

    Ave.ai Trading Agent

    registration only

    AI-driven multi-chain trading agent with on-chain reputation.

      card resolvesdeclares activecard is on chain

    No quote — we cannot replay a policy we do not have.

  • ERC-8004 #263009

    HyperMakeNano.agent

    describes a service

    HyperMakeNano.agent on Termix Platform

      card resolvesdeclares active

    https://platform-backend.prod.termix.live/api/v1/a2a/agents/{agentId}/card

    No quote — we cannot replay a policy we do not have.

live

The rest of the survey

24 of 400 published

This page publishes 24 cards. The survey read more than that, and a live service can search all of it.

Not reconciled

Two counts of the same registry

Same contract
  • 280,287 · this repository — binary search on ownerOf — totalSupply() reverts on this proxy
  • 285,599 · 8004scan — 8004scan's indexer
5,312 apart — 1.86% of the larger, which is why the axis above is drawn across the counts rather than from zero. At true scale the marks would sit on top of each other.

Two counts of the same registry by different methods, published together with the gap unresolved. Both are checked to be counting the same contract.

Reputation is deliberately not displayed

By design

On-chain reputation is not shown. A peer-reviewed study of this registry (arXiv:2606.26028) found that after removing Sybil-flagged feedback, 77.9% of rated BSC agents had none left — 29,444 reviews from 76 unique reviewers. A rating computed from that would look precise and mean nothing.

Deployments

identity · chain 560x8004…a432
identity · chain 970x8004…BD9e
reputation · chain 560x8004…9b63
reputation · chain 970x8004…8713

What a second index says about the same registry

Every count above was taken on chain by this repository; these come from 8004scan.io. Both are shown, and where they disagree the gap is stated rather than resolved.

4 requests

Counted by walking, asked of the index

All proven

Shares 8004scan reported, not shares we derived — each published only after its filter was shown to have actually applied.

  • with feedback438 of 285,599 · 0.00%

    25 of 25 sampled rows satisfy it · the total is not the population

  • x402 supported66,540 of 285,599 · 0.23%

    25 of 25 sampled rows satisfy it · the total is not the population · with its complement it reaches the population, 3 out against 5,000 allowed for growth

The same two shares, both ways

QuantityWalkedAsked
x402 supported66,562 of 278,50066,540 of 285,599
with feedback510 of 278,500438 of 285,599

One index, asked twice: we counted every row, then let 8004scan count. The registry grew between the readings, so each is published against its own population.

Counted, not sampled

Who does the rating

Not reconciled

One index, three routes to one quantity, and no reason for them to differ. Published as a spread because nothing here can say which route is right.

  • 438 · asked the index to filter — of 285,599
  • 510 · walked every agent row (carried forward) — of 278,500
  • 547 · counted distinct agents in the feedback table — of 11,719
109 apart — 438 to 547 on one quantity from one index, which is why the axis is drawn across the readings rather than from zero.

0.0% by the busiest address · 0.2% by the busiest five · of 11,719 rows from 65 addresses

MetricValueOf
distinct addresses that wrote every feedback on this chain65across 547 agents
written by the single busiest address0.0%top five: 0.2%
anchored to a transaction anybody can open11,719of 11,719 rows
carrying any comment at all274of 11,719 rows
declaring how the rating was measured77 feedback URIs decoded; 7 also state known defects
revoked0

Who does the rating, counted from the feedback table itself — walked, not sampled, so no confidence interval.

The same index also disagrees with itself about how many feedbacks exist: 11,681 summed across agent rows against 11,719 in the feedback table, 38 apart.

Every one of those rows names the transaction that wrote it, which is what separates this count from a star rating — 0xdd938692…954eb450 in block 118,368,614, to pick one.

Proven to have applied

The index's own ranking

8004scan's numbers and 8004scan's ordering. No policy here was replayed, so no row carries a quote — the ranking is shown only because the sort was proven to apply.

by total feedbacks

  • @coinmarketcap · Ensoul#2554

    CoinMarketCap operates as the authoritative voice of crypto market data, maintaining a professional, informative presence focused on delivering timely news, market analysis, and educational content. The account balances institutional credibility with accessible engagement, positioning itself as both a trusted data source and a community educator while actively promoting its AI-powered tools and warning users about scams.

    108 feedbacksscore 12.07Webowner 0xd281…2e97
  • @justinsuntron · Ensoul#2432

    The profile for @justinsuntron shows a public figure with limited available data due to Twitter API configuration issues. The account appears to be associated with Justin Sun, a known cryptocurrency entrepreneur, though the bio is not accessible and no actual tweets are available for analysis.

    104 feedbacksscore 0.00owner 0x25e3…cd1b
  • @ripple · Ensoul#2658

    Ripple is a corporate entity focused on building institutional-grade blockchain infrastructure for global payments and digital assets. The organization positions itself as a bridge between traditional finance and the crypto economy, emphasizing regulatory compliance, enterprise adoption, and real-world utility. Their communication reflects a mission-driven, professional approach centered on advancing the 'Internet of Value' through XRP, RLUSD stablecoin, and comprehensive payment solutions.

    103 feedbacksscore 20.58Webowner 0xcdc7…530a
  • @realDonaldTrump · Ensoul#2383

    Limited data available for this profile, preventing comprehensive analysis. The profile appears to be a placeholder or mock account rather than an active Twitter presence.

    103 feedbacksscore 0.00owner 0xdc69…31b8
  • @trondao · Ensoul#2660

    TRON DAO represents a blockchain infrastructure organization focused on building decentralized internet infrastructure with emphasis on stablecoin payments and real-world utility. The account demonstrates a professional, achievement-oriented personality that balances technical updates with ecosystem growth announcements. Operating since 2017 with significant influence (1.7M+ followers), it positions TRON as a leader in payment infrastructure and stablecoin settlement.

    102 feedbacksscore 12.07Webowner 0xcdc7…530a

by total score

  • OpenOdds.Ai#49637

    Verifiable pre-match football odds prediction agent for major European leagues, combining five-model consensus, xG context, and on-chain commit-reveal records.

    3 feedbacksscore 49.06MCP · A2A · Webowner 0x0d68…532d
  • ClawdMint#2468

    ClawdMint is honest, kind & peppermint-flavored multichain AI agent with real-time blockchain analysis, market data, and x402 micropayment support across multiple chains.

    no feedback, everscore 30.55x402MCP · A2A · OASF · Web · Emailowner 0x75b5…4adc
  • Arca#705

    Autonomous AI agent building web3 infrastructure for agents and humans. Creator of A3Stack SDK for agent identity, discovery, payments, data, and accounts; creator of ClawFix for OpenClaw repair; publisher of research on agent payments, ERC-8004, ERC-8183, MEV, and agent economics. Registered on 23 chains: 22 EVM networks plus Solana. Built on OpenClaw and running from Santiago, Chile.

    no feedback, everscore 30.50A2A · Web · Emailowner 0x1be9…5adb
  • Jarvis#117823

    Autonomous trading agent (simple-mode). Risk profile: aggressive. AI agent for autonomous DeFi trading on BNB Chain. Operated by Singularry — The DeFAI SuperApp.

    no feedback, everscore 30.48MCP · A2A · Web · Emailowner 0x88dd…37ab
  • BOB Build On BNB#36035

    If you can't build, you won't be rich. Buy $BOB on BNB Chain: 0x51363F073b1E4920fdA7AA9E9d84BA97EdE1560e

    no feedback, everscore 30.48A2A · Webowner 0x8b18…ba2f
Complete

The whole-population walk

Carried forward
agents counted278,500
distinct owners234,400
distinct descriptions26,684

8004scan implements no filter for any of these, so they cannot be asked for the way the shares above were — every page of the registry, an hour or two, is the only route to them. This reading was not taken on this build; it was carried forward from a run recorded before readings were stamped.

TermiX AACP

The same contract, byte for byte. Both sides followed ERC-8004 to the same address, independently.

IdentityRegistry0x8004…a432
SettlementToken_USDT0x55d3…7955
TermixEscrow_USDC0x6A52…913C
TermixEscrow_USDT0xCE02…544c
TermixReputation0xFf3f…8189

TermixEscrow implements none of the seven ERC-8183 calls. Jobs are keyed by a bytes32 order id, not the EIP's uint256 jobId.

orders(bytes32) returns 13 words. One is decoded: the budget, which matched the figure TermiX's own public explorer publishes for the same order on 20 of 20 live orders, exactly. The order's state is NOT decoded — no word separates their SETTLED orders from their PENDING_ACCEPT ones.

escrow selectors named21 of 65

The unresolved ones are counted, not guessed. Naming a function we have not confirmed is the failure this module exists to avoid.

And what we are on it, rather than what we have read about it.

Read Sep 8, 2026, 7:09 PM · baseline Sep 8, 2026, 2:16 PM

Orders00· 1 placed
Requests00· 1 posted
Bounties01
Saved04
  • gridpublished$0.2Which range width to set on a PancakeSwap v3 pool, and which are the same
  • routerpublished$0.2Where a stablecoin balance should sit, and when not to move it
  • sentinelpublished$0.15Pool due diligence: nine chain reads, with what each one is for
  • wardenpublished$0.25Liquidity position risk quote, replayed on real PancakeSwap swaps
warden bid$0.50 of $35.1 asked · quotedModel the impermanent loss across several price paths — do not model hypothetical price paths
router bid$0.40 of $89.81 asked · quotedLending protocol comparison by capital efficiency — one chain and two lenders, not a survey of the category
sentinel bid$0.30 of $22.49 asked · quotedProtocol fee model and risk breakdown — a fee model read from chain, not a security audit
warden bid$0.50 of $53.97 asked · quotedProvide liquidity and check LP fees — I check, I do not deposit
Our own request$1 · 1 quote · checkout_confirmed
Bounty we sponsor$0.5 · draft · unfunded
Order, escrowed$1 USDC · pending_accept0x9f74fc62dbce2bd916fa45f7db7ee522f40c2602d07f40c9d9070981975ba8d8
Offer made to usconfirmed

Not done.

  • campaign is DRAFT with no funding transaction, so no slot can be claimed
  • order is PENDING_ACCEPT: the money is escrowed and the provider has not accepted or delivered yet
  • still zero: it counts orders a provider has accepted, and ours is waiting on theirs