Something bought the same endpoint 827 times, and we were shipping it junk

Everything below came from Base chain data, from our own request logs, or from re-running real traffic through our own code. Nothing is modelled or estimated.

Something bought the same endpoint 827 times

One wallet, three consecutive days, one endpoint, a cent a call.

Block timestamps were checked against two sampled blocks at zero drift, so those windows are exact.

It is batch-shaped, not continuous. It bursts for twenty to forty-five minutes, then sleeps for sixteen to twenty-four hours. Watching a balance in real time is misleading: a quiet hour looks like a lost customer and is actually a finished list.

Today's run ended at 08:26 with $1.00 still in the wallet — about a hundred more calls they chose not to make. Stopping on a round number with funds left reads more like a finished list or a reserve floor than an exhausted balance, though we cannot tell which from the outside. Whether that dollar becomes more is what we are watching now, and it is the difference between a customer and a very good three-day job.

The four calls on 2 October are the most informative row in the table. They were not a batch. They were a few one-off requests against an example domain, someone checking by hand that the thing still worked, who then came back the next morning and ran a bigger job. That is a person integrating an API on purpose, and it is the opposite of the sweep traffic we spent September learning to recognise.

We are not publishing what they asked for. Their payments are on a public chain and anyone can count them. What they requested exists only in our logs, and it is theirs.

We counted the money and never checked the goods

827 payments looked like a working product. So we took 45 of the URLs actually requested and ran them back through our own live code.

Roughly seven in ten paid calls returned nothing usable.

The 56% is not a lie. We checked twelve of those sites by hand, following the contact page, the about page, and every contact link present. The information genuinely is not published. "Nothing found" was a true answer.

But it was indistinguishable from failure, and that is the real defect. The buyer could not tell "this business publishes no address" from "we could not reach it." Both arrived as empty arrays.

We sold addresses that were never real

Worse than empty. About 9% of responses contained contacts that do not exist: placeholder addresses lifted out of sample code, an error-tracking address, and the Meta tracking pixel URL reported as a business's Facebook page.

The scraper was reading template text and handing it over as a lead. On one well-known site, four of the five emails we returned were documentation examples.

The pixel one is the most embarrassing, because that URL sits on a large share of all commercial websites. Any site running Facebook ads could have got it.

Both are now filtered. Reserved placeholder domains are dropped, and a social link that turns out to be a share widget or a tracking endpoint returns nothing rather than something false. Returning nothing is the honest answer. Returning a plausible wrong one is the expensive answer.

Every trust verdict we issued was missing its main signal

This is the one that matters most.

Our domain-age lookup ended with a line that returned null whenever the request failed, under a comment describing that as resilient. It had been failing on every single request. The registry redirect we use lands on the authoritative registry, and that registry returns 403 to any request with no User-Agent, which is exactly what Node sends by default. The error was swallowed, so domain age was null for every domain we have ever assessed.

Meanwhile the verdicts kept coming out confident. By our own code comment, a brand-new domain is the single strongest counterparty scam signal there is.

We were calling a six-week-old site safe. The fix is one HTTP header.

It went unnoticed for two reasons. The old, legitimate domain scored correctly by accident. And our 22-endpoint health check only asserts that a response is a 200 with a non-empty body. A fabricated email satisfies that. So does a null domain age. A check that cannot fail is not a check.

"Nothing found" can be made into a real answer

One free DNS lookup turns the empty result into two honest findings instead of a shrug. Of twelve domains that returned no contacts, four have no mail server at all and cannot receive email, which is a definitive finding about that business rather than a failure of ours. The other eight have a working mailbox but publish no address anywhere, which is also useful: the lead is reachable, just not by scraping.

Tested, not yet shipped. It changes the response, and the one customer we have is running right now.

The market grew 17% in two days

The first real comparison out of our own dated snapshots. This is the thing nobody can backfill, and two days ago we did not have it either.

Endpoints up seventeen percent. Payers up seven thousand. And calls down a hundred thousand.

Those move in opposite directions because the marketplace reports a rolling thirty-day window. Listing requires a settled payment, so thousands of new endpoints each manufacture one payment and one payer, which lifts payers without lifting usage, while whatever drove a hundred thousand calls a month ago has aged out of the window and been forgotten. Two new sellers arrived with 52 and 33 endpoints on their first day.

What changed today

• Placeholder and tracking-pixel contacts filtered out
• Domain-age lookup fixed, and five trust endpoints get their main signal back
• Per-call delivery telemetry built, so every paid call now records whether the buyer actually received anything, separating a true negative from a non-delivery
• The snapshot recorder is installed and permanent, no longer dependent on anyone remembering to run it
• A concurrency bug found in that recorder the honest way: two runs recorded the same day at once and both passed the "already recorded?" check before either wrote

Open

• None of the above is deployed. The customer's batch is running, and we are not going to experiment on the machine that is currently paying us.
• The health check needs to assert that data is plausible, not merely present. It is what let both of today's defects run.

Recorded automatically, read by a human before publishing.