diff --git a/benchmarks/aggregator-head-lag.yml b/benchmarks/aggregator-head-lag.yml index 1bd834f6e..f9534e6af 100644 --- a/benchmarks/aggregator-head-lag.yml +++ b/benchmarks/aggregator-head-lag.yml @@ -1,4 +1,4 @@ -# OpenChainBench — Bench № 001 +# OpenChainBench. Bench № 001 slug: aggregator-head-lag number: "001" @@ -23,7 +23,7 @@ methodology: - "Regions: us-east, eu-west, sgp. Cross-region median reported in the headline." - "Reference: archive nodes per chain, validated against block hashes." - "Metric: gauge `head_lag_seconds`, sampled every 15 seconds. Aggregated over the 24-hour window using `quantile_over_time`." - - "Success rate: presence ratio — share of expected sampling slots where a value was actually emitted (5,760 expected per provider per day at the 15s cadence). 100% means the aggregator's feed was reachable for the full window." + - "Success rate: presence ratio. share of expected sampling slots where a value was actually emitted (5,760 expected per provider per day at the 15s cadence). 100% means the aggregator's feed was reachable for the full window." - "Cardinality: 3 aggregators × 3 chains × 3 regions = 27 active series." findings: [] @@ -35,8 +35,8 @@ prometheus: window: 24h # Real metric exposed by the head-lag harness: -# head_lag_seconds{aggregator, chain, region} — gauge in seconds -# head_lag_errors_total{aggregator, chain, region, error_type} — counter +# head_lag_seconds{aggregator, chain, region} . gauge in seconds +# head_lag_errors_total{aggregator, chain, region, error_type} . counter # # Label is `aggregator=`, not `provider=`. Values are in seconds; queries # multiply by 1000 so the loader stores milliseconds (consistent across the diff --git a/benchmarks/bridge-fee.yml b/benchmarks/bridge-fee.yml index 7fc14c4e3..125677413 100644 --- a/benchmarks/bridge-fee.yml +++ b/benchmarks/bridge-fee.yml @@ -1,4 +1,4 @@ -# OpenChainBench — Bench № 003 +# OpenChainBench. Bench № 003 slug: bridge-fee number: "003" @@ -10,11 +10,11 @@ metric: Effective fee unit: pct abstract: | - We measure the effective fee each bridge charges — the bottom-line cost a - user pays, fees plus slippage plus destination gas — as a percentage of + We measure the effective fee each bridge charges. the bottom-line cost a + user pays, fees plus slippage plus destination gas. as a percentage of trade size. The harness uses Prometheus gauge `bridge_cost_percent` rather than the narrower `bridge_fees_percent` because providers - structure pricing differently — some charge an explicit fee, others bake + structure pricing differently. some charge an explicit fee, others bake it into the spread. Comparing only the explicit fee field would let aggregators with implicit pricing show a misleading 0%. Sampled at $300 notional so small-amount fixed-fee blowups don't skew the percentile @@ -25,7 +25,7 @@ methodology: - "Reference notional: $300 USDC. Smaller sizes ($5, $50) are captured by the harness but excluded from this report." - "Cost: `bridge_cost_percent{amount_usd=\"300\"}`, in percent of notional. Includes fees + slippage + destination gas." - "Cadence: full sweep every 5 minutes for 24 hours." - - "Region: eu-west (single point — multi-region requires running additional monitor instances)." + - "Region: eu-west (single point. multi-region requires running additional monitor instances)." - "Failures (quote_failed, unsupported route) excluded from cost aggregates and counted toward success rate." findings: [] @@ -43,7 +43,7 @@ prometheus: # Why cost rather than fee: # bridge_fees_percent only captures the explicit fee field in each quote. # Some providers (e.g. Mobula) bake the cost into the spread instead of -# reporting an explicit fee, so they would render as 0% — misleading +# reporting an explicit fee, so they would render as 0%. misleading # readers. bridge_cost_percent = fees + slippage + gas, which is the # number that actually leaves the user's wallet. diff --git a/benchmarks/bridge-quote-latency.yml b/benchmarks/bridge-quote-latency.yml index 4e08e6a40..c136118ce 100644 --- a/benchmarks/bridge-quote-latency.yml +++ b/benchmarks/bridge-quote-latency.yml @@ -1,4 +1,4 @@ -# OpenChainBench — Bench № 002 +# OpenChainBench. Bench № 002 slug: bridge-quote-latency number: "002" @@ -21,7 +21,7 @@ methodology: - "Routes: USDC pairs spanning Solana, Base and Arbitrum." - "Notional sizes: $5, $50, $300 per quote." - "Cadence: full sweep (4 routes × 3 amounts × N bridges) every 5 minutes for 24 hours." - - "Region: eu-west (single point — multi-region requires running additional monitor instances)." + - "Region: eu-west (single point. multi-region requires running additional monitor instances)." - "Histogram buckets: 50, 100, 200, 500, 1000, 2000, 5000, 10000 ms." - "Failures (quote_failed, execution_failed, unsupported route) excluded from latency aggregates and counted toward success rate." @@ -35,8 +35,8 @@ prometheus: # Real metrics exposed by the bridge-monitor harness: # bridge_quote_latency_ms_{bucket,sum,count}{bridge, from_chain, to_chain, from_token, to_token, amount_usd, region} -# bridge_quote_success{...} — gauge 0/1 -# bridge_errors_total{..., error_type} — counter +# bridge_quote_success{...} . gauge 0/1 +# bridge_errors_total{..., error_type} . counter # # Label is `bridge=`, not `provider=`. Keep that in mind when extending. diff --git a/benchmarks/metadata-coverage.yml b/benchmarks/metadata-coverage.yml index 034a8e441..a24665cdc 100644 --- a/benchmarks/metadata-coverage.yml +++ b/benchmarks/metadata-coverage.yml @@ -1,4 +1,4 @@ -# OpenChainBench — Bench № 004 +# OpenChainBench. Bench № 004 slug: metadata-coverage number: "004" @@ -14,14 +14,14 @@ abstract: | freshly-launched tokens. The harness subscribes to Mobula Pulse V2 for new tokens on Solana, BNB Chain and Base, then asks each aggregator (Mobula, Codex, Jupiter where the chain is supported) for that token's metadata and - records whether four canonical fields — `logo`, `description`, `twitter` - and `website` — were returned. The aggregate is the share of (provider, + records whether four canonical fields. `logo`, `description`, `twitter` + and `website`. were returned. The aggregate is the share of (provider, chain, field) combinations that returned a populated value across all fresh-token checks in the window. Higher is better. A value of 100% means every field was returned for every fresh token; a value of 50% means half the fields were missing on average. - Sort order on this page is ascending — the lowest coverage shows first, + Sort order on this page is ascending. the lowest coverage shows first, which is the inverse of latency benchmarks. Readers should compare the columns themselves; numerical p50 is the headline. @@ -30,9 +30,9 @@ methodology: - "Coverage check: for each fresh token, query each aggregator's metadata endpoint and record whether `logo`, `description`, `twitter` and `website` are populated." - "Aggregators in scope: Mobula (`/api/2/token/details`), Codex (GraphQL `token` query, JWT-authenticated), Jupiter (`/v6/tokens/`, Solana only)." - "Cadence: queue-driven; every newly-discovered token is checked once across the three aggregators. Steady-state ≈ several hundred checks per provider per hour." - - "Region: `eu-west` (single point — multi-region requires running additional monitor instances)." - - "Ratio: `metadata_coverage_success_total / metadata_coverage_checks_total`, expressed in percent. Failures of the metadata API itself (timeouts, 5xx) are not counted in the denominator — only successful responses with the field check applied." - - "Jupiter is Solana-only — it appears with zero coverage on EVM chains by construction; the cross-chain headline excludes Jupiter on chains it does not support." + - "Region: `eu-west` (single point. multi-region requires running additional monitor instances)." + - "Ratio: `metadata_coverage_success_total / metadata_coverage_checks_total`, expressed in percent. Failures of the metadata API itself (timeouts, 5xx) are not counted in the denominator. only successful responses with the field check applied." + - "Jupiter is Solana-only. it appears with zero coverage on EVM chains by construction; the cross-chain headline excludes Jupiter on chains it does not support." findings: [] @@ -55,7 +55,7 @@ prometheus: # / sum(rate(metadata_coverage_checks_total{provider="X"}[24h])) # # We use quantile_over_time on a rolling 1h rate to give p50/p90/p99 the -# same shape as latency benchmarks — so a coverage rate that drifts during +# same shape as latency benchmarks. so a coverage rate that drifts during # the day shows tail behaviour, not a single flat value. providers: diff --git a/src/app/about/page.tsx b/src/app/about/page.tsx index 14ade7349..3db997e74 100644 --- a/src/app/about/page.tsx +++ b/src/app/about/page.tsx @@ -14,7 +14,7 @@ export default function AboutPage() { About OpenChainBench

- Open, reproducible benchmarks for crypto infrastructure — measured in + Open, reproducible benchmarks for crypto infrastructure. measured in the open, published in the same format every time.

@@ -23,25 +23,25 @@ export default function AboutPage() { Crypto infrastructure runs the world's open financial rails, and almost none of it is benchmarked in public. Every aggregator, bridge and market-data feed quotes its own numbers, on its own terms, with its own regions and its own definitions of “fast”. OpenChainBench picks one definition at a time, runs the experiment in the open, and publishes the script alongside the result.

- The goal is to make performance an observable property of crypto infrastructure — like uptime in SaaS, or p99 in databases — so builders can choose providers on data and users can hold them to it. + The goal is to make performance an observable property of crypto infrastructure. like uptime in SaaS, or p99 in databases. so builders can choose providers on data and users can hold them to it.

- Every benchmark is a YAML spec plus a harness. The spec describes what to measure, which providers, which Prometheus queries hold the numbers; the harness runs continuously and exposes those metrics. A single shared Prometheus scrapes every harness; the site queries Prometheus directly and re-renders every minute. Every provider is rendered with equal visual weight — readers do their own ranking. + Every benchmark is a YAML spec plus a harness. The spec describes what to measure, which providers, which Prometheus queries hold the numbers; the harness runs continuously and exposes those metrics. A single shared Prometheus scrapes every harness; the site queries Prometheus directly and re-renders every minute. Every provider is rendered with equal visual weight. readers do their own ranking.

Anyone can submit a benchmark. The{" "} contribution guide{" "} - walks through the steps. New providers, new metrics, new chains — all welcome via pull request. + walks through the steps. New providers, new metrics, new chains. all welcome via pull request.

    -
  • —Read the{" "}live benchmarks{" "}.
    • -
  • —Reproduce any number — the{" "}methodology{" "}page tells you how.
    • -
  • —Contribute a harness via{" "}GitHub. Pull requests for new providers and new benchmarks are reviewed openly.
    • -
  • —Discuss ideas in{" "}GitHub Discussions{" "}or follow{" "}@openchainbench.
    • +
  • ·Read the{" "}live benchmarks{" "}.
    • +
  • ·Reproduce any number. the{" "}methodology{" "}page tells you how.
    • +
  • ·Contribute a harness via{" "}GitHub. Pull requests for new providers and new benchmarks are reviewed openly.
    • +
  • ·Discuss ideas in{" "}GitHub Discussions{" "}or follow{" "}@openchainbench.
diff --git a/src/app/benchmarks/[slug]/page.tsx b/src/app/benchmarks/[slug]/page.tsx index d461b56ae..2e2af0965 100644 --- a/src/app/benchmarks/[slug]/page.tsx +++ b/src/app/benchmarks/[slug]/page.tsx @@ -135,7 +135,7 @@ export default async function BenchmarkPage({ {isDraft && } - {/* Charts + tables — no Fig. captions, just data */} + {/* Charts + tables. no Fig. captions, just data */} {!isDraft && ( <>
@@ -174,7 +174,7 @@ export default async function BenchmarkPage({
)} - {/* About — collapsed by default */} + {/* About. collapsed by default */}
@@ -197,7 +197,7 @@ export default async function BenchmarkPage({