> For the complete documentation index, see [llms.txt](https://docs.llama.fi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.llama.fi/analysts/data-definitions.md). # Data Definitions ## Value Locked ### Total Value Locked (TVL) For protocols: Value of all coins held in smart contracts of the protocol For chains: Sum of TVL of the protocols in that chain In traditional finance terms, TVL is similar to Assets Under Management (AUM). It represents the total value of assets that users deposit into a protocol. This is similar to how a fund or bank might report the total value of client deposits or managed assets. TVL is meant to be a proxy for the skin in the game / risk taken by depositors, so we only count assets that were actually deposited by users and are exposed to the protocol. The main exclusions: * **Borrowed coins**: assets borrowed from a lending protocol are not counted towards its TVL, only the coins actually locked in the contracts are. Among other reasons, this avoids inflating TVL through cycled lending (deposit, borrow, re-deposit the same coins). Borrows are tracked as a separate metric instead. * **The protocol's own tokens**: governance tokens staked in the protocol are tracked under Staking, and LP positions where one side is the protocol's own token are tracked under Pool2 (see [TVL categories](#tvl-categories-tracked-separately) below). These tokens are minted by the team, so depositing them costs users nothing comparable to depositing outside capital. * **Tokens minted by the protocol itself**: for example LUSD deposited back into Liquity is not counted, because the collateral backing that LUSD is already counted as TVL. * **Non-circulating and vesting tokens**: tokens that are not circulating or are yet to be issued are excluded (a token with a 10M market cap and 1B FDV could otherwise show 500M of "locked" tokens). * **Double counting**: when receipt or LP tokens from one protocol are deposited into another protocol, the second protocol is flagged as double-counted so the same underlying capital isn't summed twice into chain and global TVL. Users can toggle this on dashboards. * **Chain TVL**: native token staking (e.g. ETH PoS staking, ADA staking) is never counted, since it would overshadow DeFi TVL and turn chain TVL into a proxy of the token's market cap. Liquid staking protocols are tracked but not counted towards chain TVL by default. Bridge TVL is not attributed to any chain. * **Unproductive assets**: deposits that take no real risk and serve no function other than inflating TVL (one-sided LPs with no trading activity, lending pools with no borrowers, wrapper assets without verified backing, deposits made purely for points farming) are excluded. See [What to include as TVL](/list-your-project/what-to-include-as-tvl.md). Two litmus tests we apply: if the protocol got hacked, would the money truly be lost? And is the TVL usable and being productive? ### TVL categories tracked separately These are shown as optional toggles next to TVL rather than being included in it by default: * **Staking**: value of the protocol's own governance tokens staked in its staking system (e.g. veCRV, stkAAVE). Excluded from core TVL because it exists independently of protocol traction and the protocol could always cover a loss by minting more governance tokens. * **Pool2**: staked LP tokens where one side of the pair is the protocol's own governance token. These farms mainly incentivize holding or providing liquidity for the protocol's token rather than reflecting outside capital. * **Borrowed**: value borrowed from a lending protocol. Kept separate from TVL to avoid inflating it through cycled lending. * **Vesting**: tokens that are not circulating or not issued yet. * **Offers**: funds approved for spending on a non-custodial platform but not actually deposited into its contracts. ### USD Inflows A protocol's TVL might go down even if more assets are deposited in the scenario where the prices of assets comprising TVL go down, so just looking at the TVL chart is not the best way to see if a protocol is receiving deposits or money is exiting, as that info gets mixed with price movements. USD Inflows is a metric that fixes that by representing the net asset inflows into a protocol's TVL. It's calculated by taking the balance difference for each asset between two consecutive days, multiplying that difference by asset price and then summing that for all assets. If a protocol has all of its TVL in ETH and one day ETH price drops 20% while there are no new deposits or withdrawals, TVL will drop by 20% while USD inflows will be 0$. ### Treasury Value of coins held in ownership by the protocol. By default this excludes coins created by the protocol itself, which are instead tracked in a separate Own Tokens category. In traditional finance terms, the Treasury is the protocol's Total Assets. This is what the protocol controls directly, and is often used to fund operations, growth initiatives, or serve as a reserve. ### Assets (for CEXs) This includes all the assets that the CEX has under their custody, excluding any assets that are under a different custodian but are credited inside the CEX for use as collateral. The reasoning is that this metric works as a proxy for how safe a CEX is to leave money in; counting assets held at an external custodian would invert that signal during a bank run. ### Bridged TVL (Chain Assets) Value of the assets sitting on a chain, split by origin: assets native to the chain, assets bridged through the chain's canonical bridge, and assets bridged through third-party bridges. Where possible we track the collateral backing bridged tokens on the source chain rather than trusting the minted representation. ### Total Value Secured (TVS, for oracles) Sum of the TVL of all protocols that depend on a given oracle. It estimates the potential financial loss if that oracle malfunctioned or reported incorrect data. The guiding question is: if the oracle failed, would these assets be at risk? ## Fees and Revenue We model protocol fees and revenue as an income statement inspired by GAAP accounting standards, so the metrics below map onto each other: `Revenue = Fees - Supply-Side Revenue`, and Revenue is then attributed between Protocol Revenue and Token Holder Revenue. Rules that apply to every fee and revenue metric: * **Accrual basis**: fees and revenue are counted on the day they accrue, not the day they are paid out or claimed. A year of borrow interest repaid today is not today's revenue. * **Verifiable sources**: numbers come from on-chain data wherever possible. Self-reported figures that cannot be checked against trade-level or on-chain data are not tracked; showing nothing beats showing a wrong number. * **Negative values are real**: realized losses (a vault drawdown, negative yield) are recorded as negative fees rather than clamped to zero, so totals are not overstated. * **One listing per flow**: the same fees are never counted under two listings. Each product or version (spot vs perps, v2 vs v3) is its own listing, and a parent listing sums its children. ### Fees Total fees paid by users when using the protocol. Fees are equivalent to what would traditionally be considered Revenue in most off-chain businesses (Gross Protocol Revenue). They reflect the total amount paid by users for using the service, regardless of where those fees end up. This is the top-line number that shows how much the protocol is facilitating in economic activity. The guiding principle: Fees include everything the protocol could theoretically keep if it took 100% of the value flow. For example, for a lending protocol where depositors get 70% of borrow interest and the protocol keeps 30%, Fees is 100% of borrow interest. For a liquid staking protocol, Fees is all staking rewards generated by the staked assets, not just the protocol's cut. Important boundaries: * Only fees paid by users count. Block rewards and token emissions are incentives (a cost the protocol pays), not fees. * For chains, Fees is only the transaction fees paid by users. Fees of apps built on the chain are counted under those apps' own listings (e.g. Hyperliquid perp trading fees are tracked under the perp listing, not under the Hyperliquid L1 chain). Blockspace auction income such as priority tips paid to validators (e.g. Jito tips) is tracked as its own listing, not inside chain fees, so chains stay comparable. * Fees are the protocol's take, not gross flows. For a marketplace or launchpad, Fees is the fee charged on each sale, not the sale amount itself. * For aggregators, only the aggregator's own charges are its fees. Fees users pay to the underlying DEX or bridge are counted under that venue. * Token taxes and referral or referrer payouts are not fees or revenue; referral shares are at most Supply-Side Revenue. ### Revenue Subset of fees that the protocol collects for itself, usually going to the protocol treasury, the team or distributed among token holders. This doesn't include any fees distributed to Liquidity Providers or other suppliers of capital: `Revenue = Fees - Supply-Side Revenue`. Revenue, in the way we define it here, is closer to Gross Profit in traditional accounting. It's the portion of fees that the protocol keeps for itself after paying out costs to actors like liquidity providers. This is what goes to the team, the treasury, or tokenholders. For chains, Revenue is only the burnt portion of transaction fees (or fees flowing to the chain's treasury). Validator and staker payouts are Supply-Side Revenue. For rollups, the data and blob costs paid to the settlement layer are Supply-Side Revenue, so rollup Revenue is fees minus those costs. ### Supply-Side Revenue Portion of fees distributed to the suppliers of the capital or resources the protocol runs on: liquidity providers, lenders, stakers, node operators, as well as integrators, referrers and creators. In traditional accounting this is the Cost of Revenue. Examples: the LP share of swap fees on a DEX, interest paid to lenders on a lending protocol, staking rewards passed through to stETH holders, blob fees a rollup pays to Ethereum mainnet, trading rebates, creator royalties on an NFT marketplace. Note that stakers of a non-governance token (e.g. stablecoin or LST stakers), vault managers and curators, and an underlying platform's cut of an app's fees are all suppliers, so their share is Supply-Side Revenue, not Token Holder Revenue. ### Protocol Revenue Subset of revenue that is allocated to the protocol's treasury or core team, as opposed to being distributed to token holders. ### Token Holder Revenue Subset of revenue that is distributed to tokenholders by means of buyback and burn, burning fees or direct distribution to stakers. Token Holder Revenue is similar to Dividends in traditional finance terms. It's the part of protocol revenue that is returned to tokenholders through staking rewards, fee burns, or direct payouts. Like dividends, this shows how much value the protocol is distributing back to its investors. It also includes value flowing to governance token holders from external sources: airdrops from other protocols, bribes paid by other protocols to the token's voters, and similar off-protocol income. Bribes and token-transfer taxes, previously separate metrics, are now counted as labeled sub-sections within Token Holder Revenue. Only value reaching the protocol's own governance token counts: a protocol without a token has no Token Holder Revenue, and a protocol that sends all revenue to buybacks has zero Protocol Revenue. Burns count only when funded by actual receipts (fee burns, buybacks paid from revenue). Treasury-funded buybacks and mint-and-burn accounting are not Token Holder Revenue, and buybacks are measured at the fee source rather than at distribution. Note that `Revenue = Protocol Revenue + Token Holder Revenue` is an attribution rule rather than a daily equality: buybacks are often executed on a different day than the revenue that funds them. ### Earnings Revenue minus the value of token incentives the protocol emitted over the same period. This is the closest analogue to Net Earnings / Operating Income: it shows whether the protocol is actually profitable once you account for what it spends on emissions to attract the usage generating that revenue. A protocol can have high revenue and deeply negative earnings if it pays for activity with its own token. ### Incentives Value of tokens emitted by the protocol as rewards: liquidity mining programs, staking emissions, and, for chains, block rewards. Governance token emission schedules are tracked on the Unlocks dashboard (see Unlocks / Emissions below). Incentives are a cost the protocol pays to attract usage, so they are never counted as fees or revenue. ### Annual Operational Expenses Operational costs for salaries, audits... throughout the year. We collect this data mainly from annual protocol reports on their forums, so it's always referencing old data and likely to be outdated up till 1 year. ## Volume and Derivatives ### Volume (DEXs) Sum of the value of all trades that went through the DEX on a given day (spot/swap volume). Each swap is counted once: we count a single side of the trade, never both legs of the same swap. Volume is gross of fees (the amount the user paid in, fee included). Only swaps count. Liquidity adds and removes, deposits and withdrawals, plain transfers, borrows and NFT trades are not volume, and neither are the protocol's own actions (its mint and redeem flows, hedging or rebalancing). Volume is verifiable user action. Ticker feeds that report base and quote volume separately are the same trades in two units, so only one side is used. Volume already counted by another tracked protocol (e.g. a frontend routing to Hyperliquid, a Uniswap v4 hook) is flagged as double counted and excluded from chain and category totals. Launchpads count only volume on their own bonding curve; once a token migrates to a DEX, that volume belongs to the DEX. Wash traded volume is excluded from the final volume numbers. We actively identify and remove it: * For pools with very low fee tiers (like 0.01%) where wash trading is cheap, we apply minimum TVL-percentage rules and only count volume from pools meeting those thresholds. * During farming or points campaigns that incentivize wash trading on low-liquidity pairs, we remove the affected pairs. Incentive-farming volume is excluded even when the trades are real; an implausible volume-to-TVL or volume-to-open-interest ratio is treated as wash trading until explained. * We are extra vigilant on low-fee chains, and we prefer computing volume from on-chain data rather than trusting protocol APIs. ### Aggregator Volume Value of trades routed through a DEX aggregator. We track the overall swap volume of each user trade, not the sum of each underlying route: a swap split across three DEXs counts once at its total value, not as three route legs added together. Aggregator volume represents user intent to trade through the aggregator's interface. It's kept on a separate dashboard from DEX volume because the routed trades are already counted in the underlying DEXs' volume, so adding them together would double count. ### Perp Volume Notional value of perpetual futures trades on a derivatives exchange. Each trade is counted exactly once: we track the taker side only, never taker + maker, which would double every trade. Liquidations are not perp volume (see Liquidations below), and a vault's or market maker's PnL is never a fee. ### Perp Aggregator Volume Perp volume routed through derivatives aggregators, following the same rules as Aggregator Volume (overall trade value counted once, taker side only) and kept separate from the underlying perp protocols' volume to avoid double counting. ### Normalized Volume (Perps) Reported perp volume adjusted for how much of it is actually supported by visible orderbook liquidity. We snapshot exchange orderbooks hourly and compare each market's reported volume against the depth available around the mid price. Volume that could not realistically have traded against that liquidity (wash trading, internal matching, or fabricated prints) is discounted. This provides a standardized, exchange-agnostic way to compare venues whose raw reported volumes are inflated to different degrees. ### Options Notional Volume The underlying value of the options contracts traded or settled. Example: a call option on 10 ETH at a $2,000 strike has $20,000 of notional volume. Notional represents exposure, not the capital that actually changed hands. Only expiring options count; perpetual options are not tracked on the options dashboard. ### Options Premium Volume The premiums actually paid and received for options contracts, the real capital changing hands when positions are opened. We use premium volume as the primary metric for ranking options protocols: notional volume was heavily wash traded (contracts with huge notional value but tiny premiums), which made notional rankings meaningless, while premium volume reflects real usage much better. ### Prediction Market Volume Cash value of collateral traded on a prediction market, with each fill counted once (a fill emits both a maker and a taker row; summing them double counts). Notional contracts traded may be shown alongside as a separate figure. ### Bridge Aggregator Volume Value of cross-chain transfers routed through bridge aggregators. Volume reflects the value being bridged, not the fees paid, and is kept separate from the underlying bridges' own volume to avoid double counting. ### Open Interest Total notional USD value of outstanding perpetual positions that have not yet been settled or closed, snapshotted at the end of the period. Both long and short sides are counted, uniformly for every listing. Unlike volume, this is a point-in-time measurement, not a flow, and it should move roughly with the exchange's TVL. Where the data allows, we also break it down into long and short open interest. Options open interest is not tracked because it is trivially inflatable. ### Liquidations USD value of collateral seized from borrowers in liquidation events during the period. For perp exchanges we additionally track liquidation volume: the notional size of the liquidated positions, which is larger than the collateral lost because of leverage. ## Token and Market Data ### Token Volume Sum of value in all swaps to or from that token across all Centralized and Decentralized exchanges tracked by coingecko. Example: for SBR this was all the volume done on SBR/ANY pairs on FTX, Serum... Data for this metric is imported directly from CoinGecko. ### Token liquidity Sum of value locked in DEX pools that include that token across all DEXs for which DefiLlama tracks pool data. Example: There's a SOL/SBR pool on Orca (Solana DEX) with 25k of TVL on that pool, so this 25k counts towards the liquidity of SBR. ### Fully Diluted Valuation (FDV) Fully Diluted Valuation, this is calculated by taking the expected maximum supply of the token and multiplying it by the price. It's mainly used to calculate the hypothetical marketcap of the token if all the tokens were unlocked and circulating. Data for this metric is imported directly from coingecko. ### Median APY Median APY across DeFi pools tracked by DefiLlama that include a given asset. This is calculated by finding all pools for an asset, then sorting them by APY and finding the median weighted by TVL. ### Stablecoin Market Cap Circulating supply of a stablecoin (excluding burned and non-issued tokens) multiplied by its price, tracked per chain. Chain-level stablecoin market cap is the sum over all stablecoins issued or bridged onto that chain. ### Unlocks / Emissions Token emission and unlock schedules, built from vesting contracts and documented allocations. Used to show how much of a token's supply is already circulating and the size and dates of upcoming unlocks. ### Total Raised Sum of all money raised by the protocol, including VC funding rounds, public sales and ICOs. ## Activity and Other Metrics ### Active Addresses (24h) Number of unique addresses that have interacted with the protocol directly in the last 24 hours. Interactions are counted as transactions sent directly against the protocol, thus transactions that go through an aggregator or some other middleman contract are not counted here. The reasoning for this is that this is meant to help measure stickiness/loyalty of users, and users that are interacting with the protocol through another product aren't likely to be sticky. Only addresses that acted during the day count. An address with an open position or order that it did not touch that day is not active. ### New Addresses (24h) Number of active addresses that interacted with the protocol for the first time that day. New addresses can never exceed active addresses. ### Transactions (24h) Number of transactions sent directly against the protocol's contracts in the last 24 hours, with the same direct-interaction rule as Active Addresses. ### Events This is a manually curated list of events that impacted the protocol. The reason why we display this is just to help the user understand the reason behind changes in the protocol metrics. Example: When there's a hack that causes a sudden drop in TVL we add an event at that date explaining that a hack was the reason why TVL dropped.