feat: RPC wave-2 chains, perp cluster v2, data-api hub, PM fixes

alternatives/bitquery.yml

@@ -2,7 +2,7 @@ slug: bitquery
 target_product: Bitquery
 target_url: https://bitquery.io
 description: GraphQL API for blockchain data, multi-chain
-benchmark: network-coverage
+benchmark: asset-registry-coverage
 
 intro: |
   Bitquery is a GraphQL surface on top of indexed onchain data, with the schema as the actual product: queries declare exactly the fields needed across transfers, trades, DEX events and account state, and the indexer fans those out across chains. Pricing is point-based, with each field, filter and join consuming from a monthly point budget rather than from a flat request quota, which means a single dashboard with many panels can hit the ceiling well before request volume looks high. Chain coverage is broad but uneven in depth: some networks expose full DEX trade indexing, others only basic transfers. The team usually compared next is the one whose chain list either covers a long-tail network Bitquery does not, or covers the same network with a flatter pricing model that does not penalise wide GraphQL fragments on a per-field basis.

alternatives/coingecko.yml

@@ -2,7 +2,7 @@ slug: coingecko
 target_product: CoinGecko
 target_url: https://www.coingecko.com/en/api
 description: Crypto price + market data API, multi-chain
-benchmark: network-coverage
+benchmark: asset-registry-coverage
 
 intro: |
   CoinGecko is a coin-centric price and market data REST API built around a curated asset list (the `/coins` universe) rather than around on-chain events. Tokens are added through a listing process, prices land on the API after that process completes, and the free tier is famously throttled (around 30 requests per minute on the demo key) which pushes any real product onto a paid plan within days of integration. The on-chain DEX side ships as a separate `/onchain` namespace inherited from GeckoTerminal, with its own quotas. Teams usually leave CoinGecko at one of two points: when the launch cadence of the tokens they care about outpaces the listing pipeline, or when the per-minute cap on the free tier forces a migration before the product is monetised enough to justify the enterprise tier.

alternatives/gains.yml

@@ -0,0 +1,16 @@
+slug: gains
+target_product: gains.trade
+target_url: https://gains.trade
+description: Oracle-priced perpetuals on Arbitrum, Base, Polygon and ApeChain
+benchmark: perp-fees
+
+intro: |
+  gains.trade v8 is an oracle-priced perpetuals venue running on Arbitrum, Base, Polygon and ApeChain. It settles against a GNS staking vault rather than a central orderbook, with the position open fee read directly on-chain from the fees contract and the spread term computed from half of the on-chain spreadP parameter. Because there is no orderbook, there is no price impact when executing against it: a $1M trade costs exactly the same number of basis points as a $1k trade. This benchmark measures the live all-in cost of opening a $1000 ETH long 10x position across major perpetual venues, every five minutes, by reading taker fees from each venue's own API and walking each orderbook for $1000 of buy-side notional. gains.trade is queried via eth_call on Base: pairs(N) gives the spreadP and feeIndex for each market, then fees(feeIndex) gives the open fee (totalPositionSizeFeeP). Values are in 1e10 precision per Gains v8 convention. The same harness queries Hyperliquid, Lighter, dYdX v4 and GMX v2. Funding rate is published separately because it accrues per hour held, not at open.
+
+seo_title: "gains.trade alternatives: live benchmark"
+seo_description: Compare gains.trade against Hyperliquid, Lighter, dYdX, GMX v2 on live taker fee plus spread crossed at $1k, $100k and $1M notional, refreshed every five minutes.
+
+status: live
+
+positioning: |
+  gains.trade v8 uses a decentralized GNS staking vault rather than an orderbook. Traders open positions against the vault, priced against a Chainlink or Pyth oracle rather than a live book. The vault absorbs trader profits and receives trader losses, with GNS stakers backstopping it in exchange for a share of protocol fees. This oracle-driven model is architecturally distinct from CLOB venues: there is no maker side, no maker rebate to earn, and the fee schedule is a single flat percentage of position size. For the perp-fees axis, this has one important implication: a $1M trade costs the same basis points as a $1k trade, because there is no book to walk and no price impact to eat. The all-in cost at any size equals the open fee plus half of spreadP, both read live from on-chain. The venue covers 364 active markets across crypto, forex, tokenized stocks, commodities and stock indices, the widest multi-asset catalog among EVM perp DEXes. The typical use case is directional traders on mid-cap or exotic pairs that lack deep orderbook liquidity on any CLOB venue; teams running large block trades also benefit from the flat cost structure versus a deep-but-not-infinite orderbook.

alternatives/the-graph.yml

@@ -2,7 +2,7 @@ slug: the-graph
 target_product: The Graph
 target_url: https://thegraph.com
 description: Decentralised indexing protocol with subgraph queries
-benchmark: network-coverage
+benchmark: asset-registry-coverage
 
 intro: |
   The Graph is a decentralised indexing protocol where each dataset (a subgraph) is written, deployed and queried independently rather than read off a pre-built schema. Queries are GQL against indexer nodes, billed in GRT, with a hosted gateway in front. The model means data shape is owned by whoever wrote the subgraph: a missing field, a stale index or a deprecated mapping is on the publisher, not on a central API team. Chain coverage tracks what indexers have chosen to support, which leans heavily EVM and lags on newer L2s and non-EVM networks until someone publishes a subgraph for them. The two reasons teams move off are the cost of running a private subgraph at production load, and the operational burden of debugging an indexer regression on a chain the public hosted service does not cover.