Repository navigation
25,000 dollars does not move USDC, so the depth rung measured the fee curve again - #2781
Merged
Merged
Conversation
…again First readings off the deployed probe: every one of the eight bridges kept falling at $25,000. That is not eight providers ignoring depth, it is USDC on Base, Arbitrum and Solana being deep enough that $25k does not touch it. The rung works; it was asking a question these corridors answer trivially. Half a million is where a stablecoin route starts to answer honestly, and a provider that declines the size has told us something too. It costs the providers nothing extra, because it replaces the $50 rung rather than joining it. The ladder already runs 5,760 quotes per provider per day and a fifth rung would add 1,440 to each, which is how a free key gets revoked. It does not need one: below the depth point a bridge's cost is a fixed fee plus a proportional one, cost% = F/amount + V, so two points determine the curve and a third on it measures nothing. Fitting F and V on $5 and $300 predicts the live $50 reading to a median of 0.3% across all eight bridges, worst case 13.7% on squid. That rung was interpolation. The ladder is now $5 and $300 for the fee curve, $25,000 and $500,000 for depth: same number of quotes, two depth points instead of one, and a turning point visible between them. A test pins the budget at four rungs per route, so the next person who wants a reading has to decide what to spend rather than quietly adding load to eight third-party APIs.
Deploying main put two benches into noindex within the hour. Their asOf read
1970, and /products/mobula, /relay, /lifi and /near-intents all started
failing the links-to-noindex check because they point at them.
The cause was not the deploy. bridge-execution-latency.yml and
bridge-realized-cost.yml both declare
freshness_timestamp_metric: bridge_last_execution_timestamp_seconds
and nothing in main's harness has emitted that for weeks. Prometheus held 2,835
samples of it over the last day, scraped from the container, because production
was still running a binary built before release 1bff8c7, which took "main's
versions" of the harness while benches 261 and 263 were gated to dev. The
benches later came off the gate; the harness never caught up. Main and
production had diverged, and the only thing holding the freshness source up was
an image nobody had rebuilt.
Restored from 73265b0: last_execution.go, the gauge, and the three attachment
points. The file's own header describes the failure exactly, that a pulse gauge
cannot be a freshness source because it is gone between runs, and the execution
cycle is daily, so without the persisted copy any restart blanks it for up to
twenty-four hours.
The expose-at-start call matters more than it looks. Without it the store is
written and never read back: the file grows, the gauge stays empty, and the
mechanism appears present while doing nothing.
Two tests. One restarts the store in a temp dir and asserts the gauge comes
back carrying the persisted time. The other asserts an empty store publishes
no series at all, because a zero unix time reads as 1970 and that is precisely
how the site concluded both benches were infinitely stale.
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.
First readings off the probe deployed an hour ago: every one of the eight bridges kept falling at $25,000.
That is not eight providers ignoring depth. It is USDC on Base, Arbitrum and Solana being deep enough that $25k does not touch it. The rung works; it was asking a question these corridors answer trivially.
$500,000 is where a stablecoin route starts to answer honestly, and a provider that declines the size has told us something too.
It costs the providers nothing
The ladder already runs 5,760 quotes per provider per day. A fifth rung would add 1,440 to each, which is the sort of thing that gets a free key revoked.
It does not need one. Below the depth point cost is a fixed fee plus a proportional one,
cost% = F/amount + V, so two points determine the curve and a third on it measures nothing. Fitting F and V on $5 and $300 predicts the live $50 reading:Median 0.3%. That rung was interpolation, so it is what the depth reading is paid for.
The ladder becomes $5 and $300 for the fee curve, $25,000 and $500,000 for depth: same number of quotes, two depth points instead of one, a turning point visible between them.
A test pins the budget at four rungs per route, so the next person who wants a reading has to decide what to spend rather than quietly adding load to eight third-party APIs.
Already visible on the first rung
Per route, the signal is there where the corridor is thinner:
go build,go vet,go testclean.main.gountouched: the execution ladder still tops out at $30 of real money.