Skip to content

Near Intents could not score below 15 seconds however fast it settled - #2774

Merged
Flotapponnier merged 1 commit into
mainfrom
fix/bridge-poll-parity
Oct 2, 2026
Merged

Flotapponnier merged 1 commit into
mainfrom
fix/bridge-poll-parity

Conversation

@Flotapponnier

Copy link
Copy Markdown
Collaborator

The bench publishes 36.7 s p50 for Near Intents against 1.0 to 1.5 s for LI.FI, Mobula and Relay. Most of that gap is ours.

Two defects, both in how we poll for settlement

Near Intents slept before its first check.

// Near Intents                     // the other three
for ... {                           for ... {
    time.Sleep(15s)   // ← first        status := getStatus()  // ← first
    st := Status()                      if terminal { return }
}                                       time.Sleep(5s)
                                    }

The other three catch an already-landed settlement on the immediate call, costing only an HTTP round trip — which is why they read near one second. Near Intents had a floor of one whole interval under every measurement: instant settlement still recorded 15 s.

And the interval differed, 15 s against 5 s, so past that floor its measurements quantised three times coarser. A p50 of 36.7 s means "seen on the second or third poll", not "took 36.7 s". The true figure is somewhere between 15 and 36 s and this instrument cannot say where.

The fix

All four share one settlePollInterval and all four check before sleeping. The constant is 1 s rather than 5 s: the first check is immediate for everyone, so the interval only bounds the error on settlements slower than a round trip. At ~90 executions per bridge per month the extra status calls are a rounding error against any provider's rate limit.

A test pins both properties — shared cadence, and an interval no coarser than the ~1 s the fastest bridges settle in — because this is exactly the asymmetry that reappears the next time one bridge needs special handling.

Context

Aurora's Alex Shevchenko has publicly contested benchmarks that misrepresent Near Intents. On this number he would have been right: we published a figure making a named provider look 25× slower than its competitors, and the measurement was at fault.

The other Near Intents figures hold up and are worth noting: 12.07 bps realised fee, the best of the four (LI.FI 63.4, Relay 77.4, Mobula 12.7).

The 7-day window takes a week to clear after deploy, so the published figure will converge rather than jump.

go build, go vet, go test all clean.

The bench publishes 36.7 s p50 for Near Intents against 1.0 to 1.5 s for
LI.FI, Mobula and Relay. Most of that gap is ours, not the bridge's.

Two defects, both in how we poll for settlement.

Near Intents slept BEFORE its first status check. The other three check
first and sleep after, so a settlement that has already landed is caught on
the immediate call and costs only an HTTP round trip, which is why they read
near one second. Near Intents had a floor of one whole interval under every
measurement: instant settlement still recorded 15 s.

And the interval differed, 15 s against 5 s, so past that floor its
measurements quantised three times coarser. A p50 of 36.7 s means "seen on
the second or third poll", not "took 36.7 s"; the true figure is somewhere
between 15 and 36 s and this instrument cannot say where.

All four now share one constant and all four check before sleeping. The
constant is 1 s rather than 5 s: the first check is immediate for everyone,
so the interval only bounds the error on settlements slower than a round
trip, and at roughly 90 executions per bridge per month the extra status
calls are a rounding error against any provider's rate limit.

A test pins both properties, because this is the kind of asymmetry that
reappears the next time one bridge needs special handling.

Worth saying plainly: we published a number that made a named provider look
twenty-five times slower than its competitors, and the measurement was at
fault. The 7-day window will take a week to clear once this is deployed.
@Flotapponnier
Flotapponnier merged commit 2af4e6a into main Oct 2, 2026
2 checks passed
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