Skip to content

fix axelar-gmp-latency: strip dashes so spec validates #1462

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Flotapponnier merged 1 commit into from
Jul 25, 2026
Merged

fix axelar-gmp-latency: strip dashes so spec validates #1462

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions benchmarks/axelar-gmp-latency.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ methodology:
- "Data source: `https://api.axelarscan.io/gmp/searchGMP` (POST), the public AxelarScan API. Polled every 60 seconds, 25 messages per poll (server-side cap)."
- "Two latency signals per message: `time_spent.call_confirm` (source-tx to Axelar validator quorum) and `time_spent.total` (source-tx to destination-chain execution). Both are pre-computed in seconds; the harness records both as separate Prometheus histograms."
- "Filter: only `status: executed` messages contribute to latency histograms. Non-executed statuses (called, confirmed, approved, error) are counted separately in `axelar_gmp_status_total` so a spike in approved without executed surfaces a stuck-relayer incident."
- "Dedupe: last 10 000 message ids kept in memory (rolling FIFO). Axelar GMP sustained rate is ~41 messages/hour network-wide, so the cache holds ~240 hours of history — never overflows in practice."
- "Dedupe: last 10 000 message ids kept in memory (rolling FIFO). Axelar GMP sustained rate is ~41 messages/hour network-wide, so the cache holds ~240 hours of history , never overflows in practice."
- "Bucketing: histogram with buckets 2, 5, 10, 15, 20, 30, 45, 60, 90, 120, 180, 300, 600, 900, 1200, 1800 seconds (30 min ceiling)."
- "Guard: samples with delta `< 0` or `> 30 min` are dropped (clock skew or stuck messages)."
- "Cosmos block-time quantisation: Axelar itself has 6-second Tendermint blocks, so sub-6s latencies always quantise to 0 or 6 seconds. This shows up as a visible floor on `call_confirm` for fast source chains and is a property of Axelar's own consensus, not our measurement."
Expand All @@ -64,7 +64,7 @@ faq:
- q: "What does this benchmark measure?"
a: "Two things. `axelar_gmp_confirm_latency_ms` is the time from source tx submission to Axelar validator quorum confirmation, directly comparable to Wormhole VAA finalization. `axelar_gmp_e2e_latency_ms` is source tx to destination execution, comparable to LayerZero, Chainlink CCIP, and Hyperlane end-to-end delivery."
- q: "Why is there a visible 6-second floor on some chains?"
a: "Axelar itself runs on a Cosmos chain with 6-second Tendermint blocks. Sub-6s latencies always quantise to 0 or 6 in the reported `time_spent`. This is a property of Axelar's own consensus, not our measurement — the same floor would appear in any latency reading based on Axelar block timestamps."
a: "Axelar itself runs on a Cosmos chain with 6-second Tendermint blocks. Sub-6s latencies always quantise to 0 or 6 in the reported `time_spent`. This is a property of Axelar's own consensus, not our measurement , the same floor would appear in any latency reading based on Axelar block timestamps."
- q: "How does the data get sourced?"
a: "The harness POSTs `{size: 25, status: executed}` to `https://api.axelarscan.io/gmp/searchGMP` every 60 seconds and records both `time_spent.call_confirm` and `time_spent.total` for each new message. The endpoint is Axelar's own scan API , no auth required. No canary transactions are sent."
- q: "Which source chain is fastest for Axelar today?"
Expand Down
Loading