Skip to content

award the first past the single-participant return, and correct the pool figure - #2812

Merged
Flotapponnier merged 1 commit into
mainfrom
fix/firsts-past-single-participant
Oct 4, 2026
Merged

Flotapponnier merged 1 commit into
mainfrom
fix/firsts-past-single-participant

Conversation

@Flotapponnier

Copy link
Copy Markdown
Collaborator

Two debts from #2809, now that #2811's counters can measure instead of infer.

The latent miscount

headLagFirst was incremented inside the winners loop, which runs before the providers < 2 return. A trade one feed alone reported therefore handed that feed a first while never entering the race count or the share history: a numerator moving without its denominator, the same defect that published OKX at 95.93% on Solana, and it survived the first fix.

The lag recording stays inside the loop on purpose, since single-feed lags are deliberately kept and only the race is unscored. single_participant now also reaches the voided counter, which it did not before, and race_test.go gains the case.

The number I published in #2809

The bullet said roughly 1,200 trades on the Solana bench pool, read from head_lag_ref_matches_total{outcome="matched"} alone. That counter has a third outcome, ahead_of_reference, where every feed faster than the pool subscription lands on Solana.

What the new counters say directly:

solana bnb base
pool observed 465/h 2,903/h 269/h
races scored 254/h 2,806/h 316/h
voided off_pool 576,530/h 14,893/h 11,707/h

So the filter does bite, hard, and Solana is back inside the 100-900 races/h it ran before the token-scoped feeds arrived (measured with offset). The 25,070/h I reported right after deploying #2809 was a rate() window straddling the container restart: the artefact I warned about in that same PR and then read anyway.

The shares now agree with the latency column

Which is the check that found the bug in the first place:

chain
base mobula 71.37% serialized 23.50% okx 5.13%
bnb mobula 60.54% serialized 35.70% okx 0.29%
solana serialized 81.03% mobula 54.61% okx 0.00%

Solana p50 for the same window: serialized 3 ms, mobula 8 ms, codex 98 ms, okx 249 ms, birdeye 678 ms, geckoterminal 8.1 s. Shares exceed 100% because a tie within 5 ms counts as first for each feed involved, which is documented.

Shares are computed over an in-memory 24 h window that reset at the redeploy, so they will firm up over the next day.

Gates

go build ./..., the full go test ./cmd/script/ suite, pnpm validate (235 specs valid). The corrected bullet went over the 500 character cap on the first attempt and was shortened.

🤖 Generated with Claude Code

…ool figure

Two debts from #2809, now that #2811's counters can measure instead of infer.

headLagFirst was incremented inside the winners loop, which runs BEFORE the
providers < 2 return. A trade one feed alone reported therefore handed that
feed a first while never entering the race count or the share history: a
numerator moving without its denominator, the same defect that published OKX
at 95.93% on Solana, and it survived the first fix. The lag recording stays
inside the loop on purpose, since single-feed lags are deliberately kept and
only the race is unscored.

race_test.go gains the case. single_participant now also reaches the voided
counter, which it did not before.

And the number I published in #2809 is corrected. The bullet said roughly
1,200 trades on the Solana bench pool, read from
head_lag_ref_matches_total{outcome="matched"} alone. That counter has a third
outcome, ahead_of_reference, where every feed faster than the pool
subscription lands on Solana. What the new counters say directly:

  pool observed       solana 465/h    bnb 2,903/h   base 269/h
  races scored        solana 254/h    bnb 2,806/h   base 316/h
  voided off_pool     solana 576,530/h  bnb 14,893/h  base 11,707/h

So the filter does bite, hard, and Solana is back inside the 100 to 900
races an hour it ran before the token-scoped feeds arrived. The 25,070/h I
reported after deploying #2809 was a rate() window straddling the container
restart, which is the artefact I had warned about in that same PR and then
read anyway.

The shares now agree with the latency column, which is the check that found
the bug:

  base    mobula 71.37%  serialized 23.50%  okx 5.13%
  bnb     mobula 60.54%  serialized 35.70%  codex 10.36%  okx 0.29%
  solana  serialized 81.03%  mobula 54.61%  okx 0.00%

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@Flotapponnier
Flotapponnier merged commit 882f177 into main Oct 4, 2026
2 checks passed
Flotapponnier added a commit that referenced this pull request Oct 4, 2026
Carries #2811 and #2812 across: the three diagnostic counters, the first
awarded past the single-participant return, and the corrected pool figure in
the methodology. The worker clones dev at BUILD time, so the bullet only
reaches the page from here.

Verified on dev's base: go build ./..., the full go test ./cmd/script/ suite,
and pnpm validate (235 specs valid).

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Flotapponnier added a commit that referenced this pull request Oct 5, 2026
It said Solana scores 254 races an hour. Five consecutive 15-minute windows
read 203, 25, 46, 37 and 186, so 254 was one sample of something that swings
by a factor of eight. A race needs two feeds to report the same pool trade,
which is a sparse coincidence, so the jitter is the quantity's nature rather
than a fault.

Replaced with the order of magnitude and the comparison that actually
carries the claim: it is back to the rate it ran at before the token-scoped
feeds arrived.

Two numbers from the #2809 commit message and PR body are also wrong, and
recorded here since they are not in published copy and cannot be edited
there:

  "Mobula was first on 85 of the 109 pool trades it reported, about 78%"
  used the matched-only denominator, which omits ahead_of_reference. On the
  actual races the figure is 114 of 415, about 27.5%, which is what the page
  publishes and what the fix was always about: it was 0.08%.

  "~1,200 trades on the bench pool" came from the same mistake and was
  already corrected in #2812.

The defect and the fix are unaffected: OKX took 5 firsts in 415 Solana races
after the filter, against 75,151 an hour before it.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant