How the metrics are calculated

The numbers in this section come from public data and simple formulas - each of them is explained below: what it is based on, how it is calculated and where it stops meaning anything. There is a separate note on why our values may differ from those on other sites: usually it is not an error but a different definition of revenue.

Where the data comes from
Protocol activity comes from an open aggregator that collects fees, revenue and protocol assets from public blockchains. Prices, market cap and quote history come from the "Cryptocurrencies" section's own reference data. The key rate and OFZ yields, where they are needed for comparison, come from our Russian market database. The section does not fill gaps from closed sources and does not buy paid data: everything here is reproducible from public APIs.
How a token is linked to a protocol
The aggregator and our coin reference data share an identifier - an industry-wide one. If it matches, the link is unambiguous and the metrics are published straight away. Matching by ticker is unreliable: the same letters belong to different projects, so such links are published only after a manual check. One token can have several protocols - different exchange versions or several products from one team; their series are added up, and the number of components is shown on the card. Showing someone else's revenue under a token's name is worse than showing nothing.
What the protocol earns
Fees - everything users paid. Revenue is the part of the fees the protocol kept after settling with liquidity providers. For an exchange the difference is substantial: most of the fee goes to those who supplied liquidity, and the protocol keeps a share.

Annual revenue. With a full year of history it is the sum over 365 days. If the protocol is younger, the last quarter is taken and multiplied by 365/90; this is flagged in the table and on the card. For a seasonal business such extrapolation overstates the result - a quarter with a burst of activity turns into "annual" revenue that never existed.

90-day growth is the last 90 days against the previous 90. It reveals a turn in the trend that the annual total has not yet shown.

Revenue per dollar of assets is annual revenue divided by the assets currently in the protocol. Comparing it across categories is pointless: an exchange earns on turnover even with small balances, while a lending protocol earns on the rate spread and needs large ones.
What the holder gets
We use the aggregator's holders revenue metric - the part of revenue that went to token holders through buybacks, distribution or burning. Holder yield is that sum over 365 days relative to current market cap.

The metric is tagged for a minority of protocols. Where it is not tagged we show a dash, not a zero: zero and "unknown" are different things. Zero means payouts are tracked and there were none over the year; a dash means the source simply does not count them. Either way it is a fact about the past year: distribution rules are set by project governance and can change at any moment.
Issuance
We have no separate series for the number of tokens in circulation, so it is derived: market cap divided by price for the same day. The issuance rate then is today's supply against the supply 90 days ago, annualised; the dollar figure is the quarterly supply increase multiplied by the average price over the same period.

Price and market cap are not captured in the same second, so this method is noisy on daily changes, while over a quarter the error is immaterial. For the same reason we do not show daily issuance - only the annual rate.

Issuance to revenue above one means that over the year more tokens were handed out than the protocol earned. That is not a verdict on the project: handing out tokens can make sense when it brings users who stay. But a counter-flow of sellers does exist, and a holder should know about it.

The last line of the block is how many times the fully diluted valuation exceeds the valuation of the circulating part. We do not keep an unlock calendar: free sources have incomplete ones, and an incomplete unlock schedule misleads more than its absence.
Sustainability
Monthly revenue spread - the standard deviation of monthly totals over 12 months divided by the mean. A value around 0.2–0.3 indicates a steady flow, above one means the annual total is made up of two or three good months. It is calculated on at least six full months.

Share of the largest chain - what part of the protocol's assets sits in one chain. The closer to 100%, the more the protocol depends on that chain's health and fate.

Share of rewards in pool yields - how much of the rate the user sees rests on token handouts rather than fees. Individual pool rates are not published in this section, only that share.

Age is counted from the date the protocol appeared in the aggregator. It is close to the launch date but can differ by a few months if the project was not listed straight away.
Valuation
P/S - market cap divided by the protocol's annual revenue. Diluted P/S is the same with the valuation of all tokens, including unissued ones. The meaning is the same as a stock's P/S: how many years of revenue the project costs today.

Rank in category is the share of projects in the same category with a lower P/S. It is calculated once at least four projects in the category have a multiple.

Multiples are calculated only for annual revenue of $100.0 k or more and history of at least 90 days. Below that threshold the divisor is too small: a single random week of high fees changes the result several times over.

Comparison with the equity market. For some categories we quote the closest Russian market industry and its median P/S. There are no ready-made sector multiples in the equity database, so we calculate them ourselves: the company's price multiplied by its share count and divided by the revenue of the last reported year (no forecasts); the median covers industries with at least three companies. The current mapping is: AI agents — IT (2.10×); Blockchain — IT (2.10×); Exchange aggregators — Finance; Distributed computing for AI — IT (2.10×); Derivatives — Finance; Developer tools — IT (2.10×); Exchanges — Finance; Gaming — IT (2.10×); Payments — Finance; Prediction markets — Finance; Real-world assets — Finance; Layer 2 network — IT (2.10×). Protocol revenue and company revenue are measured by different rules, so the comparison gives a sense of the order of magnitude, not equality of metrics. We do not offer such a comparison for banks and insurers: their revenue is formed differently, and P/S says little there.
Behaviour in a portfolio
Everything in this block is calculated on daily prices from our database; aggregator data plays no part here. Link to bitcoin is the correlation of daily price changes over 90 and 365 days. Beta is the covariance of the asset's and bitcoin's returns divided by the variance of bitcoin's returns: how many times more strongly the asset reacts to a market move. Maximum drawdown is the deepest fall from a previous high over the year, next to it is how many days it took to return to that high. Behaviour on days bitcoin falls is the asset's average result on days when bitcoin lost more than 5%; it is calculated with five or more such days.

Correlations require at least 60 common trading days, beta 120. The series are aligned by date: calculating on mismatched days is meaningless.
Why the figures differ from other sites
There is no single definition of revenue in this industry. Some sites count all fees as revenue, others only the protocol's share, others still add treasury income or subtract rewards. We use one definition and do not mix it with others. Market cap comes from our own reference data, not from the protocol aggregator - which is why the multiple may differ from the one calculated at the source. Finally, our values are a snapshot of a daily calculation, not a live figure: the calculation date is shown in the footer of every page in this section.
What this section does not have
There are no composite scores or asset ratings here: revenue, issuance and risk can only be merged into one score through arbitrary weighting, and it would read as a recommendation. There are no revenue forecasts or promises of returns - every number refers to past periods. There are no lists of pools with specific rates, no links to exchanges, converters or the protocols themselves. The section describes the properties of assets and does not suggest what to do with them.
This material is informational and is not an individual investment recommendation. FairValue does not carry out transactions in digital currencies. Past performance does not determine future results.

FairValue is an information and analytics service of FairValue LLC (Kyrgyz Republic, registration number 334560-3301-ООО, TIN 02909202610352). Publicly available materials, quotes, ratings, model estimates and model strategies are intended for your own review and are not individual investment advice, a representation that an instrument is suitable for you, or a guarantee of returns. They do not constitute an offer to carry out a financial transaction on behalf of the Administration.

The AI assistant may take into account the portfolio details you enter. Its answers are generated automatically, may contain errors and do not replace a professional assessment of your circumstances or an independent verification of the data. Historical results, forecasts and backtests do not guarantee future results; quotes may be delayed. Transactions in financial instruments and digital assets involve the risk of partial or total loss of funds. You make investment decisions on your own. These warnings do not exclude the Administration's liability in the cases provided for by mandatory provisions of law.

The main server is located in Moscow. When you use the AI and email features, data may be transferred to external providers in China, the United States and, when switched to the backup, in France; other routes are disclosed in the Policy. The laws of the Kyrgyz Republic apply, as do mandatory provisions of the laws of the Russian Federation in the cases they provide for. See the Privacy Policy, Cookie Policy and User Agreement. Contact: info@fv.market.