# MethodsDefinitions and the reasoning behind every derived number. The code is the final word: `pipeline/analyze.py`, `pipeline/analyze_explorer.py`, `pipeline/sql/`.## Sources| Source | Key needed | Used for ||---|---|---|| NEAR public RPC (FastNEAR, near.org), archival RPC | No | Protocol parameters, validators, wallet balances, contract views || BigQuery `bigquery-public-data.crypto_near_mainnet_us` | Free Google account | Mint and burn from block headers, signers, cohorts, funders, gas by contract, token flows || NEAR Intents Explorer API | Free read-only JWT from partners.near-intents.org | Swap-level volume, partners, app fees, user cost || DefiLlama | No | Intents volume and fees, rival rails, chains, stablecoins, comps || revenue.near.org | No | The official claims we test || CoinGecko, Coinbase | No | Prices and market caps, with a cross-check || NearBlocks | No | Long daily series || GitHub API | No (token raises the limit) | Core repo activity || nrretf.com | No | ETF holdings |The official revenue dashboard is our primary series for Intents volume, fees and revenue. DefiLlama's adapter reads overlapping Dune tables. Daily volume matches to the dollar only since 2026-09-01, official volume ran 9-15% higher in June to August, and monthly revenue differs in both directions, because DefiLlama counts NEAR when it is swept into wallets. Monthly revenue is therefore the finest grain we trust, and the rail comparison uses DefiLlama for all four rails so they are measured alike.## Supply`total_supply` in a block header rises only at an epoch's first block and falls only when fees burn. Summing positive and negative block-to-block differences gives gross mint and burn with no assumptions. `BigQuery total_supply` is a FLOAT64, so each difference carries rounding near 3e-7 NEAR, far below the per-block burn. We check BigQuery against archival RPC headers on five dates.## Treasury share`EXPERIMENTAL_protocol_config` reports `protocol_reward_rate: [0, 1]`. That is not what mainnet does. `chain/epoch-manager/src/reward_calculator.rs` hardcodes 1/10 when the genesis protocol version is 29, and `treasury.near` receives about 2,585 NEAR an epoch. We use 10%.## Activity tiers- **Signers:** distinct `signer_account_id` in a month.- **Active on 2+ days:** signed on two or more days that month.- **Engaged:** signed on three or more days and reached two or more contracts.- **Engaged, self-custody:** engaged, not in the `.tg`, `.sweat` or `kaiching` namespaces, and under 3,000 transactions a month.These filters remove obvious non-use. They do not prove that an account is one human.## CohortsA signer's cohort is the first month it signed anything, computed over the full chain history. Retention at month k is the share of a cohort that signed in month k.## FundersFor the two sample months, the first non-system `Transfer` or `CreateAccount` receipt into each account names its funder. "Effective funders" is the inverse Herfindahl of funder shares. Accounts touched are not all new accounts, so read this as concentration, not as a new-user count.## On-chain check of Intents volumeFor each token, `ft_mint` or incoming `ft_transfer` into `intents.near` is a deposit, `ft_burn` with a `WITHDRAW_TO:` memo is a withdrawal to another chain, and outgoing `ft_transfer` is a transfer out. We price each week at that week's coin price and define one-way flow as `(deposits + withdrawals + transfers out) / 2`.This misses internal swaps, confidential intents and tokens bridged as NEP-245. It also includes solver rebalancing: per token, inflow equals outflow over months, so solvers move inventory through the same contract. With full rebalancing, deposits plus withdrawals would be twice user flow, so 61% could be closer to 30%. The ratio has held at about 0.5 to 0.6 while volume rose many times over, which may be mechanical. It shows that settled flow is real. It does not measure end-user demand.As a rough lower bound we use withdrawals outside the top 100 addresses. Large addresses may be solvers, exchanges or real whales, and the tail may hold bots, so this is a heuristic. One week in October 2025 shows a 47M SOL deposit and same-day withdrawal, about 26x reported volume. We use medians, so it does not affect the ratio.## Swap sampleThe Explorer API allows one request every 5 seconds and covers 1Click swaps. We take one full UTC day per ISO week from 2025-12-01, with the day chosen by `sha256(week start)`, so the draw is reproducible and not hand-picked. That gives 47 days and about 900,000 swaps. App-fee dollars are the stated basis points times `amountInUsd`. Stated app fees do not include 1Click's own share, so the implied fee outside the Explorer is an upper bound. Sender and recipient addresses are kept only as a truncated, unsalted hash on the crawl machine. Only aggregates are committed, and they name partners and large fee collectors. App-fee dollars are the stated basis points times `amountInUsd`.## User cost`(amountInUsd - amountOutUsd) / amountInUsd`, median by size bucket. This includes every fee and all spread, and it depends on the API's USD valuation at quote time.## Pricing-power tests**Event tests.** Two dates, with rival rails as controls. Take rates are pooled from official monthly revenue over official monthly volume, because weekly DefiLlama revenue is lumpy sweeps. Share is pooled over the weeks either side. The interval is a bootstrap of weeks on the ratio of Intents volume to the sum of THORChain, Chainflip and Maya, after over before. These are before-and-after comparisons and cannot rule out other changes in the same window. The first date is when the partner revenue share went live, not when capture began.**Partner fee steps.** A partner's average fee moves with its route mix, so it cannot be read as a price. We use the posted fee: the most common total fee across its swaps on a sample day, for days with at least 20 swaps. An event is a step of 3 bps or more that holds across four sample weeks either side. The outcome is the change in the partner's share of Explorer dollars, four sample weeks after against four before. Partners choose their own fees, so a fee rise may come with other changes, and a small share change does not prove that users ignore fees.## Lead-lag testWeekly log changes from February 2025, with two weeks dropped around the kaiching exit. For each usage measure (burn, active accounts) and horizon (1, 2, 4 weeks), we compare the extra R² from adding Intents volume or price to a usage-only model. Intervals use a block bootstrap with blocks of six weeks, and one result sits close enough to zero to flip with the seed. Out-of-sample error is walk-forward from week 40, with overlapping training rows purged.## Valuation`docs/model.js` and `pipeline/model.py` are the same maths, and `tests/test_model.py` proves they agree. Holder earnings are captured revenue times a claim share. Value is five years of discounted earnings, plus an exit multiple on year-5 earnings, plus a stated value for NEAR as a chain apart from Intents. Chain fees sit inside chain value, so they are not in earnings. All cases use one discount rate, because risk is already in the weights.Value is for the average holder. Staking rewards move value from non-stakers to stakers, so a staker does better than this and a non-staker worse. Only the 10% treasury share and validator commission leave the holder base each year. That is why issuance barely moves the model, even though offsetting it is NEAR's stated goal.All inputs and reasons live in `thesis/scenarios.json`.