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.
Several chains at once
One request per chain, same parameters. There is no multi-chain endpoint, because the alignment is the part worth doing deliberately.
for id in 43114 43419 68414; do curl -s "https://soci4l.net/api/avalanche/metrics?metric=txCount&range=90d&chainId=$id" done
Two things will bite. The first is that chains do not share a day axis, and not by a little: over a year the C-Chain returns 364 points and a chain that launched last week returns 5, so 359 days exist in one series and not the other. Joining on index rather than on day would lay those five points over the C-Chain's first five, a full year out, and nothing in the response would look wrong. Join on the day.
The second is scale. Across the Avalanche L1s with activity the spread is about seven orders of magnitude, so plotting a busy chain and a quiet one on one linear axis flattens the quiet one onto the floor. That is a true picture and an unreadable one. Either give each chain its own axis, or index every series to its first bucket with activity and compare trajectories instead.
Indexing has a floor of its own: a chain whose base bucket is tiny will swing wildly for reasons that are not growth. A chain going from 3 transactions to 6 draws the same doubling as a busy chain that genuinely doubled. Our own comparison page does all three: joins on the day, offers both readings, and refuses to index a series it cannot index honestly, saying which of those it is.
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.