Methodology

Every number on this site is computed by an open, deterministic pipeline from cited public sources, on an hourly schedule. This page describes the computation exactly. When the pipeline changes, this page changes in the same release.

Data sources

• Stablecoin supply and per-chain breakdown: DefiLlama's public stablecoins API (stablecoins.llama.fi). USDT and USDC circulating supply, per chain.
• Native token prices (ETH, SOL, TRX, POL, BNB, AVAX): CoinGecko's public price API.
• Gas prices: public JSON-RPC endpoints. On the EVM chains the price is measured from recent blocks rather than quoted: each block is read whole (eth_getBlockByNumber) and the price every transaction in it actually paid is recovered from its own fields — base fee plus the tip that fit under the sender's ceiling for EIP-1559 transactions, the stated price for legacy ones. The figure published is the median across a rolling window of at least 12 blocks and 500 transactions, widened on quiet chains until it holds enough to take a median of. Every snapshot records the exact block range it read, so any figure can be recomputed from the chain. Chain-operated system transactions, which pay nothing, are excluded. getRecentPrioritizationFees on Solana (official RPC); the current energy price from Tronscan's public chain-parameters API for Tron.
• Regulatory items: the official press RSS feeds of the Federal Reserve, the SEC and the ECB, filtered by keyword. Nothing is scraped from third parties.

No API keys are used. Failed fetches never fabricate data: if a source is unreachable, the previous run's value is shown with a visible stale badge, and every panel carries its last-updated date.

Measuring the gas price rather than asking for it is deliberate. eth_gasPrice, the usual shortcut, is not an observation: it is an undocumented heuristic by which the node you happen to ask suggests a price for a transaction you are about to send. Different nodes give different answers, and there is no way to ask it what a block from last year cost — which makes a consistent historical series impossible to build. What a transaction paid is recoverable from the block that contains it, at the head of the chain and equally at any depth, so one method covers the whole series.

Estimated transfer fee per chain

The estimated USD fee for a single stablecoin transfer:

• EVM chains (Ethereum, Arbitrum One, Base, Polygon PoS, BNB Smart Chain, Avalanche C-Chain, OP Mainnet): median paid gas price (wei) × gas units × native token USD price ÷ 10¹⁸, with a fixed estimate of 65,000 gas per ERC-20 transfer (a plain USDT transfer uses ≈63k; transfers to fresh addresses cost more).
• Solana: base fee of 5,000 lamports per signature, plus the median recent prioritization fee applied to an assumed 200,000 compute units, converted at the SOL price.
• Tron: current energy price (sun per energy unit) × 65,000 energy — a typical TRC-20 USDT transfer to an established address (transfers to fresh addresses cost roughly double) — converted at the TRX price. Bandwidth costs are ignored as negligible relative to energy.

The Paycoin Index

The Paycoin Index is the blended cost of moving $1,000 of stablecoin value across the tracked rails, expressed in basis points:

1. Compute the estimated transfer fee for each tracked chain, as above.
2. Weight each chain's fee by the combined USDT + USDC circulating supply on that chain (DefiLlama), so the index reflects where stablecoins actually live rather than treating all chains equally.
3. Divide the weighted average fee by $1,000 and express as basis points (index = avg fee ÷ 1000 × 10000).

Chains with missing data on a given day are excluded from the weighting that day. The full daily history is available as JSON under /data/.

The Paycoin Rail Score

Alongside the cost-only index, each tracked rail carries a Rail Score from 0 to 100 that blends three perspectives on the same cited inputs:

1. For each axis — transfer fee, typical finality time, and USDT + USDC supply on the chain — take log₁₀ of the value and normalise it linearly to [0, 1] across the tracked rails, so the best rail on that axis scores 1 and the worst scores 0. Fee and finality are inverted (cheaper and faster mean higher scores).
2. Blend the axes as score = (0.5 × cost + 0.3 × liquidity + 0.2 × speed) × 100, rounded to the nearest integer.

The score is relative to the tracked set: adding or removing a rail, or a change on any rail, can move every score. It is a comparison aid, not an absolute quality measure — the headline Paycoin Index remains the pure supply-weighted cost figure, because a cost in basis points is verifiable against sources in a way a composite score is not. Finality times are the fixed typical values listed above, not live measurements.

Known limitations

• Figures cover the on-chain transfer leg only — no on/off-ramp, FX, custody or compliance costs, which dominate real-world end-to-end payment costs.
• Gas-unit and compute-unit figures are fixed typical values, not per-transaction measurements.
• Rollup figures cover the L2 execution fee only and exclude the L1 data component, which on OP Mainnet and Base is the larger share of what a sender actually pays. Those two rails are therefore understated, and by more than the others.
• The median is taken across all transactions in the sampled window, not only stablecoin transfers, so it reflects what the chain charged rather than what one class of transaction chose to pay.
• Snapshots are taken hourly and every one is kept; the daily archive keeps the last observation of each calendar day, so a spike between two runs appears in the hourly series but may not appear in the daily record.
• Incumbent-rail comparison figures are static published prices with as-of dates, not live quotes, and the World Bank remittance survey measures $200 sends.
• Records dated before this pipeline existed were reconstructed, and differ from observed records in three specific ways described below.

Reweighting the index yourself

Switching rails off on the front page recomputes the index line over the ones left on, using the same supply weighting on a smaller basket. It is relabelled while you do — Index over 7 of 9 rails, say — because a reweighted average is not the Paycoin Index, and only the full basket should be cited as such.

The control is there because the headline number is dominated by two rails: Tron and Ethereum carry most of the tracked stablecoin supply and most of the cost, so an index without them is roughly two orders of magnitude cheaper. That is a fact about where stablecoins actually sit, and it is easier to see than to describe.

Reconstructed history

The archive reaches further back than the pipeline does. Records for those earlier dates were rebuilt from the same primary sources and are flagged backfilled: true in the data, so anyone citing the series can separate what was observed from what was reconstructed.

This is possible because none of the inputs are ephemeral. Gas is measured from the archived blocks themselves using the identical estimator the live pipeline uses — the same code, not a historical approximation of it — which is the reason the gas-price method was moved off eth_gasPrice in the first place. Native token prices are CoinGecko's daily closes, per-chain stablecoin supply is DefiLlama's daily series, and Tron's energy price is a governance parameter whose every change is published with the date it took effect, making Tron's historical fee exact rather than sampled.

Three things genuinely differ from an observed record:

• Every reading refers to 12:00 UTC on the date. A live record is stamped at whatever hour that day's last run happened, so the two are not sampled at the same time of day.
• Solana carries its base fee only. Its priority component comes from a rolling window the RPC will not serve for a past date. That component currently measures about 0% of a Solana transfer fee, so the omission is small — but it is an omission, not a measurement.
• There is no regulation feed for a past date, so a reconstructed record lists only the sources the index is computed from.

The daily archive is otherwise append-only. It has been rewritten once: when the gas-price method changed from a node's suggested price to the price transactions actually paid, the records already collected under the old method were regenerated under the new one, so that the entire series is measured a single way. Preserving a two-method series would have made the archive's one job — comparison over time — unsound.

Update cadence and staleness

The pipeline runs every hour. A source older than 48 hours is labelled stale wherever its data appears. The build never invents a number: it is either freshly fetched, carried forward and labelled, or shown as unavailable.