Repository navigation
invert the schedule instead of hiding the row - #3151
Merged
Merged
Conversation
pump's EVM rows were held because the router's spend is already net of what
pump keeps, so their loss sat on a smaller base than every other row on the
same chain tab, FOMO included, whose bridge take IS counted. Holding published
nothing false but left the product with no number on six chains.
The gross is recoverable without pairing anything. The schedule inverts:
spend = gross - (0.05 + r*gross) -> gross = (spend + 0.05) / (1 - r)
r is 40 or 45 bps and which one a swap paid is only readable when its size
lands on a round level, which 7 of 40 do. The two rates sit 5 bps apart while
the deduction runs 45 to 545 bps, so the midpoint leaves a residual of 2.51 bps,
symmetric, against 45 to 545 one-signed from ignoring it. Scored on all seven
spends whose real amount is known.
Checked first whether the gross was simply in the transaction: it is not. Only
4 of 40 swaps see a stable arrive at the router and none is a round amount, so
it is pre-funded out of pump's own liquidity.
The terminal component needs no separate handling: it is the residual after
pool and other, so raising given moves exactly the deduction into it.
Four tests, including that the correction beats doing nothing on every fixture,
that it touches no other product, and that it never implies a take outside the
schedule, which would be the same lie mirrored.
The schedule was measured and the gross-up read a constant beside it: every published pump swap was multiplied by a hand-written 0.00425. Two costs. The mix already differs by chain, BNB leaning 45 bps (14 against 9) and Robinhood Chain leaning 40 (40 against 8), so one constant everywhere adds up to 1.7 bps on Robinhood. And if pump moved to a third rate the exact matches would stop and the counter would show it while the gross-up went on applying 42.5 bps in silence. The watcher now tallies, per chain, the rates it matched exactly, and the gross-up weights by that tally. Only an exact read-back votes: an ordinary trade size cannot move the rate, or the measurement becomes an average of noise. The typed midpoint survives as the fallback for a chain with fewer than five matches and is named as such. Six tests, including that a chain showing only 40 bps is grossed at 40 and not at the fallback, that two chains with different evidence do not converge, and that unmatched spends leave the rate alone.
pump.fun published a Pump Bridge against Relay comparison on 2026-10-21 and invited anyone to check it. Its headline reproduces exactly on its own rows: almost 13x fewer buy errors, 0.869% against 11.214%. The export also carries sells. There the bridge errors at 7.378% against Relay's 10.511%, so over both directions the ratio is 2.95x, not 12.90x. The bridge fails 8.5 times more often on a sell than on a buy, nearly all of it bridge_execute_failed. The 20 MB export reduces to 58 counts, 2.5 KB, lossless for any rate by chain, lane, direction or error class, with the SHA256 of the original in its header. It is embedded so both figures can be recomputed from this repository rather than taken on trust, and the tests fail if the digest is ever edited. The gauges say in their help text that this is a vendor's own dataset over a window that ended on 2026-10-07 and not a measurement of ours, because a gauge on a dashboard otherwise reads as live. Loaded once at startup for the same reason: a ticker would suggest the numbers move. One thing the thread about this did not mention, asserted by a test: the arms are matched to 0.6% on buys but the bridge carries 77,593 sells against Relay's 133,474, so the directions are not equally weighted either.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pump's EVM rows were held because the router's spend is already net of what pump keeps, so their loss sat on a smaller base than every other row on the same chain tab, FOMO included, whose bridge take IS counted. Holding published nothing false but left the product with no number on six chains.
The gross does not need pairing
The schedule inverts:
ris 40 or 45 bps. Which one a swap paid is only readable when its size lands on a round level, which 7 of 40 do. The two rates sit 5 bps apart while the deduction runs 45 to 545 bps, so the midpoint is enough:Symmetric, so it favours nobody; ignoring the deduction is one-signed.
Checked the simpler explanation first
Whether the gross is simply in the transaction: it is not. Only 4 of 40 swaps see a stable arrive at the router and none is a round amount. The router is pre-funded out of pump's own liquidity, which is why its input is not on this chain.
Why no separate fee handling
The terminal component is computed as
given - pool - other, so raisinggivenmoves exactly the deduction into it.Tests
Four, including that the correction beats doing nothing on every fixture, that it touches no other product (inflating a competitor's cost is the same lie mirrored), and that it never implies a take outside the schedule.
The assumption stated in the spec: that the deduction applies to every router spend. The 7 exact matches support it, including on swaps not sent by pump's relayer. It is not proven for the other 33.