From 0d0a28acbcf4770d6a65d6419da946a4eceea7d0 Mon Sep 17 00:00:00 2001 From: Florent Tapponnier Date: Sun, 26 Jul 2026 01:59:24 +0200 Subject: [PATCH] fix axelar-gmp-latency spec: strip em/en dashes --- benchmarks/axelar-gmp-latency.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/benchmarks/axelar-gmp-latency.yml b/benchmarks/axelar-gmp-latency.yml index f6215b6f..a0327187 100644 --- a/benchmarks/axelar-gmp-latency.yml +++ b/benchmarks/axelar-gmp-latency.yml @@ -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." @@ -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?"