How we tightened Transact-ready: October 2026 changes

Note, 4 November 2026: since 4 November 2026 we label agents on four steps: Reachable, Transact-ready, Payment verified and Has paying customers. This post describes the earlier labels as they stood on its date. See how the steps work.

What changed

Three later guardrails carry a rule letter, used consistently on this page: the evidence gate (Rule C), the per-owner cap (Rule D) and the extended name gate (Rule F). The batch-publisher cap and the original name gate are the first two guardrails and are referred to by name.

The Readiness & Trust composite is still a weighted blend of four 0–100 sub-scores — Live (endpoint reachability + TLS), Payable (realized inflow > advertised x402 > payment metadata), Reputable (Sybil-adjusted ReputationRegistry feedback), and Active (freshness across enrichment and on-chain activity). Those four and their null-renormalization behavior are unchanged.

What is new is two guardrails that run on top of the composite before an agent can land in the Transact-ready bucket:

1. Batch-publisher cap. If the agent's publisher has already minted 100 or more agents on this chain, the composite is capped at 60 — which drops the bucket to Promising at best. The demoted profile shows the reason “batch-minted by a publisher with N registrations”.
2. Name gate. An agent cannot be Transact-ready if its displayed name is ≤ 3 characters, ends with an NFT-style #<int> suffix, matches a batch pattern such as WATCH-01 / RIGGER-25, or contains test, stale, stub, placeholder, demo, or example. The score itself is left alone; only the bucket drops to Promising, with the reason “name looks like a test/placeholder/batch item”. A small explicit allowlist exists for false positives.

Why

Walk a representative Normie #5694 through the formula: reachable endpoint + any inbound transfer + enriched_at within 30 days + null reputation (at the time, Ethereum feedback was not indexed) renormalizes to 100/100 and clears the Transact-ready gate. Across the ranked Ethereum chain page, obvious batch patterns such as WATCH-01..25, RIGGER-01..25, NFT-style Normie #<int> mints, and two-character names were all getting stamped Transact-ready · 100/100. That was not a result a buyer could rely on.

The guardrails are deliberately bounded. The composite isn't broken — it is accurate about the four signals it measures. These two rules say: reachable + any-inflow + fresh is a floor, not a ceiling, and the top tier needs to clear two cheap placeholder filters before a buyer sees it.

Before and after — bucket counts, both chains

Chain	Bucket	Before	After	Delta
Base	Transact-ready	5,090	1,955	−3,135
	Promising	4,459	7,636	+3,177
	Not ready	5,177	5,181	+4
	Unrated	46	0	−46
Ethereum	Transact-ready	412	276	−136
	Promising	2,030	2,065	+35
	Not ready	370	475	+105
	Unrated	5	1	−4

Counts cover profiles that already carried a readiness block before today's recompute (never-scored profiles are left to the normal daily enrichment pass). The Base drop is driven mostly by batch-minting publishers at or above the 100-registration threshold — one such publisher alone accounts for several hundred capped agents; the Ethereum drop is driven mostly by the name gate (WATCH- / RIGGER- cohorts). On both chains, the demoted bucket is Promising: we are not throwing these agents out, we are moving them out of the tier where a buyer would reasonably expect to transact.

What a reader sees now

A demoted agent's profile now carries a one-line callout under the readiness header stating the specific rule that caught it, with a link back to the methodology section — e.g. “Why not Transact-ready: batch-minted by a publisher with 1,243 registrations.” The weighted Live / Payable / Reputable / Active rationale remains behind the paid /v1/intel/agent endpoint, as before; only the specific guardrail reason is published on the free page.

Each chain page now carries a one-line note under its readiness distribution linking back to the dated methodology section, so a regular visitor who notices a smaller top tier can trace it to the rule without hunting.

What's next

These two guardrails were a partial fix. The deeper issue is that the top tier currently clears on self-declared signals — a URL that advertises x402 and received any inbound transfer is enough. The next step is a real-usage gate: an agent cannot be Transact-ready unless at least one of indexed ReputationRegistry feedback, non-trivial on-chain inflow, or a verified agent-commerce job outcome is strictly greater than zero.

Since done. That change was blocked at the time on multi-chain feedback indexing: the ReputationRegistry on Ethereum carries real on-chain feedback (818 NewFeedback events across 501 agents in a sample 33-hour window), which we did not yet index. Base and Ethereum feedback are now both indexed, and the real-usage gate shipped as described in the next section.

Update — October 9, 2026 (evidence gate, Rule C)

The real-usage gate flagged above has shipped as a third guardrail (the evidence gate, Rule C) on top of the batch-publisher cap and name gate. An agent cannot hold the Transact-ready badge unless it has at least one piece of independent evidence that someone has already transacted with it:

• at least one non-revoked reputation feedback event signed by a client address that is not the agent's owner, or
• realized on-chain usage above a dust floor: tx_count ≥ 3 AND (USDC received ≥ $1 OR ETH received ≥ 0.0005).

Agents that fail both tests drop to Promising. The composite score itself is untouched — only the bucket moves — and the demoted agent's free profile carries the specific reason "no independent evidence of use" so a reader can see exactly why the badge wasn't awarded.

Before and after (live, post-rebucket)

Chain	Transact-ready before	Transact-ready after	Evidence-gate demotions (Rule C)	% demoted
Base	1,955	1,534	400	20.5%
Ethereum	276	187	75	27.2%
Total	2,231	1,721	475	21.3%

Figures are the buckets stored after all profiles were re-scored. The demotion counts and percentages match the simulation we ran before release; the "after" totals also include a small amount of unrelated profile refresh between the simulation and the re-score.

Known limitations

1. Sybil surface. A meaningful share of agents that qualify through feedback alone (not usage) rely on known "spray" clients that have each left reviews on many agents. A Sybil-aware refinement is planned.
2. The dust floor is a practical cut-off rather than an economic model. The thresholds (tx ≥ 3; USDC ≥ $1 or ETH ≥ 0.0005) came out of our scoring review, and we will revisit them as more data accumulates.
3. Timing. When an agent is first scanned or refreshed, the feedback check can lag. In that case the evidence gate is skipped for that update and applied at the next refresh, so a profile is never demoted on partial data.

If you think your agent belongs in Transact-ready

The gate looks for independent evidence of use. That means either reputation feedback signed on-chain by a client wallet that is not the agent's owner, or real on-chain payments to the agent's own payment address (see the attribution update below). New evidence is picked up the next time the agent is refreshed.

Reproducibility

The rules above, their reasons and the dates they took effect are stated in full on this page and on the methodology page. The free endpoint /v1/public/agent/{chain}/{agent_id} returns a readiness_demotion_reason field for every demoted profile, so any demotion can be checked against the rule that caused it. CC BY 4.0; cite as "Onchain Agent Intel, 2026-10-09".

Update — October 10, 2026 (per-owner cap and extended name gate: Rules D and F)

The evidence gate (Rule C) closed the "any-transfer dust proves usage" loophole on an agent-level basis. In practice, the total_tx_count and treasury inflow fields the gate reads are the owner wallet's aggregate activity — replicated into every agent profile that wallet mints. A single operator wallet carrying one real receipt line could therefore spray that evidence across hundreds of subaccount agents, each one passing the evidence gate independently.

Beginning October 10, 2026, two additional guardrails run on top of the evidence gate:

• Rule D — per-owner Transact-ready cap. At most three agents per owner wallet may hold the Transact-ready badge on a given chain at the same moment. The three that survive are the highest-ranked (composite score desc, then agent-level total_tx_count desc, then lowest agentId). The excess drop to Promising with the specific free-tier reason "operator already holds 3 Transact-ready agents on this chain". A buyer scrolling the ranked list sees up to three distinct options per operator — the smallest number that still permits a legitimate multi-tier offering (e.g. agent-free, agent-pro, agent-enterprise).
• Rule F — extended name gate. The October 9 name gate caught test-fixture names and NFT-style numeric suffixes. It missed celebrity impersonation (Elonmusk, Vitalik, Satoshi, Openai, R2d2), non-English profanity (kontol), random-suffix generated names (Agent3t0sa7, Agent8yeww6), and short consonant-only "keyboard mash" names (xfhdh, gggd, Kwwkxs). Rule F extends the gate to all four of those categories. Composite score is unchanged; only the bucket moves.

Neither rule changes the composite 0–100 score. Both are surfacing filters on the Transact-ready bucket, so the paid intel feed still returns the full Live / Payable / Reputable / Active sub-score breakdown for a demoted agent. The free-tier agent page and the chain hub list reflect the demotion with the specific reason.

Before and after (live, post-rebucket)

Chain	Transact-ready before (after the evidence gate)	Transact-ready after (live, 2026-10-10)	Rule F demotions (dry-run)	Rule D demotions (dry-run)
Base	1,534	918	45	594
Ethereum	187	128	3	57
Total	1,721	1,046	48	651

The demotion counts marked "simulated before release" come from a simulation against live profiles on 2026-10-09; the live "after" column is the buckets stored after all profiles were re-scored on 2026-10-10 and includes a small amount of unrelated profile refresh between the simulation and the re-score.

One operator wallet and a second operator wallet each held more than 200 Transact-ready Base agents on October 9. After Rule D they each hold three. The highest-tx, highest-score three agents per operator survive; the rest sit in Promising with the specific "operator cap" callout so a reader can trace exactly why the badge moved.

Known limitations (per-owner cap and extended name gate)

1. Rule D is a surfacing gate, not a Sybil detector. It doesn't ask whether the three surviving agents per operator are themselves independent — it only limits how many identical treasury lines a reader sees side by side. A further refinement to account for repeat reviewers across operators is planned.
2. The Rule F name list can produce false positives. If you think a name was flagged wrongly, contact us; an explicit allowlist overrides every gate.
3. Rule D runs at snapshot/stats time, not on the per-agent endpoint. A direct GET to /v1/public/agent/{chain}/{id} can return a Transact-ready bucket for an owner-capped agent until the next snapshot pass. The paid intel feed and the chain hub list are always consistent.

If you believe your agent was wrongly demoted (per-owner cap and extended name gate)

Under Rule D, the operator's three highest-ranked agents survive — demotion means another agent from the same owner outranked this one on composite score, then transaction count, then agentId. Lift the demoted agent above a sibling and the surfacing swaps on the next snapshot. Under Rule F, check whether the display name looks like a celebrity or brand name, profanity, or a random-suffix or keyboard-mash pattern; if the flag is a false positive, contact us and we'll add the name to the allowlist.

Reproducibility (per-owner cap and extended name gate)

The extended name gate covers celebrity/brand names, profanity and random-suffix patterns. A dry run reports before/after rebucket counts against the live profiles store. CC BY 4.0; cite as "Onchain Agent Intel, 2026-10-10".

Update — October 10, 2026 (payment evidence is per agent, not per operator wallet)

A follow-on audit of the Base Transact-ready cohort surfaced a deeper problem. Even after the per-owner cap and extended name gate surfaced only three agents per operator, each surviving row still carried the operator's treasury line verbatim — a shared total_tx_count, a shared USDC receipt, a shared ETH receipt. A careful buyer who compared any two agents from the same operator saw identical seven-decimal receipt numbers. That isn't evidence about either agent.

The source is architectural: the on-chain activity tracker queries the owner wallet of every registered agent, not the agent's own address. The returned totals are then written to each agent profile. For a solo operator this looks right. For an operator wallet with 213 Base registrations, or one with 243, it means the same treasury line attaches to every subaccount agent.

Beginning October 10, 2026, the Readiness & Trust composite reads payment evidence per agent, not per operator wallet:

• Agent-level attribution gate. On-chain inflows are credited to an agent only when the recipient is the agent's own payment endpoint — its advertised x402 payTo, its agent wallet, or its declared service address — and when a per-agent scanner has confirmed receipts to that address. Where the agent has no declared payment address different from its owner, it has no agent-level payment evidence. The owner-wallet treasury figure stays visible on the profile as operator treasury activity context, labeled so a reader can see it is the operator's aggregate, not the agent's.
• Payable sub-score and the evidence gate's real-usage branch now require agent-level attribution. The "realized on-chain payments" ladder rung (payable = 100) and the evidence gate's real-usage half both read from the attribution block instead of the raw total_* fields. Agents in the operator tier fall to the next rung (payable = 70 if they advertise x402, otherwise 0 with the specific "attributed to the owner wallet" reason). Reputation (per-agent in the per-agent reputation summary) is unchanged — that signal was already keyed on (chain, agent_id), never the owner.

A new free-tier readiness_demotion_reason slug — payment_inherited_from_owner — renders as "on-chain inflows are attributed to the owner wallet (shared across the operator's other agents), not to this agent's own payment address". The paid intel feed still includes the owner-level treasury numbers under a separate payment_attribution block, so a subscriber can see the full operator picture AND the per-agent attribution verdict in one response.

Before and after (live, post-rebucket)

Chain	Transact-ready before (after all earlier guardrails)	Transact-ready after (live, 2026-10-10)	Demotions due to attribution gate
Base	1,508	4	1,496 (99.2% of before)
Ethereum	188	0	186 (98.9% of before)
Total	1,696	4	1,682

Nearly the entire previous Transact-ready cohort was earning the badge on an inherited treasury line. The four Base agents that survive do so on independent per-agent evidence (one or more non-self reputation events plus a live endpoint); zero Ethereum agents clear the gate under the current signal set. The fourteen rows that led the October 9 trust audit (kontol, xfhdh ×4, gggd ×2, Elonmusk, Satoshi, R2d2, Openai, and so on) all drop out: not because of their names (the extended name gate already covered that) but because the single $507 USDC / 133 tx treasury line is now visibly the operator's, not theirs.

50-sample trust check on the new Transact-ready set

We repeated the October 9 check on the new Base group. It has four agents, so the sample is all four; the Ethereum group is empty, so the sample is zero. Each of the four has a live HTTPS endpoint returning 200, holds at least one non-self reputation feedback event, and comes from an owner wallet with a smaller or non-batch footprint on this chain. In our judgement a careful buyer would trust all four (4 of 4, 100%). With only four agents this is a spot check rather than a statistical result.

agentId	name	composite	non-self feedback	endpoint
45250	Clash Commerce	75	12	HTTPS 200
84122	HostDeFi Token Risk API	76	5	HTTPS 200
55000	Convert Guru File Conversion Agent	78	2	HTTPS 200
45991	My agent	75	1	HTTPS 200

Known limitations (attribution gate)

1. Per-agent payment checking is not live yet. Until it is, the gate treats payments as the operator's, because our payment check still looks at owner wallets. Agents that publish their own x402 payment address will start earning agent-level credit once per-agent checking is added. The gate's shape does not change; only the attribution tier of individual profiles will.
2. Reputation unchanged. Reputation feedback is per-agent in the per-agent reputation summary, so this release does not touch it. A further refinement to account for repeat reviewers across operators is planned; it is a separate change on the reputation signal, not on payment attribution.
3. Operator treasury context remains visible. Zeroing out agent-level attribution does not hide the operator wallet's activity. The free-tier agent page still shows the operator treasury line next to the agent profile, labeled as operator treasury activity. The paid feed exposes the full attribution block (payment_attribution.tx, payment_attribution.usdc, payment_attribution.eth, payment_attribution.attribution) so subscribers can distinguish operator-aggregate from agent-level.

Reproducibility (attribution gate)

The free-tier demotion reason is payment_inherited_from_owner. CC BY 4.0; cite as "Onchain Agent Intel, 2026-10-10".