NEAR mints about 2.5% of its supply a year. A fee-burn dashboard sees only the gas burn, 0.92% of issuance, and puts break-even 108 times away. Since April 2026 the NEAR Intents contract has also been sending NEAR to a buyback account, where it is held, not burnt. Count that, and burn plus buybacks offset 12.0% of issuance.1
Live read unavailable (the free endpoint rate-limits); showing the committed cache.
Payback is burn plus the buyback account's gain, divided by NEAR minted to validators. Mint and burn come from total_supply in block headers, exact to the yoctoNEAR; the buyback gain is a balance change between epoch ends.2
of issuance, from burn 0.92% and buybacks 11.05%. 90% resampling range 10.7% to 13.5%.
Growth in flows needed to equal issuance at constant issuance.
If maximum issuance falls from 2.5% to 1.6% a year.
What a fee-burn dashboard reports: 0.92% of issuance.
Share of minted NEAR matched, 100-epoch rolling window. Hover, tap or use the arrow keys for values.
data/epochs.csv and data/buybacks.csv.2 Break-even is 100%, off the top of this frame.Source: mint / (burn + buyback gain)
Source: view_account balance of buybacks.multisignature.near at each epoch's last block, differenced
Source: block header total_supply: supply(first block) - supply(last block) + burnt(first block), per epoch
Source: burn / mint, both from block header total_supply
Source: block header total_supply: supply(first block) - supply(last block of previous epoch) + burnt(first block)
Source: chunk gas_used / gas_limit over 3 seeded random heights per epoch
The buyback account, buybacks.multisignature.near, gains about 9,922 NEAR a day against 829 NEAR burnt in gas. It is held, not burnt.3
Share of each epoch's minted NEAR matched by gas burn and buyback gain. Hover or use the arrow keys; click to hold an epoch.
intents.near · 3,327 transfers77.2%1csfundsadmin.sputnik-dao.near · 3 transfers22.4%clingy.near · 1 transfer0.2%52435fe912…362c8d · 3 transfers0.1%2,979 of the 2,996 transfers since height 201,009,796 came from intents.near. 1csfundsadmin.sputnik-dao.near sent 22.4% in 3 transfers, including the one the headline excludes.3
| Period | NEAR a day | Payback |
|---|---|---|
| 30 days before27 Oct, private settlement | 9,298 | 11.7% |
| 17 days since | 10,452 | 12.5% |
Since 2026-10-27 a growing share of Intents swaps settles on a private chain (reported by the Tideline entry; our own check of mainnet logs is in the cross-checks below), which hides their fees from public swap data. The buyback balance is on mainnet and still records what arrives.
Epochs that reconcile to the yoctoNEAR, from 3,374 receipts. 5 epochs with multisig calls differ by 0.34 NEAR of gas.
Sent by intents.near; 22.4% by 1csfundsadmin.sputnik-da in 3 transfers.
NEAR that has left: 0.53% of inflow, the largest to a bridge account on 2026-07-10. None burnt.
Keys needed to move it. 0 full-access keys, 4 requests ever, 0 pending. The chain does not say who holds the keys.
Source: DefiLlama summary/dexs/near-intents, in data/llama.csv
Source: DefiLlama summary/fees/near-intents dailyHoldersRevenue, in data/llama.csv
Source: captured revenue / volume, weekly, in data/llama.csv
The share of intents.near event logs that name the Confidential Intents treasury, in seeded random blocks (data/private_sample.csv, python3 fetch.py private).
| Period | Blocks | Event logs | Naming the treasury | 90% interval |
|---|---|---|---|---|
| 30 days before 2026-10-27 | 250 | 438 | 13% | 8% to 18% |
| Since | 250 | 631 | 43% | 36% to 49% |
The same flows over the same days, in NEAR a day. DefiLlama reports USD; each day is converted at that day's price.
| Flow, NEAR a day | This repo, from chain | DefiLlama |
|---|---|---|
| Gas fees burnt | 829 | 685its revenue series; its fees series is 979 |
| Buyback account gain | 9,922 | 13,594captured revenue, all wallets |
| All three revenue wallets, gain | 13,984 |
2979 of the 2996 transfers since height 201009796 into the buyback account came from intents.near, carrying 74.0% of the NEAR (NearBlocks, with transaction hashes in data/inflows.csv). The account audit rebuilds with python3 fetch.py history and python3 fetch.py multisig; test_run.py fails if an epoch is unexplained.
Payback scales with Intents volume and with the share of gross Intents fees reaching the buyback account, and inversely with the issuance rate. HSP-029, passed by NEAR's House of Stake on 2 November 2026 and awaiting ratification, would lower maximum issuance to 1.6% a year.5
burn + buybacks, as a share of issuance
flows must grow this much
| Growth a year | Issuance 2.5% | Ramp to 1.6% |
|---|---|---|
| 10% a year | 30.2 yrs | 21.3 yrs |
| 25% a year | 10.8 yrs | 8.2 yrs |
| 50% a year | 5.6 yrs | 4.4 yrs |
| 100% a year | 3.2 yrs | 2.5 yrs |
Function: run.py: main (breakeven_years, growth_needed_*).
| Model | Pinball | Band held |
|---|---|---|
| Persistencerecent level only | 0.0865 | 67% |
| Clocklevel plus a time-of-week profile | 0.0785 | 65% |
| Pricelevel plus NEAR's price | 0.0938 | 73% |
Lower pinball loss is better. The 10–90% bands are too narrow: they hold about two-thirds of outcomes against a nominal 80%. Functions: run.py: f_persistence, f_clock, f_price, backtest.
Mint and burn per epoch from block-header supply; the buyback gain is a balance change. No parameters.
fetch.py: fetch_epoch · run.py: loadThree models give 10/50/90% quantiles of NEAR burnt per epoch, backtested walk-forward.
run.py: f_persistence, f_clock, f_price, backtestIntervals for the next N epochs, from how much consecutive windows have differed. These are the frozen rounds.
run.py: window_claims, predictVolume, capture share and issuance, and the years to break-even at a steady growth rate.
run.py: main (breakeven_years)run.py, rebuilt by python3 run.py with no network; outputs in out/results.jsonEach forecast uses only data before its date, up to 30 epochs ahead. Lower pinball loss is better.
| Model | Pinball loss | Against persistence | 10–90% band held |
|---|---|---|---|
| persistencerecent level only | 0.0865 | +0.0% | 67% |
| clocklevel plus a time-of-week profile | 0.0785 | +9.2% | 65% |
| pricelevel plus NEAR's price | 0.0938 | -8.5% | 73% |
For a window of the next N epochs: the last N-epoch value, scaled by the 5% to 95% range of how much consecutive windows have differed. The table is how often that procedure, run at earlier dates on data available then, contained the outcome. Nominal coverage is 90%.
| Window | Payback | NEAR burnt | Buyback gain |
|---|---|---|---|
| 5 epochs | 134 of 168 80% | 138 of 169 82% | 108 of 123 88% |
| 10 epochs | 71 of 83 86% | 67 of 83 81% | 56 of 62 90% |
| 20 epochs | 35 of 40 88% | 30 of 40 75% | 28 of 30 93% |
| Quantity | Definition |
|---|---|
| mint | supply(first) - supply(prev last) + burnt(first) |
| burn | burnt(first) + supply(first) - supply(last) |
| payback | (burn + buyback gain) / mint |
| multiple | mint / (burn + buyback gain) |
Checked by run.py: load (continuity of heights and supply) and against mainnet by verify.py.
Not a forecast: three growth rates taken from the data by one rule, and where each takes payback from today's 12.0%. HSP-029, passed on 2 November 2026 and awaiting ratification, moves every date earlier; it does not change which paths arrive.8
Burn plus buybacks as a share of issuance, log scale. Above the line, NEAR's flows pay back more than it mints.
out/results.json → scenarios.path. Quarterly steps; the chart stops at 200%.never with HSP-029 either
If gross Intents fees keep shrinking as they did over the past year, the flow shrinks with them and never reaches issuance.
2075 with HSP-029 (49 years)
At the median year-long rate, payback is 15% of issuance in ten years. At this pace, growth alone is too slow; capture is the lever.
2031 with HSP-029 (4 years)
If Intents volume keeps the trend it set over the past year, break-even comes in about 6 years. Five-year break-even needs 57% a year.
| Share of gross Intents fees captured | Payback today | Break-even, 2.5% | With HSP-029 |
|---|---|---|---|
| 22% today | 12% | 84 yrs | 49 yrs |
| 50% | 26% | 53 yrs | 27 yrs |
| 100% | 50% | 27 yrs | 7 yrs |
Today's flow would equal issuance if issuance were 0.30% a year. HSP-029's 1.6% takes the distance from 8.4× to 5.3×. Capture is the larger lever: all of it, with HSP-029, brings the base case to 7 years.
How the three rates are set: one rule, not a choice. The captured flow is nine months old and was ramping up, so its own growth is not used; what drives it is (buybacks are 92% of payback and follow NEAR Intents volume, r = 0.92 by week). Four year-long rates from the DefiLlama year: Intents volume, last 30 days against the first 30 (+2.6%) and log-linear trend (+49.9%); gross Intents fees, the same two ways (−23.2%, +7.7%). Bear is the lowest, base the median, bull the highest. Shorter windows are left out: they annualise August's jump into several hundred percent a year. Paths start at today's 12.0% and hold capture share and NEAR price constant; issuance is a rate on a supply that keeps growing, so the NEAR minted each year rises with it; HSP-029 is a linear ramp from 2.5% to 1.6% over 24 months, starting at its earliest possible date, 2027-02-14 (after the veto window, which runs to 16 Nov 2026, and a 90-day grace period; validators must also adopt the upgrade). Dashed lines: with HSP-029. Shaded: between bear and bull. run.py: scenarios, scenarios in out/results.json.
Six points each side, at equal weight. The full argument, with what would change our mind, is in THESIS.md.
9,922 NEAR a day reach the buyback account, against 829 burnt.
2,979 of 2,996 recent transfers were sent by intents.near.
DefiLlama gives 13,594 NEAR a day for all revenue wallets; balances read from chain give 13,984.
The account receives about 22% of gross Intents fees. All of it, at today's volume, would be 50% of issuance.
At 1.6% a year the multiple is 5.3× at today's flows.
intents.near's daily receipts grew 2.8× since February; its share of all receipts rose from 0.7% to 7.8% (BigQuery).
The NEAR sits in a multisig account. Supply does not fall and the holders can spend it.
From a peak of 16.5% on 19 September 2026 to 12.0%.
Over a year, daily volume is 1.03× and gross fees 0.77× (DefiLlama).
One application supplies 92% of the payback.
10,283 NEAR left the account in 1 of 663 epochs.
Daily active accounts are down 70% and transactions down 80% since February. Most of the drop in app activity is one app, KaiChing, leaving (BigQuery).
“If the buybacks were burnt, net inflation would be 2.20% instead of 2.48%. They are not, yet.”Inflation if buybacks were burnt · out/results.json
Daily active accounts, transactions and contract usage, from Google's public NEAR dataset bigquery-public-data.crypto_near_mainnet_us. Most of the fall in calls is one app leaving: over the first 30 days earn.kaiching and wallet.kaiching made 79% of all function calls, and neither is in the top 25 now. Daily active accounts fell in one step on 19 Feb 2026, from 504,588 to 146,971, which looks like a single exit rather than a slow drift. Over the same window intents.near's own activity grew in absolute terms, so its share rose from 0.7% to 7.8%: NEAR's activity is moving to the application that pays the buybacks. It does not by itself raise payback: the buyback account is paid from Intents fees, not from receipts.
Accounts signing at least one transaction averaged 212,037 a day over the first 30 days and 63,923 over the last 30, down 70%.
queries/daily_active_accounts.sql-- daily_active_accounts: accounts that signed at least one transaction, per UTC day.
--
-- Table bigquery-public-data.crypto_near_mainnet_us.transactions (partitioned on block_date)
-- Columns read: block_date (DATE), signer_account_id (STRING). Nothing else is scanned.
-- Window 2026-02-13 to 2026-11-12, the same days as the repo's chain window; the WHERE clause
-- on block_date prunes partitions, so only these 273 days are read.
-- Cost BigQuery bills the bytes of the columns read. Measured on 2026-11-13 (dry run): 9.6 GB.
-- The console shows the exact figure ("This query will process ...") before you run it.
-- All four queries together scanned 122 GB; the free sandbox allows 1 TB a month.
-- Run BigQuery console (sandbox: free, no card): paste, Run, then
-- "Save results" -> "CSV (local file)", saved as data/bq/daily_active_accounts.csv
-- or mkdir -p data/bq && bq query --use_legacy_sql=false --format=csv --max_rows=1000 \
-- < queries/daily_active_accounts.sql > data/bq/daily_active_accounts.csv
-- Output block_date, active_accounts (one row per day). Read by bq.py; nothing else edits it.
-- Schema column names from the dataset's published schema; if the console reports an unknown
-- column, check the table's Schema tab (signer_account_id is the transaction signer).
SELECT
block_date,
COUNT(DISTINCT signer_account_id) AS active_accounts
FROM `bigquery-public-data.crypto_near_mainnet_us.transactions`
WHERE block_date BETWEEN DATE '2026-02-13' AND DATE '2026-11-12'
GROUP BY block_date
ORDER BY block_date
NEAR carried 3,411,071 transactions a day over the first 30 days and 669,188 over the last 30, down 80%.
queries/daily_transactions.sql-- daily_transactions: signed transactions included on chain, per UTC day. -- -- Table bigquery-public-data.crypto_near_mainnet_us.transactions (partitioned on block_date) -- Columns read: block_date (DATE) only, so this is the cheapest of the four queries. -- Window 2026-02-13 to 2026-11-12, filtered on block_date so only these 273 days are read. -- Cost measured on 2026-11-13 (dry run): 2.7 GB. The console shows the exact figure before -- you run it. Free sandbox: 1 TB a month. -- Run BigQuery console (sandbox: free, no card): paste, Run, then -- "Save results" -> "CSV (local file)", saved as data/bq/daily_transactions.csv -- or mkdir -p data/bq && bq query --use_legacy_sql=false --format=csv --max_rows=1000 \ -- < queries/daily_transactions.sql > data/bq/daily_transactions.csv -- Output block_date, transactions (one row per day). -- Note counts every included transaction, successful or not (the status column is not read). SELECT block_date, COUNT(*) AS transactions FROM `bigquery-public-data.crypto_near_mainnet_us.transactions` WHERE block_date BETWEEN DATE '2026-02-13' AND DATE '2026-11-12' GROUP BY block_date ORDER BY block_date
intents.near received 7.8% of all receipts over the last 30 days, against 0.7% over the first 30: its share of network activity rose.
queries/intents_share.sql-- intents_share: how much of NEAR's daily contract activity goes to intents.near.
--
-- Table bigquery-public-data.crypto_near_mainnet_us.receipt_actions (partitioned on block_date)
-- One row per action inside an action receipt. index_in_action_receipt = 0 marks the first
-- action of each receipt, so counting those rows counts receipts without reading the long
-- receipt_id strings.
-- Columns read: block_date, index_in_action_receipt, action_kind, receipt_receiver_account_id.
-- Window 2026-02-13 to 2026-11-12, filtered on block_date so only these 273 days are read.
-- Cost measured on 2026-11-13 (dry run): 83 GB, the largest of the four. The console shows
-- the exact figure before you run it. Free sandbox: 1 TB a month.
-- Run BigQuery console (sandbox: free, no card): paste, Run, then
-- "Save results" -> "CSV (local file)", saved as data/bq/intents_share.csv
-- or mkdir -p data/bq && bq query --use_legacy_sql=false --format=csv --max_rows=1000 \
-- < queries/intents_share.sql > data/bq/intents_share.csv
-- Output block_date, receipts, intents_receipts, function_calls, intents_function_calls,
-- intents_receipt_share (one row per day).
-- Check action_kind values follow the NEAR indexer enum ('FUNCTION_CALL', 'TRANSFER', ...). If
-- function_calls comes back 0, run SELECT DISTINCT action_kind for one day and adjust.
SELECT
block_date,
COUNTIF(index_in_action_receipt = 0) AS receipts,
COUNTIF(index_in_action_receipt = 0 AND receipt_receiver_account_id = 'intents.near') AS intents_receipts,
COUNTIF(action_kind = 'FUNCTION_CALL') AS function_calls,
COUNTIF(action_kind = 'FUNCTION_CALL' AND receipt_receiver_account_id = 'intents.near') AS intents_function_calls,
SAFE_DIVIDE(
COUNTIF(index_in_action_receipt = 0 AND receipt_receiver_account_id = 'intents.near'),
COUNTIF(index_in_action_receipt = 0)) AS intents_receipt_share
FROM `bigquery-public-data.crypto_near_mainnet_us.receipt_actions`
WHERE block_date BETWEEN DATE '2026-02-13' AND DATE '2026-11-12'
GROUP BY block_date
ORDER BY block_date
Share of all function calls, last 30 days, top 10; grey text: rank in the first 30 days
earn.kaiching was 1st with 51.4% of all callswallet.kaiching was 2nd with 28.0% of all callsintents.near ranked 3rd by function calls over the last 30 days (8.0% of all calls), against 11th over the first 30.
queries/top_contracts.sql-- top_contracts: the 25 contracts receiving the most function calls, in the first and the last
-- 30 days of the window, so a change in rank (intents.near's in particular) is visible.
--
-- Table bigquery-public-data.crypto_near_mainnet_us.receipt_actions (partitioned on block_date)
-- Columns read: block_date, action_kind, receipt_receiver_account_id.
-- Window two 30-day slices of 2026-02-13 to 2026-11-12: 2026-02-13 to 2026-03-14 and
-- 2026-10-14 to 2026-11-12. The WHERE clause on block_date reads only those 60 days.
-- Cost measured on 2026-11-13 (dry run): 26 GB. The console shows the exact figure before
-- you run it. Free sandbox: 1 TB a month.
-- Run BigQuery console (sandbox: free, no card): paste, Run, then
-- "Save results" -> "CSV (local file)", saved as data/bq/top_contracts.csv
-- or mkdir -p data/bq && bq query --use_legacy_sql=false --format=csv --max_rows=1000 \
-- < queries/top_contracts.sql > data/bq/top_contracts.csv
-- Output period ('first_30d' or 'last_30d'), rank, contract, function_calls, share; up to 26 rows
-- a period (the top 25, plus intents.near if it ranks lower)
-- (share = the contract's function calls / all function calls in that period).
WITH calls AS (
SELECT
IF(block_date <= DATE '2026-03-14', 'first_30d', 'last_30d') AS period,
receipt_receiver_account_id AS contract
FROM `bigquery-public-data.crypto_near_mainnet_us.receipt_actions`
WHERE (block_date BETWEEN DATE '2026-02-13' AND DATE '2026-03-14'
OR block_date BETWEEN DATE '2026-10-14' AND DATE '2026-11-12')
AND action_kind = 'FUNCTION_CALL'
),
per_contract AS (
SELECT period, contract, COUNT(*) AS function_calls
FROM calls
GROUP BY period, contract
),
ranked AS (
SELECT
period,
ROW_NUMBER() OVER (PARTITION BY period ORDER BY function_calls DESC, contract) AS rank,
contract,
function_calls,
function_calls / SUM(function_calls) OVER (PARTITION BY period) AS share
FROM per_contract
)
SELECT period, rank, contract, function_calls, share
FROM ranked
WHERE rank <= 25 OR contract = 'intents.near' -- intents.near is kept even outside the top 25
ORDER BY period, rank
Open the BigQuery console (the sandbox is free and needs no card), paste a file from queries/, Run, then Save results → CSV (local file) as data/bq/<name>.csv. Or: bq query --use_legacy_sql=false --format=csv --max_rows=1000 < queries/x.sql > data/bq/x.csv. Then python3 run.py.
run.py never reads these files, so the headline numbers and the result hash do not depend on an account with Google. Each CSV's sha256 is shown under its chart.
The 1Click Swap API terms (section 4.1(e)) forbid keeping its data beyond 24 hours, so a committed copy could not be re-checked. Intents volume and fees come from DefiLlama's public series instead.
Each round was frozen before the epochs it describes existed, and its hash is anchored with OpenTimestamps. run.py refuses a round that is not exactly what the code derives from the data up to its height.7
Both open rounds close in this window, each scored by mainnet when it does. Historically the payback band has held 82% of the time, so an occasional miss is expected even when the model is right, and a pass near the bounds is weak support.
| Frozen | Window | Committed payback | Actual | Epochs closed | Verdict |
|---|---|---|---|---|---|
| 2026-11-12 | 5 epochs | 6.9% to 27.2% | 14.9% | 5 of 5 | PASS |
| 2026-11-12 | 10 epochs | 6.3% to 30.8% | pending | 7 of 10 | PENDING |
| 2026-11-12 | 20 epochs | 6.9% to 26.8% | pending | 7 of 20 | PENDING |
Python 3.9 or later, no packages, no keys.
$ git clone https://github.com/nice-bills/Coverage
cd CoverageEvery figure on this page, from the cached chain data, in about two seconds with no network. Below is the output of the build that produced this page, ending with the result hash.
$ python3 run.py ... summary values printed above, as in out/results.json LEDGER round-224265136-h05.json: 5/5 epochs closed -> PASS LEDGER burn_total: 1193.06 to 1879.68, actual 1407.28 -> HIT LEDGER buyback_total: 7317.79 to 35576.2, actual 17739.3 -> HIT LEDGER payback: 0.0690182 to 0.272094, actual 0.149362 -> HIT LEDGER round-224265136-h10.json: 7/10 epochs closed -> PENDING LEDGER burn_total: 2173.99 to 3553.67, actual None -> PENDING LEDGER buyback_total: 14073.0 to 86747.8, actual None -> PENDING LEDGER payback: 0.0627287 to 0.307977, actual None -> PENDING LEDGER round-224265136-h20.json: 7/20 epochs closed -> PENDING LEDGER burn_total: 2819.73 to 6523.96, actual None -> PENDING LEDGER buyback_total: 34148.4 to 133348.0, actual None -> PENDING LEDGER payback: 0.0687373 to 0.267913, actual None -> PENDING RESULT sha256=a214eaa40dbd90f2e2d453838be6857b27391c1d948e1eb253b2257668d6940d
Recorded by GitHub Actions at 2026-11-14 23:59 UTC: the log of that run. Every run's full log is public.
Scoring maths, data hashes, and refusal of a cache or a forecast round with one value changed.
$ python3 test_run.py SELFTEST PASS
Recorded by GitHub Actions at 2026-11-14 23:56 UTC: the log of that run. Every run's full log is public.
Random epochs are refetched from the chain and must match the cache exactly.
$ python3 verify.py 3 20261112 verify.py n=3 at 2026-11-12 21:00:39 UTC, sources https://archival-rpc.mainnet.fastnear.com and https://mainnet.neardata.xyz epoch 194629925-194673124: MATCH mint=26891.134 burn=163.969 NEAR epoch 220247534-220290733: MATCH mint=26829.968 burn=239.643 NEAR epoch 207676334-207719533: MATCH mint=26461.174 burn=155.027 NEAR VERIFY seed=20261112 PASS (3/3 epochs match the chain, 6 blocks checked against their parents)
Recorded 2026-11-12 21:00:39 UTC with seed 20261112, in VERIFY.txt. Pick your own seed: the free endpoints rate-limit, so the scheduled job does not run it. The “Check a random epoch” button in chapter 02 does the same check in your browser.
Fetch the epochs that closed since; run.py prints PASS or FALSIFIED per round (the LEDGER lines above).
$ python3 fetch.py --epochs 45 && python3 run.pyout/results.json, as README.md statesa214eaa40dbd90f2e2d453838be6857b27391c1d948e1eb253b2257668d6940dRESULT line python3 run.py printeda214eaa40dbd90f2e2d453838be6857b27391c1d948e1eb253b2257668d6940da214eaa40dbdSet in Instrument Serif & Inter. Teal comes back to the token; terracotta is burnt.