Base URL https://soci4l.net/api/avalanche. Everything here is a GET, and none of it authenticates.
Quick start
One endpoint serves the whole catalogue. Ask for a metric and you get a daily series for the Avalanche C-Chain over the last year.
curl "https://soci4l.net/api/avalanche/metrics?metric=activeAddresses"
Add format=csv when you want a file rather than JSON.
curl "https://soci4l.net/api/avalanche/metrics?metric=txCount&range=all&interval=month&format=csv" period,txCount,complete 2020-09-01,57,true 2020-10-01,336,true … 2026-06-01,76689373,true 2026-07-01,91176250,true
The row after those is the month still running, and it carries complete=false. See below.
Any Avalanche L1 works the same way. Pass its EVM chain id, which you can read off any row of the L1 table.
curl "https://soci4l.net/api/avalanche/metrics?metric=txCount&chainId=43419&range=90d"
Metrics
Thirteen, from the public Avalanche metrics API. Four are running totals rather than daily figures: summing those over a window gives a large and entirely meaningless number, so they are marked.
| metric | Meaning | Unit | Kind |
|---|---|---|---|
| txCount | Transactions included in blocks that day. | count | per day |
| activeAddresses | Distinct addresses that sent or received a transaction. | count | per day |
| activeSenders | Distinct addresses that originated a transaction, so paid for it. | count | per day |
| feesPaid | Total transaction fees burned or paid that day, in AVAX. | avax | per day |
| gasUsed | Total gas consumed by the day’s transactions. | gas | per day |
| avgTps | Mean transactions per second across the day. | tps | per day |
| maxTps | Highest transactions per second reached that day. | tps | per day |
| avgGps | Mean gas consumed per second, the throughput measure that ignores tx size. | gas-per-second | per day |
| maxGps | Highest gas per second reached that day. | gas-per-second | per day |
| cumulativeTxCount | Every transaction the chain has ever processed. | count | running total |
| cumulativeAddresses | Every address that has ever appeared on the chain. | count | running total |
| cumulativeContracts | Every contract ever deployed. | count | running total |
| cumulativeDeployers | Distinct addresses that have deployed at least one contract. | count | running total |
Parameters
All optional. GET https://soci4l.net/api/avalanche/metrics
| Parameter | Accepts | Default |
|---|---|---|
| metric | Any of the thirteen above | txCount |
| range | 30d, 90d, 1y, all | 1y |
| interval | day, week, month | day |
| chainId | The EVM chain id of any tracked Avalanche mainnet L1 | 43114 |
| format | json, csv | json |
Weekly and monthly figures are aggregated here from the daily series. They are never read from the upstream monthly rollup, which is wrong for part of the C-Chain history.
Completeness
The field worth reading before you plot anything. Every point carries complete, and the response carries lastPeriodComplete.
{
"series": [
{ "day": "2026-08-20", "value": 345601300573, "complete": true },
{ "day": "2026-08-21", "value": 25190494165, "complete": false }
],
"lastPeriodComplete": false
}A false there means the period is still filling and its value will grow. Two periods can be unfinished: today, and the newest day the upstream has published, which it is still aggregating. That second one is easy to miss and expensive to miss: measured on 22 August 2026, the upstream's newest day held about an hour and three quarters of traffic and read at 7% of a normal day. Charted as a finished day it is a cliff that never happened.
So drop the incomplete points, or draw them as provisional. Do not average over them.
Errors
Three, and the distinction between the middle two is deliberate.
| Status | Means |
|---|---|
| 400 | An argument was not well formed: an unknown metric, range or interval, or a chainId that is not a number. The message lists what would have been accepted. |
| 404 | The chainId was well formed and no Avalanche mainnet L1 has it. Distinct from a real chain that was simply quiet, which returns 200 and a series of zeroes: no data and no activity are not the same answer. |
| 503 | The upstream was unreachable. Deliberately not a partial series, because a window with its older half missing computes a confident change over nothing. |
Cross-checked series
Four endpoints serve one series each, and each is checked against a second, independent source. The agreement, and every day the two sources disagree, is published in the response rather than smoothed away.
GET /monthly-transactionsC-Chain transactions by month, back to September 2020, with month-over-month and year-over-year change.
Cross-checked against: Routescan (Snowtrace index), reported per month as crossCheckTxCount.
This is the series behind the upstream rollup defect we reported. Monthly totals here are aggregated from the daily series, never read from the upstream monthly rollup, because that rollup is wrong.
GET /transaction-feesC-Chain fees paid, monthly or daily, denominated in AVAX and never converted to a currency.
Cross-checked against: Routescan. The response carries recentAgreementPct and disputedDayCount.
GET /block-productionBlocks per day and mean block time over a rolling window.
Cross-checked against: The Avalanche C-Chain public RPC, by bisection on day boundaries. The response carries the samples it verified against.
GET /validatorsPrimary Network validator and delegator counts with stake, daily since the 2020 launch.
Cross-checked against: Our own daily snapshot of platform.getCurrentValidators on the P-Chain, from July 2026 onward.
Each takes format=csv, and the two monthly ones also take interval=day for the underlying daily series.
Terms
Use it for anything, including commercially. No key, no quota, no attribution required, though a link back is welcome. Responses are cached for an hour, so poll on that order rather than faster: the underlying series only moves once a day.
The numbers originate with the public Avalanche metrics API and the cross-check sources named above, and the responses say so in a source field. We aggregate, cross-check and publish the disagreements; we do not compute the underlying chain data. If a figure here looks wrong, it is worth telling us, because that is exactly how the monthly rollup defect was found.