The Week's Ledger — 2026-W36

Gap — ours

We knocked on 1,088 of the 6,367 hosts every directory we read named this week — 17.1%.

Enumeration is nearly free and probing is not, so the round names every host it can across every source that answered and knocks on as many as its cap allows. The 5,279 unknocked hosts are not dead and are not healthy: they are unmeasured, and no figure on this page is taken over them. Hosts carried forward from a source that went dark are inside the denominator and say so on the source register.

Derived from population.population_walked, population.population_known

Gap — ours

1 named door was never knocked on this week.

Ours, not theirs. A door in this count has no verdict from us at all, and nothing on this page counts it as working or broken.

Derived from our_gaps.not_probed

Gap — ours

The round flagged its own coverage as suspect this week.

A feed answered with a full page and no recognisable cursor, so the round cannot tell a short list from a truncated one. Every count on this page should be read as a floor.

Derived from our_gaps.coverage_suspect

Gap — ours

1 source is not answering: discovery.

Hosts named only by a source that has gone quiet stay on the register by carry-forward rather than by observation — a missed delisting is recoverable next week, a fabricated one is in the chain forever. The full register says when each last answered.

Derived from sources[].status, sources[].last_successful_read

Correction · 2026-09-04

The x402 walk ledger carried one key, `authorization_or_tx_id`, whose own documentation read "the authorization nonce or settlement tx". Nothing in a row said which of the two a value was, and the two are opposite in what they permit: an EIP-3009 nonce is client-generated random bytes no node will ever answer to, a settlement hash is addressable by anyone with an RPC endpoint. Same shape on the page. On 2026-09-03 the store then published row 1's value into a public cross-check on issue #188 as "Transaction: 0x3e366c96…f794090 on Base mainnet" — a sentence the ledger's own schema never supported. It is the authorization nonce; `buildAuthorization` in scripts/lib/walkabout.mjs mints it as 0x + randomBytes(32) before the payment is signed, and the walker keeps the settlement hash in a separate field it reads off the PAYMENT-RESPONSE receipt. The ledger collapsed two distinct captured fields into one key and prose resolved the ambiguity in the wrong direction, in public, in the exact artifact whose selling point is that a reader can check it. The class was already ours: `nonce-unbound-from-settlement` has been in this store's public defect vocabulary since 2026-08-27 — marks the nonce spent without naming what spent it, sourced by SolomonisBlack — with the repair hint 'store the settlement transaction hash beside the nonce'. We wrote it, aimed it at other people's tills, and failed it on our own record.

The union key from the ledger's publication on 2026-09-02 to 2026-09-04, across all seven rows. The mislabel built on it was live for one day, 2026-09-03 to 2026-09-04, on a public issue thread, and was the first thing an outside instrument tried to use.

Correction · 2026-09-04

The weekly walk published not_ready verdicts against doors that were payable, because two of its checks read every chain as if it were Ethereum or Solana. payto-payable resolved any unrecognised CAIP-2 namespace to the EVM branch: an XRPL classic address is base58 in a band that sits inside the Solana window, so a correct XRPL payTo was reported as "a base58 Solana address ... no buyer on this rail can pay this offer", and Stellar and Algorand addresses, being base32, matched nothing and were reported as neither an address nor a name service. amount-atomic applied the USDC atomic-units rule to XRPL issued currencies, which the ledger itself denominates in decimals, and told those doors that "0.01" underprices by a factor of a million. In round 2026-W36, 63 of 1,089 hosts walked failed payto-payable and 56 failed amount-atomic; every one of those 56 also offered a chain the desk could not read. The verdicts were signed and published against named hosts.

One published round. The three checks were promoted from advisories into the v2 verdict on 2026-08-30. Round 2026-W35, walked 2026-08-24, carried zero such failures; round 2026-W36, walked 2026-09-01, carried 65, of which 61 hosts had read ready the week before. Before the promotion the same misreads existed but rode as advisories, visible and not verdict-changing. For the week the verdicts stood, the affected hosts’ passport pages showed not_ready and their README chips refused to render, since the chip publishes names only on the ready side. Round W36 stays in the chain as walked; the corrected instrument publishes fresh rows on the next walk beside it.

Correction · 2026-09-04

The MCP door took a buyer's arguments, validated the arguments of a handful of items, and carried a short list of fields into fulfillment. Every other field an item needs to know what it is being asked about — `url`, `address`, `tx_hash`, `tx_hashes`, `wallet`, `digest`, `mandate` and the rest — was read off the wire and dropped before the goods were made. Three shapes came out of that one defect. good_buyer and launch_check each produced and SETTLED a signed artifact about the empty string: at $0.99 and $5.00 respectively, both on 2026-09-04: each probed "", folded the unreachable result into a signed reading exactly as they are built to do, and took the money — so the buyer holds two real, correctly signed observations about no endpoint on earth. attestation_bundle minted a certificate over an empty sheaf, settled, and then threw on its way out, leaving money moved, a certificate issued and a 500 in the buyer's hand, recoverable only via /trust if they knew to look. passport_refresh and provenance_check threw before the settle, so those cost nothing — the deliver-first rule holding — but answered a paying customer with an error page roughly half the time. The HTTP door was never affected: it had the whole map and the whole set of refusals.

From the day the MCP buy shelves opened until 2026-09-04. No purchase over MCP of any affected item was ever correct, and the store cannot say how many there were beyond the first buyer's, because the argument that would have identified the subject is the argument that was dropped. Making the buyer whole for the two settled artifacts is the keeper's hand, not this fix's.

Correction · 2026-09-04

Every conversion figure on /pulse and /stats was computed against an organic ask count that subtracted only the machines that named themselves. The census had computed the other kind since July — clients that touch four or more doors inside a minute are walking the catalog whatever their user-agent says — and published them on the office wall as undeclared_walkers, a report and not a correction. So September's standing correction removed 2 rows of 7,017; August's per-door visits sat between 70 and 101 for a half-cent blessing and a $25 collaboration alike; and 48,566 all-time asks stood against 97 wallets ever opened, a ratio that held at a quarter of a percent across months whose volumes differed sevenfold. The published corrected figures were ceilings and said so, but they were far higher ceilings than the store already knew how to draw.

From the day the standing correction shipped (2026-09-02) until today, and in spirit from the day the census first listed undeclared walkers (2026-07-26) — the rule existed, the books did not use it.

Correction · 2026-09-03

The organic 402 count per item on /pulse and the books could drop increments under a burst of price-checks against one door. Every other hot counter had been spread over shards on 2026-08-27; the per-item challenge counter stayed one KV key per item, KV allows one write a second per key, and a write that outlived its retries was logged and dropped. The counts were presented as counts and were, under bursts, floors of unknown depth.

From the day the meter went in until 2026-09-03, on any door polled faster than once a second — which the uptime monitors do. How many increments were lost is not recoverable: a dropped write leaves no row.

Correction · 2026-09-03

The attestation spec page said, since 2026-08-20, that the draft-vauban-x402 family covered receipt-format negotiation, a claim algebra and delegation binding, and that this store's signature_jcs "already verifies under" the RFC 8785 discipline those drafts and draft-hopley-x402-canonicalisation-jcs-v1 pin. The first was stale: the consolidated draft defers the claim algebra, the lifecycle FSM and the delegation binding to companion documents with no normative content. The second was overstated: both draft families add pre-canonicalisation rules our artifacts do not meet (integer-millisecond timestamps only, NFC strings; our artifacts carry ISO 8601 dates, the spec's own test vector included), and neither assigns any verification role to an ed25519 signature. signature_jcs verifies under the raw RFC 8785 byte primitive, not under either draft's discipline.

2026-08-20 to 2026-09-03, on the spec page every verifier is pointed at. No artifact was affected: the signatures were and are what the page's canonical-form section says they are. What was wrong was the claim of interoperability with drafts that would reject our preimages.

Correction · 2026-09-01

The public bounty board listed five doors as open that had expired unclaimed on 2026-08-27. A bounty's stored status is written at two moments — 'open' at posting, 'paid' at claim — and nothing ever wrote 'expired', so the board and its JSON repeated the stored word while the claim door, which checks the clock, would have refused every one of them. A shopper who read /bounties on any of those five days, paid one of the doors with their own wallet and claimed, would have lost the door's price and been told the bounty had expired. The room and the JSON also carried no count, so nothing on the front could say whether there was anything to walk.

Five days, 2026-08-27 through 2026-09-01, the whole span between the first board's expiry and its next read. No claim was attempted in that window, which is the only reason nobody was refused.

Correction · 2026-09-01

The $5 Once-Over cited preflight-v1 as its headline battery while the weekly census had applied preflight-v2 since 2026-08-24. Same GET, same bytes, different headline: a door with a dollar-typed amount (or any other v2-only fold) could buy a signed ready the same week the corpus called it not_ready. The paid report already computed the v2 score and hid it in also_under as DISAGREED — so the contradiction was visible inside the artifact and still published as ready on the face a buyer hands to a stranger. Same class as 0.14: the check existed; the flagship record did not consume it.

From the Once-Over's listing through 2026-09-01. Every report signed before this date still cites preflight-v1 and keeps that citation forever; we do not resign old artifacts.

Correction · 2026-08-31

The skill bundle published to ClawHub — the copy that gets INSTALLED into somebody else's agent — priced `service_audit` at $0.10 when it has cost $5 the whole time that document has existed, and `trust_profile` at $19 after the keeper repriced it to $21. It also described the shelf as running '$0.005 to $50' when it runs $0.001 to $300, and its frontmatter advertised entry 'from $0.004' when the cheapest door is $0.001. Two failures with different shapes and the second is the worse one. The `service_audit` price was wrong in the bundle's FIRST COMMIT: nothing ever compared it to the shelf, so it was never right. The `trust_profile` price was correct when written and went stale two days later when the keeper's 2026-08-29 repricing reached the shelf, the room and the JSON, and not the bundle. A wrong price here fails silently in the worst direction: an agent budgets a tenth of what the 402 will ask, declines the purchase it meant to make, and concludes this store is unaffordable. We would never hear about it, and we cannot edit the copy already installed.

`service_audit`: four days, 2026-08-27 to 2026-08-31, the entire life of the document. `trust_profile`: two days, from the 2026-08-29 repricing. Neither was found by anyone using them.