add stakely SVG logo (bench 092)

.gitignore

@@ -37,6 +37,12 @@ yarn-error.log*
 # vercel
 .vercel
 
+# Prebuild-generated sitemap freshness manifest. Written by
+# scripts/emit-page-mtimes.ts on every build (git log %ct of editorial
+# hub pages) so the sitemap can emit a real <lastmod> from git history
+# without depending on Vercel's build-container file mtimes.
+/data/page-mtimes.json
+
 # Internal-only docs that must NOT ship with the open-source repo.
 # Patterns reserved as a tripwire: if a contributor adds a new doc with
 # one of these naming conventions, git won't track it without an

alternatives/alchemy.yml

@@ -9,3 +9,6 @@ intro: |
 
 seo_title: "Alchemy alternatives: live benchmark"
 seo_description: Compare Alchemy alternatives on real-time data freshness. Live head-lag against a canonical archive node, refreshed every minute and published openly.
+
+positioning: |
+  Alchemy's moat is a vertically integrated node platform. It runs archive nodes across 100+ chains (approximately 120 listed on the chain-connect page) and layers a data stack on top of the same infrastructure (Node API, Prices API, Notify webhooks, Subgraphs). For head lag, the relevant surface is the WebSocket subscription endpoint (eth_subscribe, plus proprietary alchemy_pendingTransactions and alchemy_minedTransactions) and the Notify webhook system for Address Activity and Custom Webhooks. Alchemy pushes filtered logs rather than pre-decoded swap events, which means an integrator must maintain a Transfer or Swap topic filter and decode the ABI client-side. The Prices API is a REST product with cached quotes drawn from CEX plus DEX aggregation, not a live swap feed. Alchemy tends to win when a team already runs the Node API for reads and wants notifications on the same account boundary; teams that need a decoded, cross-chain DEX trade stream typically migrate to a purpose-built aggregator because the client-side decoding overhead adds pipeline hops. Chain coverage skews heavily to EVM plus Solana; long-tail EVM L2s and Bitcoin sit inside the standard Node API surface.

alternatives/birdeye.yml

@@ -10,3 +10,6 @@ intro: |
 
 seo_title: "Birdeye alternatives: live benchmark"
 seo_description: "Birdeye alternatives on Solana token metadata coverage: logo, description, socials in seconds. Codex vs Mobula live."
+
+positioning: |
+  Birdeye's architectural weight sits on Solana. The public docs list 14 supported networks with Solana first and a longer tail of EVM and non-EVM chains (Ethereum, Arbitrum, BSC, Base, zkSync, Sui, Aptos, Monad, MegaETH, Fogo, Avalanche, Optimism, Polygon). The DEX Protocols page cites data drawn from more than 180 AMMs, with Solana-native venues like Raydium, Raydium CLMM, Orca and Whirlpool getting first-class treatment. The API surface that matters for metadata coverage is the DeFi and Token endpoints (/defi/price, /defi/token_overview, /defi/token_security), which return price, liquidity, supply, market cap and holder-side signals as normalized JSON. Because Solana pools are volatile and permissionless, a metadata provider either owns direct pool ingestion or inherits gaps; Birdeye publishes coverage caveats on Sui (no wallet APIs, no token security data, missing market cap and supply), which suggests per-chain pipelines rather than one uniform indexer. Teams pick Birdeye when the primary target is Solana memecoin and DEX token metadata under a single API. Teams tend to migrate when they need long-tail EVM L2 coverage or deep historical DEX reconstruction across chains where Birdeye ships less depth per chain.

alternatives/bitquery.yml

@@ -9,3 +9,6 @@ intro: |
 
 seo_title: "Bitquery alternatives: live benchmark"
 seo_description: Compare Bitquery alternatives on the number of blockchains each major onchain data provider officially supports. Live data, refreshed every six hours.
+
+positioning: |
+  Bitquery's moat is a unified GraphQL schema fanned out across four transports: GraphQL over HTTP, WebSocket subscriptions, Kafka with Protobuf encoding, and a Solana gRPC product (CoreCast) fed by validator-side Geyser plugins. Coverage is 40+ chains, uniform schema, decoded DEX trades with USD notional pre-computed server-side. For a chain-coverage benchmark that measures how many networks a provider officially supports for market data, Bitquery is structurally competitive because the same query works across every indexed chain without per-chain re-plumbing. The DEX Trades API is the load-bearing endpoint for market data: it exposes buys, sells, swaps, OHLCV at 1-second resolution, and cross-DEX aggregates on a single graph. Delivery latency is tiered by transport: gRPC under 300ms, Kafka under 500ms, WebSocket around a second, which lets integrators pick the durability vs speed trade-off explicitly. Teams win with Bitquery when they need historical plus real-time on the same schema, especially for analytics or accounting pipelines; teams that only want a decoded firehose of Solana Pump.fun trades sometimes pick a narrower vendor because Bitquery's breadth carries a higher entry price.

alternatives/chainlink.yml

@@ -11,3 +11,6 @@ seo_title: "Chainlink alternatives: live benchmark"
 seo_description: "Chainlink vs Pyth, Binance and Coinbase on live oracle deviation. Max pairwise gap on BTC, ETH, SOL."
 
 status: live
+
+positioning: |
+  Chainlink Data Feeds publish aggregated prices on-chain through an AggregatorV3 contract that is fed by a Decentralized Oracle Network running Offchain Reporting, with new rounds triggered either by a configured deviation threshold or by a heartbeat interval, and read via a proxy contract that returns latestRoundData() in the same transaction as the consuming logic. Its architectural moat is on-chain durability and the largest deployed integration surface across EVM chains, exposed through AggregatorV3Interface with no off-chain refresh step required. That model does not maximise for oracle-deviation on fast-moving assets, because the on-chain price only advances when the deviation trigger fires or the heartbeat elapses, so the reported value can lag a moving spot market by roughly one trigger-width until the next round lands. Chainlink also ships Data Streams, a pull-based sub-second latency product accessed over REST, WebSocket and SDKs, aimed at perpetual futures, options and prediction market venues that need low-latency data with on-chain verification. Lending markets, stablecoin issuers and blue-chip settlement continue on Data Feeds for the on-chain read pattern. Perp DEXes and derivatives protocols that cannot tolerate deviation lag on volatile assets migrate the price-sensitive path to Data Streams or a pull oracle.

alternatives/coingecko.yml

@@ -9,3 +9,6 @@ intro: |
 
 seo_title: "CoinGecko alternatives: live benchmark"
 seo_description: Compare CoinGecko alternatives on the number of blockchains each major onchain data API officially supports. Live data, refreshed every six hours.
+
+positioning: |
+  CoinGecko's moat is aggregation breadth across both centralized and decentralized venues under a single independent methodology. The core surface indexes 1,500+ CEXs and 18,000+ coins; the on-chain arm, delivered through GeckoTerminal and exposed under the /onchain endpoint family, adds 200+ blockchain networks, 1,500+ DEXs and tens of millions of tokens. For a chain-coverage benchmark on market data, this is the widest reported footprint of any listed provider in the cluster. Delivery is REST across every tier, with WebSocket and webhook channels gated to higher tiers. Data is not sourced from partner feeds or exchange-owned data providers but crawled and aggregated independently, which is the architectural reason CoinGecko's price on a long-tail token often differs from a venue-native quote. The /onchain/networks and /onchain/pools endpoints are the practical entry points for chain-scoped queries. CoinGecko wins for teams building broad market-data dashboards, tax and PnL products, or research tools that need one API to cover every chain a user might touch; teams focused on a single L2 or a specific DEX with millisecond freshness typically pair it with a narrower, WebSocket-native vendor.

alternatives/drpc.yml

@@ -11,3 +11,6 @@ seo_title: "dRPC alternatives: live benchmark"
 seo_description: "dRPC alternatives on eth_blockNumber p50 latency. PublicNode, 1RPC, Tenderly, Nodies, Lava ranked live."
 
 status: live
+
+positioning: |
+  dRPC is a routing layer, not a node operator. Every request lands on Dproxy, which scores third-party providers on health, capability, location, and recent compute-unit distribution; the request is then handed to Dshackle, an open-source fault-tolerant load balancer that picks the specific upstream node based on the method called, the current chain head, and the block context required. The routing is method-aware: a sendRawTransaction fans out to every capable node, a balance read routes only to lag-free upstreams, and a historical read filters to nodes that have synced to the requested block. This is architecturally distinct from single-operator RPCs, where a request runs against one homogeneous fleet, and distinct from public free RPCs, which have no cross-provider selection at all. For the rpc-capabilities axis, the routing model directly shapes the observed method coverage: a method that any upstream supports counts as covered network-wide, and uptime aggregates across upstreams rather than depending on any one operator's incident window. Chain coverage spans 120+ chains across 217 networks (Chainlist product) spanning EVM L1s and L2s, Solana, Bitcoin, Cosmos, and TON. The typical use case is teams that want one endpoint per chain with automatic failover; migration happens when a team needs a proprietary method only one upstream exposes.

alternatives/dune.yml

@@ -9,3 +9,6 @@ intro: |
 
 seo_title: "Dune alternatives: live benchmark"
 seo_description: "Dune alternatives on wallet labelling depth. Recently active address coverage across major EVM chains."
+
+positioning: |
+  Dune runs two distinct product surfaces with different pipelines. The core Dune Analytics product exposes SQL over decoded blockchain tables (Trino-backed, dbt-integrated), where community-maintained Spellbook models sit on top of raw, decoded, and traces tables. The Sim API is the real-time product, positioned in the docs as covering more than 60 EVM chains plus Solana and Eclipse with a REST surface for Balances, Activity, Transactions, Token Info, Token Holders, DeFi Positions, Collectibles and Webhooks. For a wallet-labels-coverage benchmark, the load-bearing distinction is that entity labels historically live in Dune Analytics as SQL tables and community spells rather than as a single REST endpoint on Sim; the Sim quickstart categorizes its endpoints around balances, activity, and token info, not wallet identity. Coverage of labels is therefore a function of what analysts have committed to the Spellbook plus what Sim exposes through its search and metadata endpoints. Teams pick Dune when the workflow is analyst-driven and labels are consumed via SQL joins in dashboards. Teams migrate when a product needs a single low-latency REST call that returns "is this address a CEX, MEV bot, bridge, or protocol contract" without writing a SQL query first.

alternatives/dydx.yml

@@ -11,3 +11,6 @@ seo_title: "dYdX alternatives: live benchmark"
 seo_description: Compare dYdX v4 against Hyperliquid, Lighter, GMX v2 and gains.trade on live taker fee plus spread crossed at $1000 notional, refreshed every five minutes.
 
 status: live
+
+positioning: |
+  dYdX v4 runs on an application-specific Cosmos SDK chain purpose-built for perpetuals, migrated off the Ethereum-based smart contracts in October 2023 with trading going live in November 2023. The moat sits at the pipeline level: validators maintain an off-chain in-memory orderbook for low-latency matching, then settle fills on-chain via consensus. Order placement and cancellation cost zero gas; fees apply only on execution and accrue to validators and stakers rather than a central operator. This split of matching from settlement is architecturally distinct from Ethereum L1 perp DEXs (fully on-chain, gas per action) and from single-sequencer L2 venues (matching lives on a proprietary node). For the perp-fees axis, the design has two direct consequences. Fees are set by governance parameter rather than by an operator, so tier changes are proposal-gated and observable on-chain. Rebates flow to on-chain makers under the same maker-taker schedule that a CEX would run, but with funds routed to the protocol staking layer instead of a company. The typical use case is high-volume market makers who want a maker rebate on a decentralized venue without paying per-order gas; teams migrate away when they need cross-margined equity products the Cosmos chain does not list.

alternatives/etherscan.yml

@@ -11,3 +11,6 @@ seo_title: "Etherscan alternatives: live benchmark"
 seo_description: Compare Etherscan against PublicNode feeHistory and Owlracle on gwei gap between predicted and realized priority fee, ranked on p99 over 24h.
 
 status: live
+
+positioning: |
+  Etherscan's moat is not a data product; it is a decade of running the canonical block explorer for Ethereum and the derivative explorer family (Polygonscan, BscScan, Arbiscan, Optimistic Etherscan and others), consolidated under Etherscan API V2 as one endpoint across 50+ chains. Gas Tracker rides on that same explorer infrastructure. The gastracker module exposes two actions: gasoracle returns SafeGasPrice, ProposeGasPrice, FastGasPrice, suggestBaseFee, LastBlock and gasUsedRatio; gasestimate returns a confirmation-time estimate for a supplied gas price. The public Gas Tracker page shows a countdown of "Next update in 10s" and breaks recommendations into Base plus Priority components, consistent with post-EIP-1559 fee mechanics. For the gas-estimation benchmark, the load-bearing point is that Etherscan sees the same block stream and pending pool that feeds the block explorer, so its recommendation is a direct function of recent-block base fee trajectory and the priority-tip distribution. Teams pick the Etherscan gas oracle when the integration is Ethereum-first and already uses etherscan.io for verified contracts and receipts. Teams migrate when they need mempool-derived estimates on non-EVM chains or a per-transaction priority-fee curve rather than three fixed tiers.

alternatives/gmx.yml

@@ -11,3 +11,6 @@ seo_title: "GMX alternatives: live benchmark"
 seo_description: Compare GMX v2 against Hyperliquid, dYdX, Lighter and gains.trade on live taker fee plus spread crossed at $1000 notional, refreshed every five minutes.
 
 status: live
+
+positioning: |
+  GMX V2 uses isolated GM liquidity pools rather than an orderbook. Each market has its own pool that pays out trader profits and absorbs trader losses, priced against a low-latency oracle rather than crossed against maker quotes. The V2 architecture runs on Arbitrum, Avalanche and MegaETH, with keeper contracts executing opens and closes so that the trader submits an intent and the keeper fills it at the next oracle price. This oracle-driven pool model is architecturally distinct from CLOB perp venues: there is no maker side, so there is no maker rebate to earn, and the fee schedule replaces the taker-only price with a bundle of position fee, price impact fee, borrow fee, and funding fee. For the perp-fees axis, this matters because a headline taker-only comparison understates GMX cost on skewed markets, where the borrow fee accrues hourly against the dominant side, and understates savings on balanced markets, where the position fee drops when a trade reduces open-interest skew. The typical use case is directional traders on major pairs who prefer no order management; teams migrate to CLOB venues once they need maker rebates or tight passive quoting.

alternatives/hyperliquid.yml

@@ -11,3 +11,6 @@ seo_title: "Hyperliquid alternatives: live benchmark"
 seo_description: Compare Hyperliquid against Lighter, dYdX, GMX v2 and gains.trade on live taker fee plus spread crossed at $1000 notional, refreshed every five minutes.
 
 status: live
+
+positioning: |
+  Hyperliquid runs a purpose-built L1 whose flagship application is the perp exchange itself. HyperCore holds the orderbook, margin, and matching engine as protocol state; HyperBFT, a HotStuff variant, orders blocks with median end-to-end latency of 0.2 seconds for co-located clients. Every resting order, fill, and liquidation is part of consensus and visible to every node, with strict price-time priority. This is architecturally different from dYdX v4, where matching happens in a validator in-memory book and only settlement lands on chain, and different from GMX, which has no orderbook at all. For the perp-fees axis, the design has two implications. The fee schedule is a 7-tier maker-taker table keyed to 14-day weighted volume, with maker rebates paid on every trade rather than settled periodically. HYPE staking layers a separate 5 to 40 percent discount as an overlay on top of the numbered volume tiers, and staking-linking lets a discount wallet apply to a distinct trading wallet, permanently. The typical use case is active perp traders and market makers who want CEX-shaped fees without a central operator; teams migrate away when they need EVM composability HyperCore itself does not offer, in which case HyperEVM sits on the same validator set.

alternatives/jupiter.yml

@@ -11,3 +11,6 @@ seo_title: "Jupiter alternatives: live benchmark"
 seo_description: Compare Jupiter against Mobula, OpenOcean and Raydium on live Solana quote latency. 100 USDC to long-tail token, polled every 60 seconds from 3 regions.
 
 status: live
+
+positioning: |
+  Jupiter is Solana-native and structured around two paired products. Metis is the routing primitive; Ultra is the managed execution engine on top. The Metis Update post describes slippage-aware routing, dynamic intermediate tokens and just-in-time routing as the mechanics behind route selection, and the Ultra vs Metis comparison frames Metis as a routing library callers wrap with their own RPC and transaction pipeline, while Ultra bundles transaction construction, priority-fee optimization, confirmation polling and error handling behind a single /order endpoint that averages 400 to 600 milliseconds end-to-end with p95 under one second. For a Solana DEX quote-latency benchmark, the load-bearing detail is that Jupiter runs the routing infrastructure that the majority of Solana DeFi frontends and aggregators call into, so the quote surface is a first-party product rather than a resold feed. The Quote API accepts inputMint, outputMint, amount and slippageBps, and returns a route that can traverse multiple Solana AMMs including Raydium, Orca, Meteora and Phoenix. Teams pick Jupiter when the target chain is Solana and a single call needs to price a swap across the full venue set. Teams migrate when the workflow leaves Solana or requires custom market-making beyond aggregated liquidity.