Readiness Scoring Tightened: Batch Mints and Test-Shaped Names No Longer Reach Transact-Ready

What changed

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

Our October 9 scoring-quality memo walks a representative Normie #5694 through the formula: reachable endpoint + any inbound transfer + enriched_at within 30 days + null reputation (Ethereum feedback is not yet 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. For a product sold on trust, that was wrong.

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 are 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.

That change is blocked today 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 at the time of the scoring-quality audit), we just don't index it into our local store yet. Base + Ethereum feedback indexing is the sibling in-flight piece; once it lands, the top-tier gate will tighten again.

Update — October 9, 2026 (evidence gate)

The real-usage gate flagged above has shipped as a third guardrail 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	Rule-C demotions	% 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 stored buckets after the bulk re-bucket pass. Rule-C demotion counts and percentages reconcile with the pre-ship simulation to the agent; the "after" totals include a small amount of unrelated background enrichment churn between the simulation and the rebucket run.

Known limitations we're disclosing

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 tightening is a tracked follow-up.
2. The dust floor is a judgement, not a rigorous economic test. The thresholds (tx ≥ 3; USDC ≥ $1 or ETH ≥ 0.0005) came out of the scoring-quality audit. Expect a re-calibration after one week of live data.
3. Fail-open on offline writes. When discovery or re-enrichment writes a profile before the DB-aware pipeline has computed the non-self feedback count, the gate is skipped for that write and re-applied on the next render / bulk re-bucket pass. A profile cannot be silently flipped on partial data.

If you believe your agent belongs in Transact-ready

The fastest path is to receive a reputation feedback event signed on-chain by a client wallet — our indexer picks it up on the next tick and the ranking updates. The second path is to run three or more real transactions and clear the dust floor on either USDC or ETH; the activity tracker will see the new usage within one cycle.

Reproducibility

Scoring lives at smartcontractauditpro/readiness.py (build_readiness_score). The batch-publisher counts come from ~/.openclaw/erc8004_publisher_counts.json — written by the discovery pipeline's per-publisher dedup pass — and the publisher-key derivation is at publisher_dedup.publisher_key. The name-gate predicate (_name_looks_test) and the allowlist (TRANSACT_READY_NAME_ALLOWLIST) are both module-level and covered by tests at smartcontractauditpro/tests/test_readiness_score.py. Rule C lives in the same module as EVIDENCE_GATE_REASON and _profile_has_real_usage, with the non-self feedback count looked up by audit_tracker._non_self_feedback_count directly off the reputation_feedback table. The bulk re-bucket pass that lifts the stored buckets to agree with the gate is smartcontractauditpro/rescore_0913.py. The free readiness_demotion_reason field is on /v1/public/agent/{chain}/{agent_id} for every demoted profile. CC BY 4.0; cite as "Onchain Agent Intel, 2026-10-09".

Update — October 10, 2026 (Rules D and F)

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 Rule C independently.

Beginning October 10, 2026, two additional guardrails run on top of Rule C:

• 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 — name gate v2. 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. The wordlist lives in smartcontractauditpro/data/readiness_name_gate_v2.json so it can be audited and extended without a code change.

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 (post-Rule C)	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

"Dry-run" demotion counts are the pre-ship simulation against the live profiles store on 2026-10-09; the live "after" column is the stored buckets after the rebucket pass on 2026-10-10 and includes a small amount of unrelated background enrichment churn between the simulation and the rebucket run.

The helixa.xyz operator wallet (0x339559A2…) and the Surf DeFAI operator (0x820c5091…) 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 we're disclosing (Rules D & F)

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. The follow-up (Rule E, "operator-ring-only reputation") is tracked in docs/0898y-base-score-quality.md §3.
2. The wordlist in Rule F is live and open to review. The file sits at smartcontractauditpro/data/readiness_name_gate_v2.json. False positives should be filed as a GitHub issue or paid-tier "dispute" — the TRANSACT_READY_NAME_ALLOWLIST set in readiness.py 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 (Rules D & F)

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 matches a term in data/readiness_name_gate_v2.json; if the flag is a false positive, open a dispute and we'll whitelist it.

Reproducibility (Rules D & F)

Rules D and F live in the same module as OWNER_CAP_DEFAULT, apply_owner_cap, NAME_GATE_V2_REASON, and _name_fails_gate_v2. The Rule F wordlist (celebrity/brand, profanity, random-suffix patterns) is at smartcontractauditpro/data/readiness_name_gate_v2.json so it is auditable without a code change. The dry-run tool that reports before/after rebucket counts against the live profiles store is smartcontractauditpro/tools/dry_run_rule_df.py. 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 Rules D and F 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 helixa.xyz (one wallet, 213 Base registrations), Surf DeFAI (one wallet, 243 Base registrations), and every other batch publisher, 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 Rule C real-usage branch now require agent-level attribution. The "realized on-chain payments" ladder rung (payable = 100) and Rule C'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 reputation_agent_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 (post-Rules A–F)	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 (helixa kontol, xfhdh ×4, gggd ×2, Elonmusk, Satoshi, R2d2, Openai, and so on) all drop out: not because of their names (Rule F 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 re-ran the October 9 sample methodology against the new Base cohort. The cohort has four agents, so the sample is all four; the Ethereum cohort is empty, so the sample is zero. Each of the four Base agents 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. A careful buyer evaluating these four would trust 4 of 4 (100%). The task memo's target of "the large majority" is met in the strict sense, with the honest caveat that a sample of four is a floor, not a ceiling.

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 we're disclosing (attribution gate)

1. No per-agent scanner is live yet. The gate currently classifies every stored profile as operator-tier, because the activity tracker still queries owner wallets. The per-agent scanner (future task 0898ab) will query a declared payment address directly and flip agent_level_payments: true on qualifying profiles. Agents that advertise their own x402 payTo today will begin earning agent-level credit as that scanner rolls out. The gate's shape does not change; only the attribution tier of individual profiles will.
2. Reputation unchanged. Reputation feedback is per-agent in reputation_agent_summary, so this release does not touch it. The follow-up Rule E (operator-ring-only reputation, tracked in docs/0898y-base-score-quality.md) 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 gate lives in smartcontractauditpro/readiness.py as _resolve_agent_payment_address and _resolve_payment_attribution. The bulk re-bucket pass is smartcontractauditpro/rescore_0898aa.py. The free-tier demotion slug payment_inherited_from_owner ships in DEMOTION_SLUG_PAYMENT_INHERITED. CC BY 4.0; cite as "Onchain Agent Intel, 2026-10-10".