Algorand metrics, priced for machines.

Endpoints

Human-readable dashboard with free headline numbers: api.algometrics.org

How paying works

1. Request any paid endpoint. The API answers 402 Payment Required with payment terms in the payment-required header.
2. Your client signs a $0.01 USDC transfer on Algorand and retries the request with the payment header attached.
3. The GoPlausible facilitator settles it on-chain — it even sponsors the network fee — and the API returns your data plus an on-chain settlement receipt.

View ALGOMetrics on the GoPlausible x402 facilitator dashboard.

Quick start

See the terms (free — no payment needed to look):

curl -sD - https://api.algometrics.org/v1/metrics/summary | grep -i payment-required
# base64-decoded: pay $0.01 USDC (ASA 31566704) on Algorand mainnet via GoPlausible

Pay programmatically with the x402 TypeScript client:

import { x402Client, x402HTTPClient } from "@x402/core/client";
import { ExactAvmScheme } from "@x402/avm/exact/client";
import { toClientAvmSigner } from "@x402/avm";

const client = new x402Client();
client.register("algorand:*", new ExactAvmScheme(toClientAvmSigner(SECRET_KEY)));
const http = new x402HTTPClient(client);

const url = "https://api.algometrics.org/v1/metrics/summary";
const challenge = await fetch(url); // → 402 with payment terms
const required = http.getPaymentRequiredResponse(
  (name) => challenge.headers.get(name), await challenge.json());
const payload = await http.createPaymentPayload(required);

const paid = await fetch(url, { headers: http.encodePaymentSignatureHeader(payload) });
console.log(await paid.json()); // your metrics, payment settled on-chain

Your wallet needs a little ALGO and USDC (asset 31566704) with the opt-in done. Full schema at /openapi.json.

Methodology

Protocol economics and market microstructure

Protocol metrics are computed from Algorand block headers sampled over the trailing day: fees from the fc field, issuance from proposer payouts (pp), and net supply change as the difference — the honest inflation measure, not "fee burn" alone. Microstructure metrics follow Easley, López de Prado & O'Hara's VPIN construction: every ALGO-USD trade on Coinbase is folded into volume buckets sized at 1/50 of daily volume, with exact taker-side classification.

On-chain swap activity

Once per minute, the scanner advances through fully indexed Algorand rounds and decodes Tinyman V1.1, Tinyman V2, Pact, and Humble executions. Humble pool IDs and A/B asset pairs come from the canonical protocol app's on-chain registration events; decoded transfers must match that pair and the swap method's direction. Pool-execution coverage is limited to those venues and does not represent every Algorand DEX. The scanner also captures supported pool calls nested inside Folks, Haystack, and Vestige router trades. Those routers use the user's exact deposit and final payout, so user-level routes remain visible even when an underlying venue is not decoded. Routes are counted once for network activity. Exact executions nested under roots without an atomic-group ID remain in venue analytics, but are not presented as complete user routes without a supported router boundary. Their individual pool executions remain available for venue analysis, preventing split and multi-hop trades from inflating trade counts. The endpoint reports trailing 1-hour and 24-hour windows ending at the latest fully closed UTC minute. Route and protocol activity is grouped into directional input/output pairs whose assets include ID, symbol, name, and decimals. Readable whole-token amounts are reported beside the exact atomic integers; neither represents USD volume. Asset metadata is cached during scheduled aggregation, keeping Indexer calls off the paid request path. coverageComplete identifies windows still warming up. Partially decoded known router paths are retained as incomplete rather than silently presented as complete, and router logic or random-signing accounts are not presented as the initiating wallet. Router input candidates are limited to the transaction slot between init and execution. A single non-ALGO deposit/payout match remains valid for a fully opaque route. A lone ALGO match also requires visible net consumption or an ABI-declared ALGO route input, preventing fee funding from becoming a phantom swap. When multiple deposits match, net router consumption distinguishes the swap input from auxiliary funding or an intermediate asset. Pool executions attached to a router route are limited to that router's execute calls, excluding unrelated swaps in the same atomic group. If declared route topology cannot be resolved, the exact deposit/payout trade is retained as incomplete and its kind is reported as unknown rather than incorrectly labeled direct.

DEX venue activity

The /v1/metrics/dex-venue-activity endpoint ranks the captured Tinyman V1.1, Tinyman V2, Pact, and Humble venues over trailing 1-hour and 24-hour windows. It reports each venue's decoded pool-execution count and share, the number of directional pairs observed, and its ten leading pairs with exact native token amounts. Execution share measures captured pool-call activity; it is not USD-volume share or user-trade market share, and a split or multi-hop trade may execute through several pools. Coverage does not include every Algorand DEX.

Active DEX pairs

The /v1/metrics/dex-active-pairs endpoint ranks active asset pairs by normalized user-trade count over the same rolling windows. Both trade directions are combined into one stable pair, while the response retains the separate directional flows and exact token amounts. A multi-hop or split route counts once, incomplete known routes are disclosed, and no token quantity is presented as USD volume. User-trade coverage includes exact Folks, Haystack, and Vestige router deposits and payouts; underlying venue execution coverage remains limited to Tinyman V1.1, Tinyman V2, Pact, and Humble.

DEX wallet activity

The /v1/metrics/dex-wallet-activity endpoint groups normalized user-level routes by their initiating Algorand address over rolling 1-hour and 24-hour windows. It reports active and repeat wallet counts, mean and median trades per wallet, the share of trades initiated by the top one, five, and ten wallets, and HHI as an overall trade-count concentration measure. Each route counts once even when it is split or multi-hop, and individual addresses are never returned. Addresses are accounts rather than verified people, and concentration measures activity—not USD volume, wealth, or profitability. User-trade coverage includes exact Folks, Haystack, and Vestige router deposits and payouts; underlying venue execution coverage remains limited to Tinyman V1.1, Tinyman V2, Pact, and Humble.

DEX wallet retention

The /v1/metrics/dex-wallet-retention endpoint compares distinct initiating addresses across adjacent, non-overlapping closed UTC periods of equal length. Its 1-day, 7-day, and 30-day views report active wallets in each period, wallets retained across both, current-only and previous-only wallets, retained-wallet rate, returning-wallet share, and active-wallet growth. The views become available progressively after approximately 2, 14, and 60 complete days; each UTC day has a one-hour scanner-catch-up delay, and each history-warming view returns null statistics and its exact availableAt timestamp. A new day is finalized only after scanner lag is within the configured healthy tolerance and remains stable for a short KV-write propagation buffer. A corrupt or oversized daily rollup is disclosed as a source-gap; affected views return null statistics rather than partial counts. A gap clears only after an explicit archival rebuild restores the full UTC day, or after that day ages out of the comparison. A newlyActiveWalletCount wallet is absent from the immediately preceding equal-length period, but may be a reactivated address seen earlier—it is not necessarily new to Algorand. Addresses are accounts rather than verified people, individual addresses are never returned, and coverage remains limited to the documented DEX venues and supported router paths.

Trending DEX pairs

The /v1/metrics/dex-trending-pairs endpoint identifies pairs whose current activity is unusually high relative to that same pair's preceding seven-day history. The 1-hour view compares the latest fully closed UTC hour with 168 hourly observations; the 24-hour view compares the latest fully closed day with seven preceding non-overlapping daily observations. Pairs are ranked by the mean of their normalized user-trade-count and unique active-wallet-count z-scores, with activity multiples, historical percentiles, sample counts, and both trade directions retained. The result measures acceleration, not absolute popularity, USD volume, price performance, or investment quality. It returns 503 during its initial eight-day pair-wallet history warm-up, requires at least three current trades from two active wallets in the 1-hour view or ten current trades from three active wallets in the 24-hour view, plus a combined trend score of at least 1, never returns individual wallet addresses, and has the same limited DEX and router coverage as the active-pairs endpoint. Each z-score denominator is the largest of the observed population standard deviation, one count, and 10% of the baseline mean; the effective value is returned for reproducibility. The warm-up response is not charged. After warm-up, an empty pairs array is a valid, charged result meaning no pair cleared the screen.

DEX activity anomalies

The /v1/metrics/dex-activity-anomalies endpoint reports asset pairs and venues whose current activity is unusually high or unusually low against their own preceding seven-day baseline. Where trending pairs ranks acceleration among already-active pairs, this one is two-sided and includes drops, which makes it suited to alerts and agent polling. The 1-hour view scores each series against 168 preceding hourly observations and, separately, against the same UTC hour on each of the preceding seven days, and reports an anomaly only when both scores clear the threshold in the same direction: Algorand DEX activity follows a strong daily cycle, so a single pooled hourly baseline would call every daily peak a spike and every night a drop. The 24-hour view uses seven non-overlapping daily observations, which already balance across weekdays, and additionally requires the current value to fall outside the observed baseline range. Pair spikes require at least five current trades from two active wallets in the 1-hour view, or fifteen current trades from three active wallets in the 24-hour view. Venue spikes require at least three current executions in the 1-hour view or ten in the 24-hour view. Drops have no current-activity floor because a real drop can reach zero. Each window returns these requirements explicitly. Each score denominator is the largest of the observed population standard deviation, the square root of the baseline mean, and an absolute floor, and is returned so the score is reproducible. A baseline observation is used only when every hour inside it is proven processed by the scanner cursor, within the aggregate retention horizon, and readable; hours that fail are excluded rather than counted as zero, and the excluded count is returned. Because unprovable hours skew toward quiet periods, that exclusion can lift the baseline mean slightly, which the response discloses. Venue anomalies count pool executions rather than user trades, so a router changing its split strategy can move a venue without any change in user activity, and the 1-hour window sits inside the 24-hour window, so the two must never be added. zScore is a standardized deviation, not a p-value, and severityScore is a rescaled absolute z-score saturating at 1 rather than a probability. The endpoint returns 503 during its eight-day warm-up, while the scanner has not proven it processed the whole current window, and when no window has a usable baseline; those responses are not charged. After warm-up, an empty anomalies array is a valid, charged result meaning nothing cleared the published thresholds. No wallet addresses are returned, venue series carry no wallet count, and coverage is limited to the same documented DEXs and router paths as the active-pairs endpoint.

On-chain DEX microstructure

The /v1/metrics/dex endpoint applies the same VPIN construction to decoded on-chain ALGO/USDC swaps. Because every captured Tinyman, Pact, and Humble execution records the taker's side directly, adverse selection is measured from the exact swap direction rather than the tick-rule inference used on centralized venues. Executions are folded into fixed base-volume buckets as the scanner advances, and the response carries VPIN, order-flow imbalance, Kyle lambda, realized and Parkinson volatility, and VWAP for the pair. A divergence block compares the on-chain reading to the Coinbase ALGO-USD microstructure snapshot — the price basis in basis points, plus each venue's VPIN ranked against its own trailing history, since raw VPIN levels are not comparable across an AMM and a central limit order book — so agents can tell when on-chain flow carries more adverse selection than usual, or is trading rich or cheap, versus the centralized book. Until enough volume has accumulated to close the first bucket the endpoint returns 503 and is never charged.

Every response includes compact quality signals and a link to its full methodology and caveats — read them in full.