# DefiLlama and our methodology We pride ourselves in producing inclusive, non-biased, and community driven statistics for the decentralised finance industry. We do our best to treat all projects equally with regards to what is and isn't included in TVL, how long it takes to list or update a project's TVL, and everything else. ## All Metrics We Track DefiLlama tracks a wide range of metrics across DeFi. Each metric has its own open-source adapter repository where anyone can contribute. If you want to list your project, find the relevant metric below and submit a PR to the corresponding repo. | Metric | Description | Repository | Guide | | ---------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | **TVL** | Total Value Locked in protocol smart contracts | [DefiLlama-Adapters](https://github.com/DefiLlama/DefiLlama-Adapters) | [Guide](/list-your-project/how-to-write-an-sdk-adapter) | | **RWA** | Track value of issued tokens/defi usage | [Submit form](https://forms.gle/Q9wXCmeBzEdK3i8m9) | [Guide](/real-world-assets/real-world-assets) | | **Fees & Revenue** | Protocol fees, revenue, and income statement breakdown | [dimension-adapters](https://github.com/DefiLlama/dimension-adapters) (`fees/`) | [Guide](/list-your-project/other-dashboards) | | **DEX/Perp Volume** | Spot/swap and perpetual trading volume on decentralized exchanges | [dimension-adapters](https://github.com/DefiLlama/dimension-adapters) (`dexs/`) | [Guide](/list-your-project/other-dashboards) | | **Options Volume** | Notional and premium volume from options DEXs | [dimension-adapters](https://github.com/DefiLlama/dimension-adapters) (`options/`) | [Guide](/list-your-project/other-dashboards) | | **Aggregator Volume** | Trading volume routed through DEX aggregators | [dimension-adapters](https://github.com/DefiLlama/dimension-adapters) (`aggregators/`) | [Guide](/list-your-project/other-dashboards) | | **Bridge Aggregator Volume** | Volume routed through bridge aggregators | [dimension-adapters](https://github.com/DefiLlama/dimension-adapters) (`bridge-aggregators/`) | [Guide](/list-your-project/other-dashboards) | | **Yields** | APY and yield data across DeFi pools | [yield-server](https://github.com/DefiLlama/yield-server) | [Guide](https://github.com/DefiLlama/yield-server/blob/master/README.md) | | **Stablecoins** | Circulating supply and peg data for stablecoins | [peggedassets-server](https://github.com/DefiLlama/peggedassets-server) | [Guide](https://github.com/DefiLlama/peggedassets-server/blob/master/README.md) | | **Emissions** | Token emission and unlock schedules | | | | **Oracles TVS** | Total Value Secured by oracle providers | [defillama-server](https://github.com/DefiLlama/defillama-server) | [Guide](/list-your-project/oracles-tvs) | | **Bridges** | Bridge TVL and cross-chain transfer tracking | [bridges-server](https://github.com/DefiLlama/bridges-server) | [Guide](https://github.com/DefiLlama/bridges-server/blob/master/README.md) | | **Token Rights** | Governance, economic, and ownership rights | [Submit form](https://token-rights-teams.llama.fi/) | [Guide](/list-your-project/token-rights) | | **Metadata updates** | Changes to a listed project's name, description, logo, links, etc | Email | | *** ### Our Methodology At DefiLlama we consider the value of any tokens locked in the contracts of a protocol / platform as TVL. Below are some notes about how our calculations work. Valuing different tokens: * Almost all tokens are priced using CoinGecko's API. Where this can't be done, we can accommodate using on-chain methods to quantify the value of a token. This is most commonly done by comparing the pool weights of a very liquid Uniswap V2 market. * We don't count any tokens that are not circulating or are yet to be issued. For example if a team locks a share of their tokens in a vesting contract we won't count these as TVL, since these tokens haven't been issued yet. * We don't double-count within the same protocol. If users can deposit a token, get a receipt token and deposit that in another part of your protocol we'll only count it once. For example Cream has an ETH2 liquid staking token, which can be lent on their money market, we only count it once. Node validators and other chain-native token staking: * We don't count native token staking. For example, ATOM staking to secure the Cosmos hub isn't counted. Liquid staking protocols are tracked but not counted towards chain TVL by default. Bridges: * There are arguments both for including bridge TVL on the origin chain and the destination chain. Therefore we count the TVL of bridge projects but do not contribute them towards the TVL of any chain. Smart Wallets: * We don't count funds in smart contract wallets, such as Argent or Gnosis Safe. In the case of protocols that move money to different chains, TVL is counted on the chain where the users deposited the money and interacted with the protocol. # How to list a DeFi project The majority of adapters on DefiLlama are contributed and maintained by their respective communities, with all changes being coordinated through the [DefiLlama/DefiLlama-Adapters](https://github.com/DefiLlama/DefiLlama-Adapters) github repo. {% hint style="info" %} This page covers listing a **TVL adapter**. For other metrics (fees, volume, yields, stablecoins, emissions, etc.), see the [full list of all metrics we track](/#all-metrics-we-track) with links to each repo and guide. {% endhint %} If you'd like to list a DeFi project on DefiLlama: 1. Fork the [Adapters repo](https://github.com/DefiLlama/DefiLlama-Adapters) (button towards the top right of the repo page). 2. Add a new folder with the same name as the project to projects/. 3. Write an [SDK adapter](/list-your-project/how-to-write-an-sdk-adapter) in the new folder. 4. Make a Pull Request with the changes on your fork, to the main DefiLlama Adapters repo, with a brief explanation of what you changed. 5. Wait for someone to either comment on or merge your Pull Request. There is no need to ask for someone to check your PR as they are monitored regularly. 6. Once your PR has been merged, please give 24 hours for the front-end team to load your listing onto the UI. 7. If protocol is already listed and you want to add a new product/version, just make a new adapter and submit a PR. DefiLlama team will make the necessary changes afterwards (adding all protocols under a parent listing). ## How to build an adapter And adapter is just some code that: 1. Collects data on a protocol by calling some endpoints or making some blockchain calls 2. Computes the TVL of a protocol and returns it ### Next steps You probably need to write an SDK adapter, for which you could use the following guide: {% content-ref url="/pages/-MWjVXR-3Xs62n8bbM\_9" %} [How to write an SDK adapter](/list-your-project/how-to-write-an-sdk-adapter) {% endcontent-ref %} # How to update project metadata If your project's metadata (name, website link, twitter handle, logo...) on DefiLlama is outdated or incorrect, you can submit an update request by sending an email to Make sure to provide proof that the change is legitimate, examples of valid proof are: * For website changes, a banner on the original website that links to the new website, or a redirect * For social media changes, a post on the previous handle about a migration to a new handle * ... On this email you can request changes such as: * Project name * Description * Logo * Website URL * Social media links * Category or tags * Other public project metadata #### Review Process Metadata updates are reviewed manually before being published. Providing clear verification and complete information helps speed up the review process. If additional information is required, the DefiLlama team may contact you for clarification. # How to add a new Blockchain {% hint style="info" %} For non-EVM chains just follow the same steps but instead of picking the shortName from chainlist, make one up that adjusts to your chain. {% endhint %} #### 1. Fork the [DefiLlama-Adapters](https://github.com/DefiLlama/DefiLlama-Adapters) repo #### 2. **Add the Blockchain to `chains.json`** You need to add the name of the blockchain in the `projects/helper/chains.json` file to recognize it as a new supported chain. **Example Change**: ```json "chains": [ "ethereum", "binance-smart-chain", "polygon", "zklink", // Add your new blockchain here. "fraxtal", "zksync" ] ``` You should use the field shortName from *** #### 3. **Add Token Mappings in `tokenMapping.js`** Add the token mappings for the new blockchain to the [`projects/helper/tokenMapping.js` file](https://github.com/DefiLlama/DefiLlama-Adapters/blob/main/projects/helper/tokenMapping.js#L41). This file maps token addresses to their respective identifiers for accurate tracking and handling. **Example Change**: ```js const fixBalancesTokens = { zklink: { [ADDRESSES.zklink.WETH]: { coingeckoId: "ethereum", decimals: 18 }, }, ozone: { '0x83048f0bf34feed8ced419455a4320a735a92e9d': { coingeckoId: "ozonechain", decimals: 18 }, }, }; ``` This ensures tokens on the new blockchain (`zklink`) are properly recognized, including their `coingeckoId` for price tracking and their decimals. *** #### 4. Submit a Protocol **using your blockchain (e.g.,** projects/savmswap/index.js**)** Lastly, update the project’s configuration file to add your new blockchain as a valid supported chain. If we don't track any protocol on your blockchain, we can not add it. So make sure to add the new chain under a current project or add a new adapter to track the project on your blockchain **Example Change**: ```js const { uniTvlExport } = require('../helper/unknownTokens') module.exports = uniTvlExport('zklink', '0x1842c9bD09bCba88b58776c7995A9A9bD220A925') //blockchain, factory address ``` 5. Submit a Pull Request # How to write an SDK adapter ### Adapters 101 An adapter is just some code that takes in a UNIX timestamp and chain block heights, and returns the balances of assets locked in a protocol, including all the decimals (that is, the way it's stored on chain). Our SDK will convert all raw asset balances into their USD equivalent and sum to obtain total TVL, so you need minimal processing inside the adapter. ### Basic adapter Below, you can see the adapter we use for Mint Club on Binance Smart Chain (BSC). Let's walk through it to get a better understanding of how it works. {% code title="projects/mint-club/index.js" %} ```javascript const MINT_TOKEN_CONTRACT = '0x1f3Af095CDa17d63cad238358837321e95FC5915'; const MINT_CLUB_BOND_CONTRACT = '0x8BBac0C7583Cc146244a18863E708bFFbbF19975'; async function tvl(api) { const collateralBalance = await api.call({ abi: 'erc20:balanceOf', target: MINT_TOKEN_CONTRACT, params: [MINT_CLUB_BOND_CONTRACT], }); api.add(MINT_TOKEN_CONTRACT, collateralBalance) } module.exports = { methodology: 'counts the number of MINT tokens in the Club Bonding contract.', start: 1000235, bsc: { tvl, } }; ``` {% endcode %} The adapter consists of 3 main sections. First, any dependencies we want to use. Next, an async function containing the code for calculating TVL (where the bulk of the code usually is). Finally, the module exports. #### Line 4 - Input Parameter: It is an injected `sdk.ChainApi` object with which you can interact with a given chain through `call/multiCall/batchCall` method based on your need, also stores tvl balances {% hint style="info" %} DefiLlama uses a wide variety of sources to price tokens, such as CoinGecko and chain calls to price exotic tokens such as Curve and uniswap LPs. If you find that a token is missing and it's not getting priced in your adapter, just let us know in our discord! {% endhint %} #### Line 5 - On Chain Function Calls Here we use the SDK to get the erc20 token balance of a contract, but this api.call() function can be used to call all sorts of contract functions. Parameters used: * abi - Because we have used a common erc20 function for Mint Club, we're able to use a string for the 'abi' parameter. However for other contract functions you will need to pass a [JSON ABI (or human-readable abi string)](https://www.quicknode.com/guides/solidity/what-is-an-abi) (can find these on etherscan). * target - The target address of the contract call. * params - Optional, must take the same amount of params expected by the on-chain contract function. #### Line 11 - Adding Data To The Balances Object In the SDK we have utilities to add data to the balances dictionary. api.add() takes 2 parameters: 1. The token key you want to add to. We will transform the MINT token address so that we can fetch the CoinGecko price. 2. The balance we want to add. (NB: If we were using a CoinGecko ID in position 2, we'd need to divide collateralBalance by 10 \*\* \ to convert the raw balance to a real balance). Note: if you want to add balances of multiple tokens at the same time, you can do so by running `api.addTokens(tokens, balances)` {% embed url="" %} Example add tokens {% endembed %} #### Line 23 - Module Exports The module exports must be constructed correctly, and use the correct keys, so that the DefiLlama UI can show your data. Nest chain TVL (and separate types of TVL like staking, pool2 etc) inside the chain key (eg 'bsc', 'ethereum'). Please also let us know: * timetravel (bool \[default: true]) - if we can backfill data with your adapter. Most SDK adapters will allow this, but not all. For example, if you fetch a list of live contracts from an API before querying data on-chain, timetravel should be 'false'. * misrepresentedTokens (bool \[default: false]) - if you have used token substitutions at any point in the adapter this should be 'true'. * methodology (string) - this is a small description that will explain to DefiLlama users how the adapter works out your protocol's TVL. * start (number - optional) - the earliest timestamp the adapter will work at. * hallmarks (array of \[number, string]) - set of events that greatly affected protocol TVL and we display on the chart ([example](https://defillama.com/protocol/uniswap)). ### Testing Once you are done writing it you can verify that it returns the correct value by running the following code: ```bash $ npm install # if you want debug logs $ export LLAMA_DEBUG_MODE="true" # Replace with your adapter's name $ node test.js projects/mint-club/index.js ``` If the adapter runs successfully, the console will show you a breakdown of your project's TVL in USD. If it all looks accurate, you're ready to submit. ### Submit πŸŽ‰ Just submit a PR to [the adapter repository on Github](https://github.com/DefiLlama/DefiLlama-Adapters)! # Functions we've written so you don't have to ### Exports Helpers Exporting empty TVL - if your project has filtered TVL only, here's an easy way to export core TVL as empty. ``` module.exports = { bsc: { tvl: () => ({}), staking } }; ``` {% embed url="" %} Example adapter {% endembed %} ### Token balance queries if you have a known set of tokens and contract addresses, there are few ways to fetch and export it as tvl using `sumTokensExport` if single contract and multiple tokens ``` const { sumTokensExport } = require("./helper/unwrapLPs"); module.exports = { fantom: { tvl: sumTokensExport({ owner: '0x..., tokens: [ '0x...',... ], }), } }; ``` if there are multiple contracts to look up: ``` const { sumTokensExport } = require("./helper/unwrapLPs"); module.exports = { fantom: { tvl: sumTokensExport({ owners: ['0x...', '0x...', ...], tokens: [ '0x...',... ], }), } }; ``` if all contracts dont share same set of tokens: ``` const { sumTokensExport } = require("./helper/unwrapLPs"); module.exports = { fantom: { tvl: sumTokensExport({ tokensAndOwners: [ // [tokenAddress, ownerContractAddress] ['0x...', '0x...'], ['0x...', '0x...'], ], }), } }; ``` if any of these tokens are LP tokens, set `resolveLP: true` to resolve them into underlying tokens {% embed url="" %} Example adapter {% endembed %} {% embed url="" %} Example adapter {% endembed %} ### Solana Helpers getTokenBalance is used for getting a solana account's balance of a particular token. ``` const { getTokenBalance } = require("../helper/solana"); ``` {% embed url="" %} Example Solana Adapter {% endembed %} ### Transforming Tokens That Aren't On CoinGecko {% hint style="info" %} DefiLlama uses a wide variety of sources to price tokens, such as CoinGecko and chain calls to price exotic tokens such as Curve and uniswap LPs. If you find that a token is missing and it's not getting priced in your adapter, just let us know in our discord! {% endhint %} To count the TVL of LP token balances, the positions must be unwrapped into their underlying tokens. ``` const { sumTokens2 } = require('../helper/unwrapLPs'); const balances = {}; ... return sumTokens2({ balances, tokensAndOwners: [...], api, resolveLP: true }) ``` {% embed url="" %} Example Unwrap Uni V2 Adapter {% endembed %} ### Getting Block Heights For lesser known EVM chains sometimes the block height wont be available in the third parameter passed to the adapter's TVL function. In this case you can use getBlock to fetch the block height. ``` const { getBlock } = require('../helper/http'); block = await getBlock(timestamp, chain, chainBlocks); ``` {% embed url="" %} Example Get Block Adapter {% endembed %} # Staking and Pool2 The stakings and pool2 functions make it really simple to add any native token TVL. ``` const { stakings } = require("../helper/staking"); const { pool2s } = require("../helper/pool2"); ``` {% embed url="" %} Example Stakings Adapter {% endembed %} If your protocol token isn't on GitHub, you can estimate the USD value of the token using stakingPriceLP. This function will use uniV2 pool weights we determine the value of the staked tokens. (NB: there must be a Uni V2 pool with your coin in, which has significant liquidity. Otherwise the price oracle will be unreliable and vulnerable to manipulation.) ``` const { stakingPricedLP } = require("../helper/staking"); ``` {% embed url="" %} Example Price From LP Adapter {% endembed %} # Fork helpers ### Uniswap V2 There are a few different helpers for Uni V2 forks but we recommend using `uniTvlExport`. ```javascript const { uniTvlExport } = require('../helper/unknownTokens') const chain = 'yourChain' const factory = '0x...' // v2 factory address module.exports = uniTvlExport(chain, factory) ``` {% embed url="" %} Example Uni V2 Adapter {% endembed %} ### Uniswap V3 There are a few different helpers for Uni V3 forks but we recommend using `uniTvlExport`. ```javascript const { uniV3Export } = require('../helper/uniswapV3') module.exports = uniV3Export({ chainX: { factory: '0x...', fromBlock: 'block when factory contract was deployed' }, chainY: { factory: '0x...', fromBlock: 'block when factory contract was deployed' }, }) ``` {% embed url="" %} Example Uni V3 Adapter {% endembed %} ### GMX ```javascript const { gmxExports } = require('../helper/gmx') module.exports = { bsc: { tvl: gmxExports({ vault: '0x...', }) } } ``` {% embed url="" %} Example GMX Adapter {% endembed %} ### Aave ```javascript const { aaveExports } = require("../helper/aave") ``` {% embed url="" %} Example Aave Fork Adapter {% endembed %} ### Compound ```javascript const { compoundExports2 } = require("../helper/compound"); module.exports = { polygon: compoundExports2({ comptroller: '0x...', cether: '0x...', // optional, needed if gas token is used }), }; ``` {% embed url="" %} Example Compound Fork Adapter {% endembed %} ### Liquity ```javascript const { getLiquityTvl } = require("../helper/liquity.js") module.exports = { chainX: { tvl: getLiquityTvl('0x...'), } } ``` {% embed url="" %} Example Liquity Fork Adapter {% endembed %} ### Balancer V2 ```javascript const { onChainTvl } = require('../helper/balancer') module.exports = { metis: { tvl: onChainTvl('0x...', ), } } ``` {% embed url="" %} Example Balancer V2 Fork Adapter {% endembed %} # General EVM contract calls ### Balance Calls use `sumTokens2` method from helper to return token balances For example, you have a vault with USDC and ETH tokens in it in arbitrum ```javascript const { sumTokensExport, sumTokens } = require('./helper/unwrapLPs') const owner = '0x...' // vault address const tokens = [ '0xff970a61a04b1ca14834a43f5de4533ebddb5cc8', // USDC '0x0000000000000000000000000000000000000000', // ETH ] module.exports = { arbitrum: { tvl: sumTokensExport({ owner, tokens }) } } // or module.exports = { arbitrum: { tvl: async (api) => { return sumTokens2({ owner, tokens, api, }) } } } ``` {% embed url="" %} Example ERC20 Token Balance Adapter {% endembed %} ### Custom Contract Calls Contract calls are the most common ways of recording TVL. ```javascript const response = await api.call({}) ``` Often after a single contract call you'll also want to add the balance to your balances object, which can be easily done with sumSingleBalance. ``` await sdk.util.sumSingleBalance(balances, tokenAddress, balanceOfToken); ``` {% embed url="" %} When you have lots of calls to functions with the same ABI, it's easier to use multiCall and sumMultiBalanceOf. ```javascript const tokensInacBTC = [ '0x2260fac5e5542a773aa44fbcfedf7c193bc2c599', '0xEB4C2781e4ebA804CE9a9803C67d0893436bB27D' ]; const acBTCTokenHolder = '0x73FddFb941c11d16C827169Bb94aCC227841C396'; const underlyingacBTC = await api.multiCall({ calls: tokensInacBTC.map(token => ({ target: token, params: [acBTCTokenHolder] })), abi: 'erc20:balanceOf', withMetadata: true, }); sdk.util.sumMultiBalanceOf(balances, underlyingacBTC); ``` {% embed url="" %} Example MultiCall Adapter {% endembed %} # What to include as TVL? ### TVL Total value locked inside a platform / protocol's own contracts by users. ### TVL Filters We separate TVL into different types. This lets users decide what they do and do not want to include in the dashboard data. These types are: * Staking - the platform's own tokens * Pool2 - staked LP tokens where one side of the market is the platform's own governance token. * Borrows - deposits borrowed from the platform * Vesting - Tokens that are not circulating or not issued yet. This mostly applies to vesting protocols where a token with 10M mcap and 1B FDV could have 500M locked, in these cases it makes no sense for TVL from that token to be 500M when mcap of it is only 10M * Offers - funds that are approved for spending on a non-custodial platform, but not actually deposited into the platform contracts ### Not TVL * Assets that aren't on the blockchain, such as bonds or fiat currency. We don't consider the dollars stored on Tether's bank account as TVL, for example. * We also don't accept assets that your protocol generates and are locked into other protocols, as that's the later protocols TVL, not your project's. See [this](https://github.com/DefiLlama/DefiLlama-Adapters/pull/60#issuecomment-807045050) for rationale. * We don't count native token staking. For example, ATOM staking to secure the Cosmos hub isn't counted. ### Edge Cases * **Real-World Assets (RWA)**:\ At present, we only track the tokenization of real-world assets (RWAs), such as bonds, treasuries, and real estate. Only tokenized representations of these assets, issued and traded on the blockchain, are counted towards TVL. ### Unproductive Assets We are improving the Total Value Locked (TVL) metric by removing unproductive or artificial liquidity. Some assets are deposited only to earn rewards or boost metrics without taking real market risk or providing value to users. These positions often come from a small number of large wallets and do not support actual liquidity for the ecosystem. In some cases, TVL may also be inflated through circular or non-backed assets, making the data misleading. Our goal is to ensure TVL reflects real economic activity and remains transparent for all users. While we are not placing blame on any team or chain, there may be instances where whales or large liquidity providers attempt to farm incentives without taking meaningful risks. We have also observed cases where unproductive assets are included in TVL through undisclosed arrangements or recycled liquidity. We understand that some projects may have adopted these practices to remain competitive or support growth during early stages. However, these positions can distort the perception of real usage and user participation. There are common cases to be considered: * Liquidity pools with a few providers and no trading activities. * Assets deposited into lending pools with a few lenders and no borrowers. * Assets deposited into yield/staking pools from a few depositors only to earn points or rewards. * Wrapper assets that lack verified or provable backing. * Assets without real user deposits or that can no longer be withdrawn by users. Our intention is not to call out or discredit any individual protocol. Instead, we want to give all teams and chains the opportunity to align with a more accurate and honest standard. By excluding these unproductive assets, we ensure that TVL remains a reliable and trustworthy metric. This supports meaningful liquidity, real user engagement, and a more representative measurement of value across DeFi. Our commitment is to provide the community with accurate data, improve transparency, and ensure fair representation for all participants in the ecosystem. ### Unproductive Assets-Protocol List #### Momentum We removed TVL from unproductive liquidity pools, these pools have BTC wrapper assets with no trading activities: * YBTC.B/satYBTC.B - 0x584e68589d2ce655c47fa88d75090258c0d8b5b16c3d643e0ddc2b71e81e6546 * MBTC/brBTC - 0xb64d0313a3a542e3d8f8066df767e2459d356377ca15ff003ef5e16629569b4d * BTCvc/eBTCvc - 0x1d182ec3743611393c06e810662dcf70efcfd2e16d855dfdb4dee6abc1bf9ce0
#### DeSyn Liquid Strategy We removed TVL from unproductive vaults. These vaults have only a few depositors, no users deposits. We removed vaults on these blockchains: * BSC * Mode * Ethereum * Plume * Core * Hemi * B2 Network * GOAT Network * AILayer * Bitlayer #### Saros DLMM We removed unproductive pools on Saros DLMM that have only a few liquidity providers with no trading activities: * UNIBTC/XBTC - 7hc6hXjDPcFnhGBPBGTKUtViFsQuyWw8ph4ePHF1aTYG * BFBTC/CBBTC - 9BJ1xTWSuSTqSpgh6fuCmsArHNVA2Fmu5PtDmC6kTAF6 * BFBTC/UNIBTC - HtyaKeqMTd9o289XKZWc8CSJTdp8xABgXrRDWw1wp96W * BFBTC/WBTC - DfohHvQNtXdN7ZgB6AQxNZiqNm2u528mAhY8MTeNEcAd * BFBTC/ZBTC - 66AFL6NKwwKkWr5bbvigviEcMzWCMXWhypch1KsQhoCH * UNIBTC/WBTC - J5ix1fmNfLfpyYr5MDVw4U9dqqCNG8oVvrSkGF3cTwtB #### Stream Finance We removed looping/leverage assets from Stream Finance vaults. There are wallets deposit some initial USDC, WBTC, ETH on ethereum to mint xUSD, xBTC, xETH , they bridge xUSD, xBTC, xETH to other chains, they used xUSD, xBTC, xETH as collateral to borrow USDT, USDC, deUSD, they use swap all borrowed tokens to USDC, WBTC, ETH, deposit back to xUSD, xBTC, xETH We removed all bad debts from Stream Finance after their financial loss report: #### Cygnus We delisted Cygnus from our website because we detected they mint and stake unbacking assets BTC and ETH. #### unagiswap We removed unproductive liquitiy pools that have a single liquidity provider with no users trading activities. * USDa/sUSDa pool with 70M - 0x332df42cf1c2c4874edb62f1f498424d2c2e928a #### Avalon Finance We removed BTC wrapper assets with no borrow from lending pools. * Merlin - WBTC * Kaia - USDa * BoB - SolvBTC, SolvBTC\_BBN * Taiko - SolvBTC * BSC - USDX, sUSDX #### Sumer.money We removed unproductive assets with no borrow from lending pools. * Meter - suUSD, suETH * Base - suUSD, suETH * Arbitrum - suUSD, suETH, suBTC * Ethereum - suUSD, suETH, suBTC * Core - suUSD, suBTC, solvBTC.m * Berachain - suUSD, suBTC * Hemi - suUSD, suETH, suBTC, brBTC * Bitlayer - suBTC * GOAT Network - suETH, suBTC, enzoBTC * ZkLink - suBTC, solvBTC.m, M-BTC, solvBTC.b * B2 Network - suUSD, suBTC * Monad - suUSD #### Segment Finance We removed satUSD token from lending pool which has no borrow on BoB chain. #### VaultCraft We removed TVL from unproductive vaults. These vaults have only a few depositors, no users deposits. Ethereum: * 0xcF9273BA04b875F94E4A9D8914bbD6b3C1f08EDb * 0x77e88cA17A6D384DCBB13747F6767F30e3753e63 * 0xdB06a9D79f5Ff660f611234c963c255E03Cb5554 Base: * 0x023577b99e8A59ac18454161EecD840Bd648D782 Hemi: * 0x748973D83d499019840880f61B32F1f83B46f1A5 * 0x0b8E088a35879f30a4d63F686B10adAD9cB3DBE1 #### iZiSwap We removed unproductive liquitiy pools that have a single liquidity provider with no users trading activities. Hemi pools: * bfBTC/hemiBTC - 0x469a5066578e22a1222cc78b2ccaca602db6bb4a * bfBTC/hemiBTC - 0xFE1c507Be86F977B61d12D1DA3c95D0dEeB1B86A * brBTC/suBTC - 0x98a3a18583138474aedd2ceec034cba1fa783613 * mBTC/uniBTC - 0xe9635693b7606f1914c0cd698065ec84267a62a1 Taiko pools: * mBTC/uniBTC - 0x5e1e8c9c77b0de88f1c4597a3c145b0c7abcf485 #### Bluefin AMM We removed TVL from unproductive assets in liquidity pools that have no users trading activities * BTCvc-vBTCvc - 0x90811fd5409c14d29ec40f59bf7158c52dffa20bc11eb33873670addbf149aa2 #### Pell Network We removed TVL from unproductive assets in vaults that have a few deposit addresses BOB - SolvBTC Restaking vault, there is only one depositor Core - uBTC Restaking vault, there are a few depositors Zetachain - pumpBTC Restaking vault, there is only one depositor Bitlayer - suBTC vault has only one depositor Plume - esBTC vault has only one depositor Plume - YBTC.B vault has only one depositor Goat - nETH vault has only one depositor Goat - rnETH vault has only one depositor Rootstock - uniBTC vault has only two deposits #### Kodiak V3 We removed TVL from unproductive liquidity pools that have no trading activities * SolvBTC.BNB/SolvBTC - 0x24619368bad314d1635a54027c5231b9b83c4a7e * brBTC-uniBTC = 0xe9703de93406cc31441a57ce5d08272ed545d32b #### RollX We removed TVL from unproductive assets in vaults that have a few deposit addresses Base - bfBTC vault, there is only a few depositors [https://etherscan.io/tx/0xce658f57edc490798ddc55e3f67169e3190fe23afe50a4ce4ca411d0714edada](https://basescan.org/address/0x623F2774d9f27B59bc6b954544487532CE79d9DF) #### Tea-REX We removed TVL from unproductive assets in vaults that have a few deposit addresses Sei - bfBTC vault, there is only a whale deposit #### Sailor Finance We removed TVL from unproductive liquidity pools that have no trading activities * SolvBTC/xSolvBTC - 0x877704326c9b8fe08eb5c92f6b0a75fcc3287ff6 #### Takara We removed TVL from unproductive assets with very low usage and no borrowing activity. * **enzoBTC**\ Single depositor, no borrowing\ `0x7F3C2A5bCA48150c7Ce07DcEAb9B73336a7e592a` * **M-BTC**\ Few deposits, no borrowing\ `0x963Db326b734FD58a9396C020BBb52C14acaFb02` * **uBTC**\ Few deposits, no borrowing\ `0xabFb7A392a6DaaC50f99c5D14B5f27EFfd08Fe03` #### Curvance We removed TVL from eBTC unproductive assets deposited from a single wallet and no borrows. * eBTC - Monad: 0x2840772E14fFbe337aB966727B7D1Dd09BDc76E4 #### Townsquare We removed TVL from unproductive assets in pools that have a few deposit addresses * enzoBTC - Monad: 0xD7aCB868F97F8286D5d3A0Fd5Ef112a8a72eCD90 #### Dolomite We removed TVL from WLFI market which almost supplied by WLFI team multisig * WLFI - 0xda5e1988097297dcdc1f90d4dfe7909e847cbef6 #### TermMax We removed TVL from brBTC market on BSC which have no borrow * brBTC market - 0x529A60A7aCDBDdf3D71d8cAe72720716BC192106 We removed TVL from uBTC on Bsquared which had a low number of deposit addresses * uBTC market - 0x5022B6563f6bc9f0D47F407ba32B64e1f438213a * uBTC - 0x796e4D53067FF374B89b2Ac101ce0c1f72ccaAc2 #### Echo Lending We removed TVL from these 2 wallets - single deposit - no borrow on aBTC market * 0xe7518ae420007626da09e3afff0f9076343267b94797043203e506e3599e965b * 0x3b9a45c9d5c73e27c48f85a26a3e9b3fcef44af44ddf9e0995bf17390b1d1bb8 #### Avalon USDa We removed all BTC wrappers TVL from team wallet deposit on all blockchains. # How to update a project ### Update project metadata (name, description, logo...) Fill this form: ### Update TVL If you'd like to update the code used to calculate the TVL of a DeFi project already listed on DefiLlama: 1. Fork the [Adapters repo](https://github.com/DefiLlama/DefiLlama-Adapters) (button towards the top right of the repo page). 2. Make your changes to the fork (generally easiest by cloning your new fork into a desktop IDE). 3. Make a Pull Request from your fork, to the main DefiLlama Adapters repo, with a brief explanation of what you changed. 4. Wait for someone to either comment on or merge your Pull Request. There is no need to ask for someone to check your PR as they are monitored regularly. ### Events If you'd like to update or add an **Event** to a DeFi project listed on DefiLlama: 1. Same as steps 1 & 2 above, fork the [Adapters repo](https://github.com/DefiLlama/DefiLlama-Adapters) (button towards the top right of the repo page) so that you can make your changes. 2. Add a "hallmarks" export to module.exports and add your hallmark as an array inside of an array (i.e. hallmarks: \[\["2025-05-29", "what happened"]]. You can add more by separating the inner arrays with a comma(","). View an example of hallmark entries [here](https://github.com/DefiLlama/DefiLlama-Adapters/blob/main/projects/uniswap/index.js#L57). The dates must follow the YYYY-MM-DD standard. 3. Once you have added the Hallmarks make a Pull Request from your fork, to the main DefiLlama Adapters repo, with a brief explanation of what you changed. 4. Hallmarks is not for adding any product development but instead its meant to explain changes in TVL. Only add events that had an impact on the TVL of a project. 5. Wait for someone to either comment on or merge your Pull Request. There is no need to ask for someone to check your PR. # How to write dimensions adapters This guide will help you create adapters for DefiLlama's various dashboards, including [fees](https://defillama.com/fees), [volumes](https://defillama.com/dexs), [aggregators](https://defillama.com/aggregators), [derivatives](https://defillama.com/derivatives), [Bridge Aggregators](https://defillama.com/bridge-aggregators), [Options](https://defillama.com/options), and others. ## What is an Adapter? An adapter is some code that: 1. Collects data on a protocol by calling some endpoints or making blockchain calls 2. Computes a response and returns it It's a TypeScript file that exports an async function which takes a FetchOptions object containing: * startTimestamp: Unix timestamp for start of period * endTimestamp: Unix timestamp for end of period * startBlock: Block number corresponding to start timestamp * endBlock: Block number corresponding to end timestamp * createBalances: Helper function to track token balances * api: Helper for making contract calls * getLogs: Helper for fetching event logs The function returns an object with metrics (like fees, volume, etc.) for that time range. ## Introduction to Dimension Adapters DefiLlama's dashboards track various metrics (dimensions) for DeFi protocols. Each dashboard focuses on specific dimensions: * **Dexs dashboard**: Tracks trading volume from DEXs (spot/swaps) * **Fees dashboard**: Tracks fees and revenue from all types of protocols * **Aggregators dashboard**: Tracks volume from DEX aggregators * **Derivatives dashboard**: Tracks volume from derivatives protocols * **Aggregator-Derivatives dashboard**: Tracks volume from aggregator-derivatives protocols * **Bridge Aggregators dashboard**: Tracks volume from bridge aggregators * **Options dashboard**: Tracks notional and premium volume from options DEXs ## How to List Your Project The majority of adapters for DefiLlama dashboards are contributed and maintained by their respective communities, with all changes being coordinated through the [`DefiLlama/dimension-adapters` GitHub repo](https://github.com/DefiLlama/dimension-adapters). To add your protocol to any dashboard, follow these steps: 1. Fork the [`dimension-adapters`](https://github.com/DefiLlama/dimension-adapters) repository 2. Create a new file at `[dashboard]/yourProtocolName/index.ts` or `[dashboard]/yourProtocolName.ts` (where `[dashboard]` is the relevant folder like `fees`, `dexs`, `aggregators`, `aggregator-derivatives`, `bridge-aggregators`, `options`, etc.) 3. Implement your adapter following the guidelines in this document 4. Test your adapter using `npm test [dashboard] yourProtocolName` 5. Submit a PR! A llama will review it and merge it. Once merged, it can take up to 24h to be available in the dashboard {% hint style="info" %} Seeing issues getting logs or with calls at historical blocks? You can replace the RPC being used by creating a .env file and filling it with rows like this: ETHEREUM\_RPC="https\://..." BSC\_RPC="https\://..." POLYGON\_RPC="https\://..." ... {% endhint %} ## Basic Example Let's start with a simple, complete example of a fees adapter: ```typescript import { FetchOptions, SimpleAdapter } from "../../adapters/types"; import { CHAIN } from "../../helpers/chains"; const FeeCollectedEvent = "event FeesCollected(address indexed _token, address indexed _integrator, uint256 _integratorFee, uint256 _lifiFee)" const LIFIFeeCollector = '0xbD6C7B0d2f68c2b7805d88388319cfB6EcB50eA9'; const fetch = async (options: FetchOptions) => { const dailyFees = options.createBalances(); const data: any[] = await options.getLogs({ target: LIFIFeeCollector, eventAbi: FeeCollectedEvent, }); data.forEach((log: any) => { dailyFees.add(log._token, log._integratorFee); }); return { dailyFees, dailyRevenue: dailyFees, dailyProtocolRevenue: dailyFees }; }; const methodology = { Fees: 'All fees paid by users for swap and bridge tokens via LI.FI.', Revenue: 'All fees are kept by LI.FI as protocol revenue.', ProtocolRevenue: 'All fees are distributed to LI.FI treasury.', } const adapter: SimpleAdapter = { version: 2, pullHourly: true, fetch, chains: [CHAIN.ETHEREUM], start: '2023-07-27', methodology } export default adapter; ``` ### Adapter Structure The object exported by your adapter file defines its behavior. The main configuration object holds a `version` key and supports two different structures: **Recommended Structure**: For protocols with the same fetch logic across all chains, you can use the simplified structure with `fetch`, `chains`, `start`, and `methodology` at the root level. ### SimpleAdapter Properties * **fetch**: The core async function that returns different dimensions of a protocol. The dimensions returned depend on which dashboard you're targeting (e.g., `dailyVolume` for the dexs dashboard, `dailyFees` for the fees dashboard). See "Core Dimensions" below. * **chains**: Array of chain constants (e.g., `[CHAIN.ETHEREUM, CHAIN.POLYGON]`) indicating which chains this adapter supports. * **start**: The earliest timestamp (as YYYY-MM-DD or unix timestamp) we can pass to the fetch function. This tells our servers how far back we can get historical data. * **methodology**: (Optional) Object describing how different dimensions are calculated. See "Metadata and Methodology" below. * **runAtCurrTime**: (Optional, defaults to `false`) Boolean flag. Set to `true` if the adapter can only return the latest data (e.g., last 24h) and cannot reliably use the `startTimestamp` and `endTimestamp` passed to `fetch`. #### Example of Multi-chain Root-level Structure ```typescript import { CHAIN } from "../../helpers/chains"; const methodology = { Fees: 'All fees paid by users for protocol operations.', Revenue: 'Portion of fees kept by the protocol after paying suppliers.', SupplySideRevenue: 'Portion of fees distributed to liquidity providers.', ProtocolRevenue: 'Portion of gross profit allocated to protocol treasury.', } const adapter: SimpleAdapter = { version: 2, pullHourly: true, fetch, chains: [CHAIN.ETHEREUM, CHAIN.POLYGON, CHAIN.ARBITRUM], start: '2023-01-01', methodology } ``` ## Testing Your Adapter Test your adapter locally before submitting a PR: ``` > npm test [dashboard] [protocolSlug] > npm test [dashboard] [protocolSlug] [timestamp] ``` ``` npm test fees katana ``` To test at specific day (unix format or yyyy-mm-dd): ``` npm test fees katana 1662110960 npm test dexs katana 2025-04-10 ``` This checks if your adapter correctly returns data for the requested time period. ### Adapter Version The top-level `version` key specifies which fetch signature the adapter uses and how it is scheduled. #### Version 2 (Recommended) Use version 2 whenever your data source can return data for an arbitrary time range. The `fetch` function receives a `FetchOptions` object with `startTimestamp`, `endTimestamp`, and all the helpers (`createBalances`, `getLogs`, `api`, etc.). **Every version 2 adapter must explicitly set the `pullHourly` key.** Default to `pullHourly: true`, which lets the system call your adapter in hourly increments for more granular data and avoids recomputing the same period. Only set `pullHourly: false` when the data genuinely cannot be pulled hourly, and add a comment explaining why. Because version 2 adapters run hourly, drive your time windows off `options.startTimestamp` / `options.fromTimestamp` (and `options.getFromBlock()`), **not** `options.startOfDay`. Keying off start-of-day sends the same request every hour and breaks hourly granularity. ```typescript import { FetchOptions, SimpleAdapter } from "../../adapters/types"; import { CHAIN } from "../../helpers/chains"; const fetch = async (options: FetchOptions) => { const dailyFees = options.createBalances(); const logs = await options.getLogs({ target: "0x1234...abcd", eventAbi: "event FeeCollected(address token, uint256 amount)", }); logs.forEach(log => dailyFees.add(log.token, log.amount, 'Trading Fees')); return { dailyFees, dailyRevenue: dailyFees }; }; const adapter: SimpleAdapter = { version: 2, pullHourly: true, // required key on version 2: true unless hourly pulls are impossible (then false + comment why) fetch, chains: [CHAIN.ETHEREUM], start: '2024-01-01', methodology: { Fees: "Trading fees collected from swaps.", Revenue: "All fees are kept by the protocol.", }, }; export default adapter; ``` #### Version 1 Use version 1 **only** when your data source provides daily data that cannot be split into arbitrary time ranges β€” for example, an external API that returns one value per calendar day. **Dune adapters must always be `version: 1`**: Dune queries run once per day, and a version 2 adapter would re-run the same expensive query every hour. The `fetch` signature is the same single `(options: FetchOptions)` argument as version 2 β€” the old 3-argument form `(timestamp, chainBlocks, options)` no longer exists and will fail. Use the values already on `options` (`options.startOfDay`, `options.dateString`) instead of deriving them from a raw timestamp, and do not return `timestamp` in the result. Version 1 does **not** support `pullHourly`. ```typescript import { FetchOptions, SimpleAdapter } from "../../adapters/types"; import { CHAIN } from "../../helpers/chains"; import { httpGet } from "../../utils/fetchURL"; const fetch = async (options: FetchOptions) => { const data = await httpGet(`https://api.example.com/daily-fees?date=${options.dateString}`); return { dailyFees: data.fees, dailyRevenue: data.revenue, }; }; const adapter: SimpleAdapter = { version: 1, fetch, chains: [CHAIN.SOLANA], start: '2024-06-01', methodology: { Fees: "Daily fees fetched from external API.", Revenue: "All fees are protocol revenue.", }, }; export default adapter; ``` #### When to Use Which | | Version 2 | Version 1 | | ------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | **Use when** | On-chain logs, contract calls, subgraphs | External API that only returns daily aggregates, Dune queries | | **Fetch signature** | `(options: FetchOptions)` | `(options: FetchOptions)` (same as v2 - the old 3-arg signature is removed) | | **Time range** | Arbitrary start/end timestamps | Fixed day (00:00–23:59 UTC) | | **`pullHourly`** | Required - set explicitly (`true` by default, `false` + reason if not possible) | Not supported | | **Preference** | Always prefer this | Use only when v2 is not possible | ### Core Dimensions Your `fetch` function should return an object containing properties corresponding to the metrics (dimensions) relevant to the dashboard you are targeting. All dimensions should be returned as balance objects (`Object`) where keys are the token identifiers (e.g., `ethereum:0x...`) and values are the raw amounts (no decimal adjustments). > **Minimum Requirements:** To be listed, your adapter **must** provide accurate `dailyFees` and `dailyRevenue` dimensions. `dailySupplySideRevenue` is strongly encouraged whenever the protocol has supply-side costs. `dailyHoldersRevenue` should be included for protocols that distribute value to tokenholders. Always include breakdown labels and `breakdownMethodology`. Cumulative `total*` dimensions are deprecated and should not be used. Here are the standard dimensions grouped by dashboard type: **Dexs and Dex Aggregators Dimensions:** * `dailyVolume`: (**Required**) Trading volume for the period. **Derivatives and Aggregators-Derivatives Dimensions:** * `dailyVolume`: (**Required**) Perpetual trading volume for the period. * `openInterestAtEnd`: (Optional) Open interest at the end of the period. * `longOpenInterestAtEnd`: (Optional) Long open interest at the end of the period. * `shortOpenInterestAtEnd`: (Optional) Short open interest at the end of the period. **Bridge Aggregators Dimensions:** * `dailyBridgeVolume`: (**Required**) Bridge volume for the period. **Options Dimensions:** * `dailyNotionalVolume`: (**Required**) Notional volume of options contracts traded/settled. * `dailyPremiumVolume`: (**Required**) Premium volume collected/paid. * `openInterestAtEnd`: (Optional) Open interest at the end of the period. * `longOpenInterestAtEnd`: (Optional) Long open interest at the end of the period. * `shortOpenInterestAtEnd`: (Optional) Short open interest at the end of the period. **Fees Dimensions:** Our fees dimensions follow an income statement model inspired by GAAP accounting standards. See the "Breakdown Labels & Income Statement" section below for the full methodology and rationale. * `dailyFees`: (**Required**) All fees and value collected from *all* sources (users, LPs, yield generation, liquid staking rewards, etc.), representing the total value flow into the protocol's ecosystem. This maps to **Gross Protocol Revenue** on the income statement β€” everything the protocol could theoretically keep if it took 100%. For a DEX this is total swap fees, for lending this is all borrow interest, for liquid staking this is all staking rewards from staked ETH. Block rewards are **not** fees β€” they are incentives. For chain adapters, track only transaction fees paid by users (not perp DEX fees built on top). * `dailyUserFees`: (Optional, but helpful) The portion of `dailyFees` directly paid by end-users (e.g., swap fees, borrow interest, liquidation penalties, marketplace commissions paid by buyers/sellers). * `dailySupplySideRevenue`: (**Required when applicable**) The portion of `dailyFees` distributed to liquidity providers, lenders, stakers, or other suppliers of capital/resources β€” as well as fees paid out to integrators, referrers, partners, and creators. This maps to **Cost of Revenue** on the income statement. Examples: LP fees on a DEX, interest paid to lenders, staking rewards passed through to stETH holders, blob fees to mainnet for rollups, validator commissions, trading rebates, integrator/referral fees, partner revenue shares, creator royalties. **Real-world supply side examples from** [**`dimension-adapters`**](https://github.com/DefiLlama/dimension-adapters)**:** * **Creator / Referral platform** ([Zora](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/zora-sofi.ts)): Creator rewards + trade referrer + platform referrer fees all flow to `dailySupplySideRevenue`. Protocol rewards = `dailyRevenue`. * **DEX LP fees** ([e3](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/e3.ts)): LP fees from trading = `dailySupplySideRevenue`, token buybacks = `dailyHoldersRevenue`. * **Perp LP + rebates** ([GMX](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/gmx.ts)): 70% of swap/margin/mint-redeem fees to GLP holders = `dailySupplySideRevenue`, 30% to GMX stakers = `dailyHoldersRevenue`. * **Creator royalties** ([BasePaint](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/basepaint.ts)): 90% of mint fees to artists (`METRIC.CREATOR_FEES`) = `dailySupplySideRevenue`, 10% to protocol. * **Lending interest** ([Aave](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/aave-v3.ts)): Interest distributed to lenders = `dailySupplySideRevenue`. Also includes Paraswap partner fees as a supply side cost. * **Liquid staking** ([Lido](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/lido.ts)): 90% of staking + MEV rewards passed to stETH holders = `dailySupplySideRevenue`. * **Savings/DSR costs** ([MakerDAO](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/makerdao.ts)): DSR interest paid to depositors + USDS staking rewards = `dailySupplySideRevenue` (uses `allowNegativeValue: true`). * `dailyRevenue`: (**Required**) The portion of `dailyFees` kept by the protocol entity itself. This maps to **Gross Profit** on the income statement. `dailyRevenue = dailyFees - dailySupplySideRevenue`. * `dailyProtocolRevenue`: (Optional, clarifies revenue split) The portion of `dailyRevenue` allocated to the protocol's treasury or core team. * `dailyHoldersRevenue`: (Optional, but important for protocols distributing to holders) All value flowing to governance token holders. This maps to **Tokenholder Income** on the income statement. Includes buybacks, token burns, direct distributions, AND income from external sources (airdrops from other protocols, bribes from other protocols, etc.). > **Deprecated:** `dailyBribeRevenue` and `dailyTokenTax` are deprecated as separate dimensions. Instead, include these as labeled sub-sections within `dailyHoldersRevenue` (e.g., `dailyHoldersRevenue.add(token, amount, 'Bribes from Protocol X')`). **Fee/Revenue Attribution Examples by Protocol Type:** If you are unsure how to classify fees and revenues, refer to this table or contact us at or ask on Discord:
| Attribute | DEXs | Lending | Chains | NFT Marketplace | Derivatives | CDP | Liquid Staking | Yield | Synthetics | | ----------------- | ------------------------------------------- | ------------------------------------------ | ---------------------------------------------- | -------------------------------------- | -------------------------------- | -------------------------- | ------------------------------- | ---------------------------------- | -------------------------------- | | UserFees | Swap fees paid by users | Interest paid by borrowers | Gas fees paid by users | Fees paid by users | Fees paid by users | Interest paid by borrowers | % of rewards paid to protocol | Paid management + performance fees | Fees paid by users | | Fees | =UserFees | =UserFees | =UserFees | =UserFees | UserFees + burn/mint fees | =UserFees | Staking rewards | Yield | =UserFees | | SupplySideRevenue | LPs revenue | Interest paid to lenders | Sequencer costs, blob fees | Creator earnings | LP revenue, trading rebates | \* | Revenue earned by stETH holders | Yield excluding protocol fees | LPs revenue | | Revenue | % of swap fees going to protocol governance | % of interest going to protocol governance | Burned coins (fees-sequencerCosts for rollups) | Marketplace revenue + creator earnings | Protocol governance revenue | =ProtocolRevenue | =ProtocolRevenue | =ProtocolRevenue | =ProtocolRevenue | | ProtocolRevenue | % of swap fees going to treasury | % of interest going to protocol | \* | Marketplace revenue | Value going to treasury | Interest going to treasury | =UserFees | =UserFees | % of fees going to treasury | | HoldersRevenue | Money going to gov token holders | \* | \* | \* | Value going to gov token holders | \* | \* | \* | % of fees going to token holders | > **Notes:** > > * Protocol governance includes treasury + gov token holders. > * `Revenue = HoldersRevenue + ProtocolRevenue`. > * `Revenue = Fees - SupplySideRevenue`. > * Asterisk (\*) indicates typically not applicable or zero for that category. > * For chains: only track transaction fees paid by users. Perp DEX fees on Hyperliquid L1 are tracked under the perp adapter, not the chain adapter. ## Implementation Steps Building the `fetch` function is the core task. Here's a breakdown: 1. **Identify Supported Chains**: Determine which blockchains your protocol runs on by referencing the [chains.ts](https://github.com/DefiLlama/dimension-adapters/blob/master/helpers/chains.ts) file. For the recommended root-level structure, add these to the `chains` array. For chain-specific configurations, you'll need a `BaseAdapter` entry for each chain. 2. **Define Start Dates**: Find your protocol's deployment date to set the `start` property (root-level for consistent dates, or per-chain for different deployment dates). This enables proper data backfilling. 3. **Choose Data Source(s)**: Select the appropriate method(s) to retrieve the necessary data for calculating dimensions. Common approaches are detailed below. ## Data Source Examples Choose the appropriate data source based on your protocol's architecture. The `fetch` function receives an `options` object containing helper utilities like `createBalances`, `getLogs`, `api` (for contract calls), `queryDuneSql`, etc. ### On-Chain Event Logs Ideal for tracking specific events that generate fees or volume: ```typescript const fetch = async ({ getLogs, createBalances }) => { const dailyFees = createBalances(); const dailyRevenue = createBalances(); const logs = await getLogs({ target: "0xcf205808ed36593aa40a44f10c7f7c2f67d4a4d4", eventAbi: 'event Trade(address trader, address subject, bool isBuy, uint256 shareAmount, uint256 ethAmount, uint256 protocolEthAmount, uint256 subjectEthAmount, uint256 supply)' }); logs.forEach(log => { dailyFees.addGasToken(log.protocolEthAmount * 2); // Example: Total fees dailyRevenue.addGasToken(log.protocolEthAmount); // Example: Protocol's share }); return { dailyFees, dailyRevenue }; }; ``` Example: [Ostium](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/ostium/index.ts) ### Token Transfer Tracking Track tokens received by protocol treasury/fee addresses: ```typescript import { addTokensReceived } from '../../helpers/token'; const fetch = async (options: FetchOptions) => { // Track ERC20 token transfers to treasury const dailyFees = await addTokensReceived({ options, tokens: ["0x4200000000000000000000000000000000000006"], // WETH on Base targets: ["0xbcb4a982d3c2786e69a0fdc0f0c4f2db1a04e875"] // Treasury }); // Example: Assuming all received tokens are fees and revenue return { dailyFees, dailyRevenue: dailyFees } } ``` Example: [Synthetix](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/synthetix.ts) ### Subgraphs Fast queries for protocols with well-maintained subgraphs: ```typescript import { request } from "graphql-request"; const fetch = async (options: FetchOptions) => { const dailyVolume = options.createBalances(); const query = `{ volumeStats(where: {timestamp_gte: ${options.startTimestamp}, timestamp_lt: ${options.endTimestamp}}) { volumeUSD token } }`; const { volumeStats } = await request("https://api.thegraph.com/subgraphs/name/protocol/subgraph", query); volumeStats.forEach(stat => { // Assuming volumeUSD needs conversion if not directly usable dailyVolume.add(stat.token, stat.volumeUSD); }); return { dailyVolume }; }; ``` Examples: * [Curve](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/curve.ts) * [LlamaLend](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/llamalend.ts) * [TheGraph](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/thegraph.ts) * [Dackieswap](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/dackieswap.ts) ### Query Engines (Dune, Flipside, Allium) For complex queries or when direct blockchain access is too expensive: ```typescript const fetch = async (options: FetchOptions) => { const dailyFees = options.createBalances(); const results = await options.queryDuneSql(` SELECT SUM(amount) as fees, token_address FROM ethereum.transactions WHERE to_address = '0x123...abc' -- Example fee address AND block_time >= FROM_UNIXTIME(${options.startTimestamp}) AND block_time < FROM_UNIXTIME(${options.endTimestamp}) GROUP BY token_address `); if (results && results.length > 0) { results.forEach(row => { dailyFees.add(row.token_address, row.fees); }); } return { dailyFees }; }; ``` Example: [Pumpswap](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/pump-swap/index.ts) ### Contract Calls For protocols where data is accessible through view functions or requires multiple contract interactions: ```typescript const fetch = async (options: FetchOptions) => { const dailyFees = options.createBalances(); // Example: Get plugin data through contract calls const plugins = await options.api.call({ target: "0xd7ea36ECA1cA3E73bC262A6D05DB01E60AE4AD47", // Contract address abi: "address[]:getPlugins", }); // Use multiCall for efficiency when making multiple similar calls const bribes = await options.api.multiCall({ abi: "function getBribe() returns (address)", calls: plugins }); // Example: Collect fee data from events emitted by bribe contracts for (const bribe of bribes) { const logs = await options.getLogs({ target: bribe, eventAbi: "event Bribe__RewardNotified(address indexed rewardToken, uint256 reward)", }); logs.forEach((log) => { dailyFees.add(log.rewardToken, log.reward); }); } return { dailyFees }; }; ``` Example: [Beradrome](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/beradrome/index.ts) ## Metadata and Methodology Always include a `methodology` object to explain how your metrics are calculated. This is crucial for transparency. ```typescript const methodology = { Fees: "All swap fees paid by traders (0.3% per trade).", Revenue: "Protocol keeps 0.05% of each swap after paying LPs.", SupplySideRevenue: "LPs receive 0.25% of each swap as liquidity incentive.", HoldersRevenue: "Protocol buybacks funded from treasury revenue.", ProtocolRevenue: "0.05% of swap fees allocated to protocol treasury.", } const adapter: SimpleAdapter = { version: 2, pullHourly: true, fetch, chains: [CHAIN.ETHEREUM], start: '2023-01-01', methodology } ``` The `methodology` object provides a one-line summary per dimension. For detailed per-label explanations, use `breakdownMethodology` (see below). ## Breakdown Labels & Income Statement ### Why We Use an Income Statement Model Our previous system only displayed aggregated numbers with no breakdown. Users didn't know what we were counting (e.g., does Ethereum fees include blob fees?), there was no way to tell if a new revenue stream was being tracked, and we only captured tokenholder income from burns/distributions while missing airdrops, bribes, etc. We moved to a system inspired by **GAAP** accounting standards. The goal is: * Break down each component as much as possible * Name and description of each component must be easy to understand β€” if you were a user and saw this breakdown, would you understand what each thing is? * When a user wonders "does this include X revenue stream/cost?" it should be trivial to answer by looking at the breakdown * Include every way that tokenholders make money, even if it's coming from another protocol ### Income Statement Template This template is a **reference for deciding which dimension and breakdown label to use** when writing your adapter. For each revenue stream or cost in your protocol, find it in the template below to determine whether it belongs in `dailyFees`, `dailySupplySideRevenue`, `dailyRevenue`, `dailyHoldersRevenue`, etc. Then use the corresponding label in your `.add()` calls and `breakdownMethodology` object (see the code examples further below). **Gross Protocol Revenue** (`dailyFees`): * \+ Swap Fees * \+ Liquidation Fees * \+ Interest Income (borrow interest) * \+ Staking Rewards * \+ MEV Captured * \+ Gas Fees (transaction fees on chains and rollups) **Cost of Funds** (`dailySupplySideRevenue`): * \- LP Payments * \- Interest Expenses (paid to lenders/depositors) * \- Staking Rewards, less fees (passed through to stakers) * \- MEV paid to stakers, less fees * \- Blob fees to mainnet (for rollups) * \- Validator Commissions * \- Trading Rebates (including those funded by token emissions) * \- Integrator / Referral Fees (paid to partners, integrators, or referrers) * \- Creator Royalties / Fees **Gross Profit** (`dailyRevenue`) = Gross Protocol Revenue - Cost of Funds *** **Tokenholder Income** (`dailyHoldersRevenue`) β€” OFF STATEMENT: *Capital Allocations:* * \+ Treasury Buybacks * \+ Tokenholder Distributions *Other Tokenholder Flows:* * \+ Airdrops Received by Tokenholders from Other Protocols (e.g., Binance Earn where BNB stakers receive airdrops from tokens that launch on Binance) * \+ Bribes Received by Tokenholders from Other Protocols * \+ Other Off-Protocol Tokenholder Income **Tokenholder Income** = Capital Allocations + Other Tokenholder Flows ### How to Implement This in Your Adapter The income statement above maps directly to your `.add()` calls and `breakdownMethodology`. Here are compact examples from real adapters showing different protocol types: #### Creator / Referral Platform (Zora) ```typescript // fees/zora-sofi.ts β€” creators, referrers, and protocol each get a share dailyFees.addUSDValue(creatorRewards, 'Creator Rewards') dailyFees.addUSDValue(tradeReferrer, 'Trade Referrer') dailyFees.addUSDValue(platformReferrer, 'Platform Referrer') dailyFees.addUSDValue(protocolRewards, 'Protocol Rewards') // Creators + referrers = supply side (they are "suppliers" of content/traffic) dailySupplySideRevenue.addUSDValue(creatorRewards, 'Creator Rewards') dailySupplySideRevenue.addUSDValue(tradeReferrer, 'Trade Referrer') dailySupplySideRevenue.addUSDValue(platformReferrer, 'Platform Referrer') // Protocol keeps the rest dailyRevenue.addUSDValue(protocolRewards, 'Protocol Rewards') const breakdownMethodology = { Fees: { 'Creator Rewards': 'Rewards distributed to content creators.', 'Trade Referrer': 'Fees paid to the address that referred the trade.', 'Platform Referrer': 'Fees paid to the platform that referred the user.', 'Protocol Rewards': 'Fees retained by the Zora protocol.', }, SupplySideRevenue: { 'Creator Rewards': 'Creator rewards are supply side costs.', 'Trade Referrer': 'Trade referral fees are supply side costs.', 'Platform Referrer': 'Platform referral fees are supply side costs.', }, Revenue: { 'Protocol Rewards': 'Protocol rewards retained by Zora.', }, } ``` #### Perp DEX with LP Split (GMX) ```typescript // fees/gmx.ts β€” 70% to GLP holders, 30% to GMX stakers import { METRIC } from '../../helpers/metrics'; dailyFees.add(token, mintFees, METRIC.MINT_REDEEM_FEES) dailyFees.add(token, marginFees, METRIC.MARGIN_FEES) dailyFees.add(token, swapFees, METRIC.SWAP_FEES) // 70% of all fees β†’ supply side (GLP holders) dailySupplySideRevenue.add(token, mintFees * 0.7, 'Mint/Redeem Fees To GLP') dailySupplySideRevenue.add(token, marginFees * 0.7, 'Margin Fees To GLP') dailySupplySideRevenue.add(token, swapFees * 0.7, 'Swap Fees To GLP') // 30% β†’ holders revenue (GMX stakers) dailyHoldersRevenue.add(token, mintFees * 0.3, 'Mint/Redeem Fees To GMX Stakers') dailyHoldersRevenue.add(token, marginFees * 0.3, 'Margin Fees To GMX Stakers') dailyHoldersRevenue.add(token, swapFees * 0.3, 'Swap Fees To GMX Stakers') ``` #### Liquid Staking (Lido) ```typescript // fees/lido.ts β€” 90% to stakers, 10% protocol fee import { METRIC } from '../../helpers/metrics'; dailyFees.add(token, stakingRewards, METRIC.STAKING_REWARDS) dailyFees.add(token, mevRewards, METRIC.MEV_REWARDS) // 90% passed through to stETH holders dailySupplySideRevenue.add(token, stakingRewards * 0.9, 'Staking Rewards To Stakers') dailySupplySideRevenue.add(token, mevRewards * 0.9, 'MEV Rewards To Stakers') // 10% kept by protocol dailyRevenue.add(token, stakingRewards * 0.1, 'Staking Rewards Fee') dailyRevenue.add(token, mevRewards * 0.1, 'MEV Rewards Fee') ``` ### When to Use Breakdown Labels **Always provide labels, even when there is only one source/destination of fees.** This prevents having to update and backfill data later when the adapter is listed under a parent protocol. For example, when writing a Fluid DEX adapter, add a `'Swap Fees'` label even though it has only one source of fees. Later, when Fluid Lending is also listed and both are grouped under the Fluid parent protocol, the DEX adapter already has proper breakdown labels and doesn't need updating or data backfilling. ### How Labels Change Per Dimension Labels should vary by dimension to provide the most useful information: * **`dailyFees`**: Use **source-of-fees** labels that describe where money comes from. Simple labels like: `'Swap Fees'`, `'Borrow Interest'`, `'Flashloan Fees'`, `'Liquidation Fees'`, `'Staking Rewards'`, `'MEV Rewards'` * **`dailyRevenue`**, **`dailyProtocolRevenue`**, **`dailySupplySideRevenue`**, **`dailyHoldersRevenue`**: Use **more detailed labels** that describe both the source and destination: `'Swap Fees To LPs'`, `'Borrow Interest To Treasury'`, `'Borrow Interest To Lenders'`, `'Staking Rewards To Protocol'` This distinction matters because the same source of fees often splits across multiple destinations: ```typescript // dailyFees: simple source labels dailyFees.add(token, totalBorrowInterest, 'Borrow Interest') // dailySupplySideRevenue: detailed destination labels dailySupplySideRevenue.add(token, lenderShare, 'Borrow Interest To Lenders') // dailyRevenue: detailed destination labels dailyRevenue.add(token, protocolShare, 'Borrow Interest To Treasury') ``` ### Adding Breakdown Labels in Code The third parameter in `.add()` specifies the category label. All balance methods support this: ```typescript // .add() with label dailyFees.add(tokenAddress, amount, 'Borrow Interest') // .addGasToken() with label dailyFees.addGasToken(amount, 'Staking Rewards') // .addUSDValue() with label dailySupplySideRevenue.addUSDValue(usdAmount, 'Borrow Interest To Lenders') // .add() with Balances object and label dailyRevenue.add(balancesObj, 'Spot Fees') ``` ### Label Naming Best Practices Labels must be **clear, descriptive, and immediately understandable to a user who sees the breakdown**: **Good labels:** * `'Borrow Interest'` β€” clear what borrowers are paying * `'GHO Borrow Interest'` β€” specific to the GHO market * `'Liquidation Fees'` β€” describes the fee source * `'Staking Rewards'` β€” clear revenue source * `'MEV Rewards'` β€” specific MEV-related revenue * `'Spot Fees'` β€” trading fees on spot markets * `'Borrow Interest To Treasury'` β€” clear destination * `'Borrow Interest To Lenders'` β€” clear who receives it * `'Spot fees on Unit markets'` β€” specific enough to distinguish from other spot fees **Bad labels:** * `'Protocol Fees'` β€” too vague, doesn't explain what kind of fees * `'Fees'` β€” not descriptive at all * `'Revenue'` β€” doesn't explain the source * `'Other'` β€” not informative * `'Misc'` β€” meaningless to users **Key principles:** 1. **Be specific**: Users should immediately understand what each label means 2. **Break down as much as possible**: More granular breakdowns are always better 3. **Use constants when they fit**: Check `helpers/metrics.ts` for shared labels, but **prioritize clarity over reuse** 4. **Vary labels across dimensions**: Use different labels in dailyFees vs dailySupplySideRevenue when it helps understanding 5. **Think like income statements**: Would an investor reading this breakdown understand exactly where the money comes from and goes? 6. **Answer "does this include X?"**: When a user wonders if a specific revenue stream or cost is included, the answer should be obvious from the breakdown ### Using Metric Constants Standard labels are defined in [`helpers/metrics.ts`](https://github.com/DefiLlama/dimension-adapters/blob/master/helpers/metrics.ts): ```typescript import { METRIC } from '../../helpers/metrics'; METRIC.BORROW_INTEREST // 'Borrow Interest' METRIC.LIQUIDATION_FEES // 'Liquidation Fees' METRIC.FLASHLOAN_FEES // 'Flashloan Fees' METRIC.SWAP_FEES // 'Token Swap Fees' METRIC.LP_FEES // 'LP Fees' METRIC.STAKING_REWARDS // 'Staking Rewards' METRIC.MEV_REWARDS // 'MEV Rewards' METRIC.TOKEN_BUY_BACK // 'Token Buy Back' METRIC.CREATOR_FEES // 'Creator Fees' METRIC.MARGIN_FEES // 'Margin Fees' METRIC.OPEN_CLOSE_FEES // 'Open/Close Fees' METRIC.PERFORMANCE_FEES // 'Performance Fees' METRIC.MANAGEMENT_FEES // 'Management Fees' METRIC.CURATORS_FEES // 'Curators Fees' METRIC.OPERATORS_FEES // 'Operators Fees' METRIC.TRADING_FEES // 'Trading Fees' METRIC.TRANSACTION_GAS_FEES // 'Transaction Gas Fees' METRIC.TRANSACTION_BASE_FEES // 'Transaction Base Fees' METRIC.TRANSACTION_PRIORITY_FEES // 'Transaction Priority Fees' METRIC.MINT_REDEEM_FEES // 'Mint/Redeem Fees' METRIC.DEPOSIT_WITHDRAW_FEES // 'Deposit/Withdraw Fees' METRIC.SERVICE_FEES // 'Service Fees' METRIC.ASSETS_YIELDS // 'Assets Yields' METRIC.PROTOCOL_FEES // 'Protocol Fees' ``` **When to use constants vs custom labels:** * **Use constants** when they clearly describe your category * **Write custom labels** when constants would be unclear or confusing β€” user understanding is more important than code consistency * Before creating a new constant, check if an existing one fits. Before using a constant, check if it's clear enough for your use case. ### breakdownMethodology Object **Every label used in `.add()` calls MUST appear in `breakdownMethodology`**, and every label in `breakdownMethodology` must have corresponding data in code. This object documents each sub-section. #### Structure ```typescript const breakdownMethodology = { Fees: { 'Label A': 'Description of this revenue source', 'Label B': 'Description of this revenue source', }, Revenue: { 'Label C': 'Description of what protocol keeps from this source', }, SupplySideRevenue: { 'Label D': 'Description of what suppliers receive', }, ProtocolRevenue: { 'Label E': 'Description of what goes to treasury', }, HoldersRevenue: { 'Label F': 'Description of tokenholder income source', }, } ``` #### Complete Example: Aave (Lending) ```typescript const breakdownMethodology = { Fees: { 'Borrow Interest': 'All interest paid by borrowers from all markets (excluding GHO).', 'Borrow Interest GHO': 'All interest paid by borrowers from GHO only.', 'Liquidation Fees': 'Fees from liquidation penalty and bonuses.', 'Flashloan Fees': 'Flashloan fees paid by flashloan borrowers and executors.', }, Revenue: { 'Borrow Interest': 'A portion of interest paid by borrowers from all markets (excluding GHO).', 'Borrow Interest GHO': 'All 100% interest paid by GHO borrowers.', 'Liquidation Fees': 'A portion of fees from liquidation penalty and bonuses.', 'Flashloan Fees': 'A portion of fees paid by flashloan borrowers and executors.', }, SupplySideRevenue: { 'Borrow Interest': 'Amount of interest distributed to lenders from all markets (excluding GHO).', 'Borrow Interest GHO': 'No supply side revenue for lenders on GHO market.', 'Liquidation Fees': 'Fees from liquidation penalty and bonuses are distributed to lenders.', 'Flashloan Fees': 'Flashloan fees paid by flashloan borrowers and executors are distributed to lenders.', }, ProtocolRevenue: { 'Borrow Interest': 'Interest from all markets (excluding GHO) collected by Aave treasury.', 'Borrow Interest GHO': 'All interest paid on GHO market collected by Aave treasury.', 'Liquidation Fees': 'A portion of liquidation fees collected by Aave treasury.', 'Flashloan Fees': 'A portion of flashloan fees collected by Aave treasury.', }, } ``` #### Example: Fluid (Lending with Buybacks) ```typescript const FLUID_METRICS = { BorrowInterest: METRIC.BORROW_INTEREST, TokenBuyBack: METRIC.TOKEN_BUY_BACK, BorrowInterestToTreasury: 'Borrow Interest To Treasury', BorrowInterestToLenders: 'Borrow Interest To Lenders', } const breakdownMethodology = { Fees: { [FLUID_METRICS.BorrowInterest]: "All interest paid by borrowers.", }, Revenue: { [FLUID_METRICS.BorrowInterestToTreasury]: "Percentage of interest going to treasury.", }, ProtocolRevenue: { [FLUID_METRICS.BorrowInterestToTreasury]: "Percentage of interest going to treasury.", }, SupplySideRevenue: { [FLUID_METRICS.BorrowInterestToLenders]: "Amount of interest distributed to lenders.", }, HoldersRevenue: { [FLUID_METRICS.TokenBuyBack]: "FLUID token buyback from the treasury.", }, } ``` #### Example: Hyperliquid (DEX with Buybacks) ```typescript const breakdownMethodology = { Fees: { 'Spot Fees': 'Fees collected on all spot trades, excluding trades on markets with Unit assets (eg bridged BTC).', 'Spot fees on Unit markets': 'Fees from spot trades on markets that include an asset deployed by Unit, in these spot markets all fees go to Unit.', }, Revenue: { 'Spot Fees': '99% of spot trade fees, excluding perp fees and unit protocol fees.', }, SupplySideRevenue: { 'Unit Revenue': 'All fees earned on Unit spot markets go to Unit.', 'HLP': '1% of the spot fees go to HLP vault (used to be 3% before 30 Aug 2025).', }, HoldersRevenue: { [METRIC.TOKEN_BUY_BACK]: "99% of spot trade fees (excluding perp fees and unit protocol fees) for buy back HYPE tokens.", }, } ``` #### Example: Liquity (CDP with No Protocol Revenue) ```typescript const breakdownMethodology = { Fees: { 'Borrow Fees': 'One-time borrow fees paid by borrowers.', 'Redemption Fees': 'Redemption fees paid by borrowers.', 'Gas Compensation': 'Gas compensations paid to liquidators when triggering liquidations.', 'Liquidation Profit': 'Profit from ETH collaterals distributed to stability pool stakers on liquidations.', }, Revenue: { 'Borrow Fees': 'One-time borrow fees paid by borrowers.', 'Redemption Fees': 'Redemption fees paid by borrowers.', }, HoldersRevenue: { 'Borrow Fees': 'Borrow fees distributed to LUSD stability pool and LQTY stakers.', 'Redemption Fees': 'Redemption fees distributed to LUSD stability pool and LQTY stakers.', }, SupplySideRevenue: { 'Gas Compensation': 'Gas compensations paid to liquidators when triggering liquidations.', 'Liquidation Profit': 'Profit from ETH collaterals distributed to stability pool stakers.', } } ``` ### Adding to Your Adapter ```typescript const adapter: SimpleAdapter = { version: 2, pullHourly: true, fetch, chains: [CHAIN.ETHEREUM], start: '2023-01-01', methodology, breakdownMethodology, } ``` ### Requirements Checklist **Must have:** 1. Every label used in `.add()` calls has a corresponding entry in `breakdownMethodology` 2. Every label in `breakdownMethodology` has corresponding data assigned in code 3. Labels are descriptive and immediately understandable to users 4. Descriptions clearly explain what each category represents 5. Labels are provided even when there's only one source of fees (for parent protocol compatibility) 6. `dailySupplySideRevenue` (Cost of Revenue) is tracked whenever the protocol pays out to suppliers **Common mistakes to avoid:** 1. Using vague labels like "Protocol Fees" or "Other" β€” be specific 2. Missing `breakdownMethodology` entries for labels used in code 3. Having `breakdownMethodology` entries with no corresponding data 4. Not breaking down enough β€” more detail is always better 5. Using the same labels across all dimensions when different labels would be clearer 6. Forgetting to label single-source adapters (breaks when listed under parent protocol) 7. Tracking block rewards as fees β€” they are incentives, not fees 8. Including perp DEX fees in chain adapters β€” those belong in the perp adapter ### Real-World Examples Browse these adapters for complete implementations: * [Aave](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/aave-v3.ts) β€” Multi-market lending with GHO breakdown and Paraswap partner fees * [Fluid](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/fluid/index.ts) β€” Lending with treasury/lender split and buybacks * [Liquity](https://github.com/DefiLlama/dimension-adapters/blob/master/helpers/liquity.ts) β€” CDP with borrow, redemption, and liquidation fees * [Hyperliquid](https://github.com/DefiLlama/dimension-adapters/blob/master/dexs/hyperliquid-spot/index.ts) β€” DEX with unit markets and HYPE buybacks * [GMX](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/gmx.ts) β€” Perp DEX with 70/30 LP/staker split * [Lido](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/lido.ts) β€” Liquid staking with staking + MEV reward breakdown * [Zora](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/zora-sofi.ts) β€” Creator/referral platform with integrator fees as supply side * [BasePaint](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/basepaint.ts) β€” Creator royalties (90% to artists) * [MakerDAO](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/makerdao.ts) β€” CDP with DSR costs and stability fees * [Ethereum](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/ethereum/index.ts) β€” Chain adapter with base/priority fee breakdown For full income statement examples showing how major protocols in each category break down their financials, see the [examples folder](https://github.com/DefiLlama/docs/blob/master/list-your-project/other-dashboards/examples/README.md). ## Code Structure Guidelines Follow these rules when writing adapters: * **Prefer on-chain data**: Use on-chain event logs and contract calls where possible. We are stricter about this for chains where we maintain our own indexer, or where there is significant volume/fees, or where you suspect wash trading. * **Set `pullHourly` explicitly on every version 2 adapter**: use `pullHourly: true` wherever EVM logs and Allium queries are used - it avoids recomputing data for the same time period and provides more granular hourly data. Only set `false` with a comment explaining why hourly pulls are not possible. * **Never swallow errors**: It's better to fail than to return incorrect data. If a small chain with $10K volume fails, it shouldn't break an adapter that tracks $100M daily on other chains β€” return 0 for the failing chain. * **Use/add helper code**: When multiple adapters use similar logic, extract it into shared helpers. * **No npm dependencies**: Do not add npm packages. This leads to bloat. * **Use `api.multiCall`**: Prefer `api.multiCall` over `Promise.all` for batching EVM calls. Use `PromisePool` for non-EVM calls. * **Return token breakdowns**: Always return amounts with token addresses (not pre-converted USD). Always include `methodology` and `breakdownMethodology` (where appropriate). * **Watch for wash trading**: Be vigilant about wash trading, especially on low-fee chains. ## Important Considerations ### Precision Use the `BigNumber` library (available via `options.createBalances()` or direct import) for mathematical operations involving token amounts, especially when dealing with different decimals or potentially large/small numbers, to avoid JavaScript precision issues. ```typescript import BigNumber from "bignumber.js"; // ... inside fetch function const feesInGas = new BigNumber(graphRes["fees"]); const ethGasPrice = await getGasPrice(timestamp); // Assuming getGasPrice helper exists const dailyFees = options.createBalances(); // Create a Balances object dailyFees.addGasToken(feesInGas.multipliedBy(ethGasPrice).toString()); return { dailyFees, dailyRevenue: dailyFees }; ``` ## Helper Functions Reference DeFiLlama provides numerous helper functions to simplify common tasks in adapter development. These are available either via direct import or through the `options` object passed to your `fetch` function. ### Protocol-Specific Helpers (Common Abstractions) These helpers provide high-level abstractions for common DeFi protocol archetypes. #### Uniswap V2/V3-like Protocols * **`uniV2Exports` / `getUniV2LogAdapter`**: Generates adapter configurations for Uniswap V2-style DEXes across multiple chains. ```typescript import { uniV2Exports } from '../helpers/uniswap'; // Example for a Uniswap V2 fork on BSC export default uniV2Exports({ [CHAIN.BSC]: { factories: ['0x123...abc'], // Factory address fees: { type: 'fixed', // Or 'variable' or 'stable' feesPercentage: 0.3 // Swap fee percentage } } // Other chains... }); ``` Examples: * [Nile Exchange V1](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/nile-exchange/index.ts) (V2-style) * [Hydrometer](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/hydrometer/index.ts) * [ABCDEFX](https://github.com/DefiLlama/dimension-adapters/blob/master/dexs/abcdefx/index.ts) * **`uniV3Exports`**: Creates adapters for Uniswap V3-style DEXes, supporting variable fees and multiple pools. ```typescript import { uniV3Exports } from '../helpers/uniswap'; // Example for a Uniswap V3 fork on Scroll export default uniV3Exports({ [CHAIN.SCROLL]: { factory: '0xAAA32926fcE6bE95ea2c51cB4Fcb60836D320C42', // Optional custom fee handling or additional configurations } // Other chains... }) ``` Example: * [2thick](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/2thick.ts) (V3-style) #### Compound V2-like Protocols * **`compoundV2Export`**: Creates an adapter for Compound V2-like protocols, taking config parameters and returning an object that tracks fees, revenue, and distribution among holders and suppliers. ```typescript import { compoundV2Export } from '../helpers/compound'; // Example for a Compound V2 fork on Ethereum export default compoundV2Export({ reserveFactor: 0.1, // Example: 10% of interest goes to protocol markets: { [CHAIN.ETHEREUM]: { comptroller: '0x123...abc', // Comptroller address // ... other market parameters like specific cToken addresses if needed } // Other chains... } }); ``` Example: * [Strike](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/strike/index.ts) ### Token Tracking Helpers Functions for tracking native and ERC20 token movements. * **`addTokensReceived`**: Tracks ERC20 token transfers received by specified addresses. Supports filtering by sender/receiver and custom token transformations. Uses indexer first, then logs. ```typescript import { addTokensReceived } from '../../helpers/token'; const fetch: any = async (options: FetchOptions) => { const dailyFees = await addTokensReceived({ options, tokens: ["0x4200000000000000000000000000000000000006"], // WETH on Base targets: ["0xbcb4a982d3c2786e69a0fdc0f0c4f2db1a04e875"] // Treasury }) return { dailyFees, dailyRevenue: dailyFees } } ``` Example: * [Synthetix](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/synthetix.ts) * **`addGasTokensReceived`**: Tracks native token transfers (like ETH) received by specified multisig addresses. ```typescript import { addGasTokensReceived } from '../../helpers/token'; const fetch = async (options: FetchOptions) => { const dailyFees = await addGasTokensReceived({ options, multisigs: ["0x123...abc", "0x456...def"] // Treasury multisig addresses }); return { dailyFees, dailyRevenue: dailyFees }; } ``` * **`getETHReceived`**: Tracks native token transfers on EVM chains via Allium DB queries. ```typescript import { getETHReceived } from '../../helpers/token'; const fetch = async (options: FetchOptions) => { const balances = options.createBalances(); await getETHReceived({ options, balances, target: "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045" // Treasury address }); return { dailyFees: balances, dailyRevenue: balances }; } ``` [Example Implementation - DexTools](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/dextools.ts) * **`getSolanaReceived`**: Fetches token transfers to specified Solana addresses, allows blacklisting senders/signers. ```typescript import { getSolanaReceived } from '../../helpers/token'; const fetch = async (options: FetchOptions) => { const dailyFees = options.createBalances(); await getSolanaReceived({ options, balances: dailyFees, target: "9yMwSPk9mrXSN7yDHUuZurAh1sjbJsfpUqjZ7SvVtdco", // Treasury blacklists: ["3xxxx..."] // Optional senders to exclude }); return { dailyFees, dailyRevenue: dailyFees }; } ``` Example: * [Axiom](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/axiom.ts) ### EVM Data Helpers Functions for querying EVM logs and indexers. * **`getLogs`** (Available via `options.getLogs`): Retrieves event logs based on filters (target, signature, topics). ```typescript const fetch = async (options: FetchOptions) => { // options includes getLogs const dailyFees = options.createBalances(); const logs = await options.getLogs({ target: "0xcf205808ed36593aa40a44f10c7f7c2f67d4a4d4", eventAbi: 'event Trade(address trader, address subject, bool isBuy, uint256 shareAmount, uint256 ethAmount, uint256 protocolEthAmount, uint256 subjectEthAmount, uint256 supply)' }); logs.forEach(log => { dailyFees.addGasToken(log.protocolEthAmount); }); return { dailyFees }; } ``` [Example Implementation - Ostium](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/ostium/index.ts) * **`queryIndexer`**: Executes queries against DefiLlama's indexers (transfers, events, etc.). ```typescript import { queryIndexer } from '../../helpers/indexer'; const fetch = async (options: FetchOptions) => { const transfers = await queryIndexer({ chain: options.chain, fromTimestamp: options.startTimestamp, toTimestamp: options.endTimestamp, type: 'Transfer', // Example: query token transfers filter: { to: "0x123...abc" } }); const dailyFees = options.createBalances(); transfers.forEach(t => dailyFees.add(t.token, t.value)); return { dailyFees }; } ``` [Example Implementation - Sudoswap V2](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/sudoswap-v2.ts) ### Query Engine Helpers Functions for querying external data platforms. * **`queryDuneSql`** (Available via `options.queryDuneSql`): Executes SQL queries against Dune Analytics. ```typescript const fetch = async (options: FetchOptions) => { // options includes queryDuneSql const dailyFees = options.createBalances(); const results = await options.queryDuneSql(` SELECT SUM(fee_amount) as fees FROM ethereum.transactions WHERE to = '0x123...abc' AND block_time BETWEEN to_timestamp(${options.startTimestamp}) AND to_timestamp(${options.endTimestamp})` ); if (results && results.length > 0) { dailyFees.addGasToken(results[0].fees); } return { dailyFees }; } ``` [Example Implementation - Pumpswap](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/pump-swap/index.ts) * **`queryAllium`** (Available via `options.queryAllium`): Queries the Allium database. ```typescript const fetch = async (options: FetchOptions) => { // options includes queryAllium const dailyFees = options.createBalances(); const result = await options.queryAllium(` SELECT SUM(value) as revenue FROM ethereum.transactions WHERE to_address = '0x123...abc' AND block_timestamp BETWEEN TO_TIMESTAMP_NTZ(${options.startTimestamp}) AND TO_TIMESTAMP_NTZ(${options.endTimestamp}) `); if (result && result.length > 0) { dailyFees.addGasToken(result[0].revenue); } return { dailyFees }; } ``` ### Chain-Specific Helpers Helpers tailored for specific chains or L2s. * **`fetchTransactionFees`** (Available via `options.fetchTransactionFees`): Retrieves total native token transaction fees burned/collected by the network. ```typescript const fetch = async (options: FetchOptions) => { // options includes fetchTransactionFees const dailyFees = await options.fetchTransactionFees(); // Assumes network fees are protocol revenue return { dailyFees, dailyRevenue: dailyFees }; } ``` ### General Helpers Utility functions for common adapter patterns. * **`startOfDay`** (Available via `options.startOfDay`): Converts `options.endTimestamp` to 00:00:00 UTC for data sources requiring exact day timestamps. ```typescript const fetch = async (options: FetchOptions) => { const startOfDayTimestamp = options.startOfDay; // Use startOfDayTimestamp in API calls requiring a 00:00:00 timestamp // e.g., const data = await fetchAPI(`...?date=${startOfDayTimestamp}`); // ... } ``` ### Helper Source Code Reference You can find the full source code for these helper functions in the DefiLlama GitHub repository: * [Token Helpers](https://github.com/DefiLlama/dimension-adapters/blob/master/helpers/token.ts) - Contains functions like addTokensReceived, getETHReceived, getSolanaReceived, etc. * [Uniswap Helpers](https://github.com/DefiLlama/dimension-adapters/blob/master/helpers/uniswap.ts) - Contains uniV2Exports, uniV3Exports * [Compound Helpers](https://github.com/DefiLlama/dimension-adapters/blob/master/helpers/compoundV2.ts) - Contains compoundV2Export * [Aave Helpers](https://github.com/DefiLlama/dimension-adapters/blob/master/helpers/aave/index.ts) - Contains aaveExports ## Frequently Asked Questions ### How does DeFiLlama ensure data quality and accuracy? **Code Review Process**: Each protocol adapter undergoes peer review by llamas through GitHub pull requests. This ensures code quality, data accuracy, and that a consistent methodology is applied to all protocols for the same metrics before any adapter goes live. **Methodology Consistency**: We maintain a uniform methodology across all protocol adapters and chains. Whenever the methodology evolves, our team propagates the update to every relevant adapter to ensure figures remain fully comparable across protocols. **Monitoring Systems**: We maintain internal alert systems that detect unusual data spikes, broken adapters, and anomalies across both TVL and dimension adapters (fees/revenue/volume). This allows the team to quickly identify and fix issues. **Historical Data Integrity**: When protocols add new components (like treasury wallets, new contracts, etc.), we backfill historical data to maintain completeness and accuracy. This ensures users have access to accurate historical insights. ### Data Classification Rules * **Fees**: Only fees paid by users for a transaction/storage/etc should be tracked as fees. Block rewards are a cost and must be tracked as incentives, not fees. * **Revenue**: Only the part of fees that gets burnt (or similar) can be tracked as revenue. The part that goes to stakers does not benefit the chain/holders β€” make sure to tag these correctly in the breakdown. * **Holder revenue**: Usually the same as revenue unless a portion is set aside for the protocol (like in the case of Zcash). * **Chain fees**: Track only the transaction fees paid by users. Do not include perp DEX fees for protocols like Hyperliquid L1 β€” those are counted under the perp listing. ### How we handle data integrity and keep data organic? **Wash Trading Detection**: We actively identify and remove wash trading volumes to prevent them from undermining legitimate trading data. **TVL Percentage Rules**: For pools with very low fee percentages (like 0.01%) that enable wash trading, we apply minimum TVL percentage rules. Only volume from pools meeting these thresholds is counted, effectively filtering out wash trading while preserving legitimate activity. **Chain-Specific Considerations**: * **Solana**: Due to lower transaction fees that make wash trading more viable, we apply TVL percentage filters to major Solana DEXs while maintaining legitimate volumes * **BSC**: During farming campaigns that create wash trading incentives for low-liquidity pairs, we remove affected pairs to maintain data integrity ### How can I report data issues or provide feedback? You can report issues or provide feedback by sending an email to Llamas regularly review feedback and implement necessary fixes to maintain the highest data quality standards across all adapters. # Listing your project {% hint style="warning" %} **Note (Updated: 2025-05-01):** This page might contain outdated information. For the most up-to-date documentation, please visit the main [Building Dimension Adapters](/list-your-project/other-dashboards) guide. {% endhint %} ## Listing your project Same as TVL adapters, the majority of adapters for the dashboards under this section are contributed and maintained by their respective communities, with all changes being coordinated through the [`DefiLlama/dimension-adapters` github repo](https://github.com/DefiLlama/dimension-adapters). Here you will find information about how you can list your DeFi project to one of the following dashboards: * **Dexs dashboard**. Tracks volume from different dexs (only spot/swaps). * **Aggregators dashboard**. Tracks `volume` from different aggregators. * **Fees dashboard**. Tracks `fees` and `revenue` from different protocols. * **Derivatives dashboard**. Tracks `volume` from different protocols. * **Options dashboard**. Tracks notional and premium `volume` from different options dexs. The simple instructions to add your project are: 1. Fork the [`dimension-adapters`](https://github.com/DefiLlama/dimension-adapters) repository. 2. Add a new folder with the slug of the project under the respective adapters folder. 3. Add your adapter to an `index.ts` file and export it. It should look like this: `./[dashboard]/[slug]/index.ts`. You will find more information in the next sections. 4. Test that the adapter works correctly by running `yarn test [dashboard] [protocolSlug]`. You will find more information in the next sections. 5. Submit a PR! A llama will take a look at it and merge it. Once merged, it can take up to 24h to be available in the dashboard. {% hint style="info" %} Seeing issues getting logs or with calls at historical blocks?\ You can replace the RPC being used by creating a .env file and filling it with rows like this:\ ETHEREUM\_RPC="https\://..." BSC\_RPC="https\://..." POLYGON\_RPC="https\://..."\ ... {% endhint %} # How to build an adapter {% hint style="warning" %} **Note (Updated: 2025-05-01):** This page might contain outdated information. For the most up-to-date documentation, please visit the main [Building Dimension Adapters](/list-your-project/other-dashboards) guide. {% endhint %} ## How to build an adapter And adapter is just some code that: 1. Collects data on a protocol by calling some endpoints or making some blockchain calls 2. Computes a response and returns it. That's just a typescript file that exports an async function that is given start and end timestamps (and block numbers) and returns an object with metrics for the time range between those two timestamps. A really simplified version of an adapter could be the following lines: ```typescript import { FetchOptions, SimpleAdapter } from "../adapters/types"; import { CHAIN } from "../helpers/chains"; import { queryDune } from "../helpers/dune"; const fetch: any = async (options: FetchOptions) => { const dailyFees = options.createBalances(); const value = (await queryDune("3521814", { start: options.startTimestamp, end: options.endTimestamp, receiver: '9yMwSPk9mrXSN7yDHUuZurAh1sjbJsfpUqjZ7SvVtdco' })); dailyFees.add('So11111111111111111111111111111111111111112', value[0].fee_token_amount); return { dailyFees, dailyRevenue: dailyFees } } export default { version: 2, adapter: { [CHAIN.SOLANA]: { fetch: fetch, start: 0, }, }, }; ``` The above adapter is for a protocol that is deployed on `solana`, and will return the daily fees and revenue for the time period between startTimestamp and endTimestamp. Depends on which dashboard the adapter is aiming for, it should return different attributes. We call those attributes dimensions. In the next page you will find a detailed list of all supported dimensions. #### BaseAdapter In the above example, the object under the key `solana` is what we call a `BaseAdapter` and it contains all the methods and information needed to list, collect data and enable your project. The attribute `fetch` is the most important part of the BaseAdapter but not the only attribute needed to list your project. Other important attributes needed for an optimal listing are: * `fetch`: Promise that returns different dimensions of a protocol. The dimensions returned depends on which adapter you would like to list your project (e.g. \`dailyVolume\` for the [dexs dashboard](https://defillama.com/dexs)). * `start`: The earliest timestamp we can pass to the fetch function. This tells our servers how far can we get historical data. * `runAtCurrTime`: Boolean that flags if the adapter takes into account the timestamp and block passed to the fetch function (`runAtCurrTime: false`) or if it can only return the latest data, for example there are some adapters that are only able to return the volume of the past 24h from the moment the adapter is executed (`runAtCurrTime: true`). * `meta`: Object that contains metadata of the BaseAdapter. The possible attributes are: * `methodology`: Object that describes the methodology used to calculate the different dimensions returned. Find an example [here](https://github.com/DefiLlama/dimension-adapters/blob/c03a108f546707ab75ef727d33cef053348757dd/protocols/pancakeswap/index.ts#L43). * `hallmarks`: Set of events that greatly affected protocol data and we display on the chart ([example](https://defillama.com/protocol/uniswap)). Besides these, you'll find the `version` key, this should always be `2` except in the case where the adapter can only run for time ranges that start at 0:00 and end at 0:00 of the next day, in that case version must be `1`. Typically this happens with APIs that return volume for each day and don't allow more precise time periods. #### Some other examples You can use getLogs() to get all event logs in the timeframe between the two timestamps automatically, in the following case we use it to get the logs emitted by the friendtech contract on every trade, which is then used to calculate fees and revenue (in this case fees is twice the value of revenue, since on every trade, 50% of the fee goes to the protocol and 50% to the room creator). ```typescript import { Adapter, FetchV2, } from "../adapters/types"; import { CHAIN } from "../helpers/chains"; export default { adapter: { [CHAIN.BASE]: { fetch: (async ({ getLogs, createBalances, }) => { const dailyFees = createBalances() const dailyRevenue = createBalances() const logs = await getLogs({ target: "0xcf205808ed36593aa40a44f10c7f7c2f67d4a4d4", eventAbi: 'event Trade(address trader, address subject, bool isBuy, uint256 shareAmount, uint256 ethAmount, uint256 protocolEthAmount, uint256 subjectEthAmount, uint256 supply)' }) logs.map((e: any) => { dailyFees.addGasToken(e.protocolEthAmount * 2) dailyRevenue.addGasToken(e.protocolEthAmount) }) return { dailyFees, dailyRevenue, } }) as FetchV2, start: 1691539200, }, }, version: 2, } as Adapter ``` Since most adapters follow a similar structure, we've written some helper functions that you might help you writing your adapter. You will find information about these functions in the next pages. # Dimensions {% hint style="warning" %} **Note (Updated: 2025-05-01):** This page might contain outdated information. For the most up-to-date documentation, please visit the main [Building Dimension Adapters](/list-your-project/other-dashboards) guide. {% endhint %} ## Dimensions In the previous page we have seen how to create the structure of our adapter. In this section we will focus on explaining the different dimensions that our adapters can return. We call dimension to the attributes returned by the `fetch` function of our adapters. Depending on where would you like to list your project, you should return one of the below dimensions. All dimensions should be returned as balance object (`Object`) where keys are the coins and their values are the amount of each coin. Our code will get the price of each coin and calculate the final result. Examples: ```typescript // volume dimension in tokens object { dailyVolume: { "ethereum:0x0000000000000000000000000000000000000000": "3924300000000" } } ``` > In order to be listed your adapter would need to provide a minimum of one **daily** dimension. Providing all of them is not required but recommended in order to have better insights. {% hint style="info" %} All total values like totalVolume, totalFees, totalRevenue... are OPTIONAL {% endhint %} **Dexs, dexs aggregators and derivatives dimensions:** * `dailyVolume`: (Required for these dashboards) Trading volume for the period. **Options Dimensions:** * `dailyNotionalVolume`: Notional volume of options contracts traded/settled. * `dailyPremiumVolume`: Premium volume collected/paid. **Fees Dimensions:** * `dailyFees`: (**Required**) All fees and value collected from *all* sources (users, LPs, yield generation, liquid staking rewards, etc.), excluding direct transaction/gas costs paid by users to the network. This represents the total value flow into the protocol's ecosystem due to its operation. * `dailyUserFees`: (Optional, but helpful) The portion of `dailyFees` directly paid by end-users (e.g., swap fees, borrow interest, liquidation penalties, marketplace commissions paid by buyers/sellers). * `dailyRevenue`: (**Required**) The portion of `dailyFees` kept by the protocol entity itself, distributed either to the treasury (`dailyProtocolRevenue`) or governance token holders (`dailyHoldersRevenue`). * `dailyRevenue = dailyProtocolRevenue + dailyHoldersRevenue` * `dailyProtocolRevenue`: The portion of `dailyRevenue` allocated to the protocol's treasury or core team. * `dailyHoldersRevenue`: The portion of `dailyRevenue` distributed to governance token holders (e.g., buybacks, burns). * `dailySupplySideRevenue`: The portion of `dailyFees` distributed to liquidity providers, lenders, or other suppliers of capital/resources essential to the protocol's function. * `dailyBribeRevenue`: Governance token paid as bribe/incentive for token holder action. * `dailyTokenTax`: Fees generated from a tax applied to token transfers. ### Fee/Revenue Attribution Examples by Protocol Type If you are unsure how to classify fees and revenues, refer to this table or ask on Discord:
| Attribute | DEXs | Lending | Chains | NFT Marketplace | Derivatives | CDP | Liquid Staking | Yield | Synthetics | | ----------------- | ------------------------------------------- | ------------------------------------------ | ---------------------------------------------- | -------------------------------------- | -------------------------------- | -------------------------- | ------------------------------- | ---------------------------------- | -------------------------------- | | UserFees | Swap fees paid by users | Interest paid by borrowers | Gas fees paid by users | Fees paid by users | Fees paid by users | Interest paid by borrowers | % of rewards paid to protocol | Paid management + performance fees | Fees paid by users | | Fees | =UserFees | =UserFees | =UserFees | =UserFees | UserFees + burn/mint fees | =UserFees | Staking rewards | Yield | =UserFees | | Revenue | % of swap fees going to protocol governance | % of interest going to protocol governance | Burned coins (fees-sequencerCosts for rollups) | Marketplace revenue + creator earnings | Protocol governance revenue | =ProtocolRevenue | =ProtocolRevenue | =ProtocolRevenue | =ProtocolRevenue | | ProtocolRevenue | % of swap fees going to treasury | % of interest going to protocol | \* | Marketplace revenue | Value going to treasury | Interest going to treasury | =UserFees | =UserFees | % of fees going to treasury | | HoldersRevenue | Money going to gov token holders | \* | \* | \* | Value going to gov token holders | \* | \* | \* | % of fees going to token holders | | SupplySideRevenue | LPs revenue | Interest paid to lenders | \* | \* | LP revenue | \* | Revenue earned by stETH holders | Yield excluding protocol fees | LPs revenue | > Some notes: > > * Protocol governance includes treasury + gov token holders > * Revenue = HoldersRevenue + ProtocolRevenue # Important considerations {% hint style="warning" %} **Note (Updated: 2025-05-01):** This page might contain outdated information. For the most up-to-date documentation, please visit the main [Building Dimension Adapters](/list-your-project/other-dashboards) guide. {% endhint %} ## Important considerations **Multiple adapters, same protocol** * If you want to list your protocol in different dashboards you can return in the same adapters dimensions of different dashboards. See the following example: ```typescript const adapter = { adapter: { ..., fetch: async ({ endTimestamp }) => { const { dailyVolume } = await querySubgraph(volumeQuery, endTimestamp) const { dailyFees } = await querySubgraph(feesQuery, endTimestamp) return { dailyVolume, // dimension for dexs dashboard dailyFees, // dimension for fees dashboard } } ..., } } ``` **Methodology** * For fees and revenue adapters please don't forget to include how have you calculated the values in the methodology attribute. ```typescript const adapter = { adapter: { ... fetch: async () => ({ dailyFees: "32498", dailyRevenue: "0", dailySupplySideRevenue: "32498" }), meta: { methodology: { Fees: "User pays 2% of each swap", Revenue: "Protocol takes no revenue", SupplySideRevenue: "LPs revenue is 2% of user fees", } } } } ``` **Incomplete data** * If the adapter is not able to provide data for all dimensions, let's say for example you can only provide data for `dailyVolume` but not for `totalVolume`, please keep the dimension as `undefined`, don't assign an arbitrary value or set to it `"0"`. ```typescript // wrong { dailyFees: "2144", totalFees: "0" // <- wrong!! } // correct { dailyFees: "2144" } ``` * If the adapter can't be used to backfill data and only allows to get data for today's timestamp, please **set the flag** `runAtCurrTime` to `true`. See more about this flag in the previous sections. ```typescript const adapter = { adapter: { fetch: fetchFunction, runAtCurrTime: true } } ``` **Precision** Please, consider using the *BigNumber* library when doing mathematical operations that might result or include a value with a magnitude outside the range of safe values to use in JavaScript. ```typescript const feesInGas = new BigNumber(graphRes["fees"]) const ethGasPrice = await getGasPrice(timestamp) return { dailyRevenue = feesInGas.multiplyBy(ethGasPrice) } ``` # Helper functions {% hint style="warning" %} **Note (Updated: 2025-05-01):** This page might contain outdated information. For the most up-to-date documentation, please visit the main [Building Dimension Adapters](/list-your-project/other-dashboards) guide. {% endhint %} ## Helper Functions This document provides detailed information about the various helper functions available to simplify the creation of adapters. Each section includes example implementations and links to real adapters using these functions. ### Token Tracking Helpers #### addTokensReceived Tracks ERC20 token transfers received by specified addresses. Supports filtering by sender/receiver and custom token transformations. It attempts to use an indexer first for performance, with a fallback to log processing. ```typescript import { addTokensReceived } from '../../helpers/token'; const fetch: any = async (options: FetchOptions) => { const dailyFees = await addTokensReceived({ options, tokens: ["0x4200000000000000000000000000000000000006"], // WETH on Base targets: ["0xbcb4a982d3c2786e69a0fdc0f0c4f2db1a04e875"] // Treasury }) return { dailyFees, dailyRevenue: dailyFees } } ``` [Example Implementation - Synthetix](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/synthetix.ts) #### addGasTokensReceived Tracks native token transfers (like ETH) received by specified multisig addresses. This helper is particularly useful for protocols that collect fees in the chain's native token. ```typescript import { addGasTokensReceived } from '../../helpers/token'; const fetch = async (options: FetchOptions) => { const dailyFees = await addGasTokensReceived({ options, multisigs: ["0x123...abc", "0x456...def"] // Treasury multisig addresses }); return { dailyFees, dailyRevenue: dailyFees }; } ``` #### getETHReceived Tracks native token transfers on EVM chains, supporting multiple chains through Allium database queries. ```typescript import { getETHReceived } from '../../helpers/token'; const fetch = async (options: FetchOptions) => { const balances = options.createBalances(); await getETHReceived({ options, balances, target: "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045" // Treasury address }); return { dailyFees: balances, dailyRevenue: balances }; } ``` [Example Implementation - DexTools](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/dextools.ts) #### getSolanaReceived Fetches token transfers to specified Solana addresses within a given time range, with ability to exclude specific sender addresses or transaction signers. ```typescript import { getSolanaReceived } from '../../helpers/token'; const fetch = async (options: FetchOptions) => { const dailyFees = options.createBalances(); await getSolanaReceived({ options, balances: dailyFees, target: "9yMwSPk9mrXSN7yDHUuZurAh1sjbJsfpUqjZ7SvVtdco", // Treasury blacklists: ["3xxxx..."] // Optional senders to exclude }); return { dailyFees, dailyRevenue: dailyFees }; } ``` [Example Implementation - Jito](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/jito.ts) ### EVM Data Helpers #### getLogs Retrieves event logs from blockchains based on specified filters like target addresses, event signatures, and topics. Essential for tracking on-chain events. ```typescript const fetch = async ({ getLogs, createBalances }) => { const dailyFees = createBalances(); const logs = await getLogs({ target: "0xcf205808ed36593aa40a44f10c7f7c2f67d4a4d4", eventAbi: 'event Trade(address trader, address subject, bool isBuy, uint256 shareAmount, uint256 ethAmount, uint256 protocolEthAmount, uint256 subjectEthAmount, uint256 supply)' }); logs.forEach(log => { dailyFees.addGasToken(log.protocolEthAmount); }); return { dailyFees }; } ``` [Example Implementation - Ostium](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/ostium/index.ts) #### queryIndexer Executes queries against DeFiLlama's indexers to retrieve token transfers, events, and other blockchain data. ```typescript import { queryIndexer } from '../../helpers/indexer'; const fetch = async (options: FetchOptions) => { const transfers = await queryIndexer({ chain: options.chain, fromTimestamp: options.startTimestamp, toTimestamp: options.endTimestamp, filter: { to: "0x123...abc" } }); const dailyFees = options.createBalances(); transfers.forEach(t => dailyFees.add(t.token, t.value)); return { dailyFees }; } ``` [Example Implementation - Sudoswap V2](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/sudoswap-v2.ts) ### Protocol-Specific Helpers #### compoundV2Export Creates an adapter for Compound V2-like protocols, taking config parameters and returning an object that tracks fees, revenue, and distribution among holders and suppliers. ```typescript import { compoundV2Export } from '../helpers/compound'; export default compoundV2Export({ reserveFactor: 0.1, // 10% of interest goes to protocol markets: { [CHAIN.ETHEREUM]: { comptroller: '0x123...abc', // ... other market parameters } } }); ``` [Example Implementation - Strike](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/strike/index.ts) #### uniV2Exports / getUniV2LogAdapter Generates adapter configurations for Uniswap V2-style DEXes across multiple chains. ```typescript import { uniV2Exports } from '../helpers/uniswap'; export default uniV2Exports({ [CHAIN.BSC]: { factories: [ '0x123...abc' // Factory address ], fees: { type: 'fixed', feesPercentage: 0.3 // 0.3% fee } }, // Other chains }); ``` [Example Implementation - Nile Exchange V1](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/nile-exchange-v1/index.ts) [Example Implementation - Hydrometer](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/hydrometer/index.ts) [Example Implementation - ABCDEFX](https://github.com/DefiLlama/dimension-adapters/blob/master/dexs/abcdefx/index.ts) #### uniV3Exports Creates adapters for Uniswap V3-style DEXes, supporting variable fees and multiple pools. ```typescript import { uniV3Exports } from '../helpers/uniswap'; export default uniV3Exports({ [CHAIN.ETHEREUM]: { factory: '0x1F98431c8aD98523631AE4a59f267346ea31F984', // Optional custom fee handling or additional configurations } }); ``` [Example Implementation - 2thick](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/2thick.ts) ### Query Engine Helpers #### queryDuneSql Executes SQL queries against the Dune Analytics database. ```typescript import { queryDuneSql } from '../helpers/dune'; const fetch = async (options: FetchOptions) => { const results = await queryDuneSql( options, `SELECT SUM(fee_amount) as fees FROM ethereum.transactions WHERE to = '0x123...abc' AND block_time BETWEEN to_timestamp(${options.startTimestamp}) AND to_timestamp(${options.endTimestamp})` ); const dailyFees = options.createBalances(); dailyFees.addGasToken(results[0].fees); return { dailyFees }; } ``` [Example Implementation - Pumpswap](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/pump-swap/index.ts) #### queryAllium Queries the Allium database for blockchain data across multiple chains. ```typescript import { queryAllium } from '../helpers/allium'; const fetch = async (options: FetchOptions) => { const result = await queryAllium(` SELECT SUM(value) as revenue FROM ethereum.transactions WHERE to_address = '0x123...abc' AND block_timestamp BETWEEN TO_TIMESTAMP_NTZ(${options.startTimestamp}) AND TO_TIMESTAMP_NTZ(${options.endTimestamp}) `); const dailyFees = options.createBalances(); dailyFees.addGasToken(result[0].revenue); return { dailyFees }; } ``` #### getGraphDimensions2 Alternative implementation of getGraphDimensions with a simplified approach for newer adapter versions. ```typescript import { getGraphDimensions2 } from '../helpers/getUniSubgraphVolume'; const adapter = getGraphDimensions2({ graphUrls: { [CHAIN.ETHEREUM]: 'https://api.thegraph.com/subgraphs/name/protocol/subgraph', }, feesPercent: 0.3, dailyFeeField: 'feesUSD', // Additional configuration options }); ``` [Example Implementation - Quickswap](https://github.com/DefiLlama/dimension-adapters/blob/master/fees/quickswap.ts) ### Chain-Specific Helpers #### fetchTransactionFees Retrieves the total transaction fees for a specific blockchain network within a given time range. ```typescript import { fetchTransactionFees } from '../helpers/chain-fees'; const fetch = async (options: FetchOptions) => { const dailyFees = await fetchTransactionFees(options); return { dailyFees }; } ``` ### Helper Function Reference You can find the full source code for these helper functions in the DefiLlama GitHub repository: * [Token Helpers](https://github.com/DefiLlama/dimension-adapters/blob/master/helpers/token.ts) - Contains functions like addTokensReceived, getETHReceived, etc. * [Uniswap Helpers](https://github.com/DefiLlama/dimension-adapters/blob/master/helpers/uniswap.ts) - Contains uniV2Exports, uniV3Exports * [Compound Helpers](https://github.com/DefiLlama/dimension-adapters/blob/master/helpers/compound.ts) - Contains compoundV2Export * [Graph Helpers](https://github.com/DefiLlama/dimension-adapters/blob/master/helpers/getUniSubgraphVolume.ts) - Contains getGraphDimensions2 **Exact day timestamp** Some data sources are only able to return data given a 00:00:00 day timestamp. In that case you can use the parameter `startOfDay` to get the timestamp of the specific day. For example passing `1663718399 (2022-09-20T23:59:59.000Z)` timestamp will return `1663632000000 (2022-09-20T00:00:00.000Z)` # Testing {% hint style="warning" %} **Note (Updated: 2025-05-01):** This page might contain outdated information. For the most up-to-date documentation, please visit the main [Building Dimension Adapters](/list-your-project/other-dashboards) guide. {% endhint %} ## Testing After adding your adapter to the correct folder, you will be able to test it by checking the output of the following command: ``` > npm test [dashboard] [protocolSlug] ``` or ``` > npm test [dashboard] [protocolSlug] [timestamp] ``` Being `[dashboard]` one of the following values: `dexs`, `fees`, `incentives`, `aggregators`, `options`, `derivatives`. `[protocolSlug]` the name of your protocol and `[timestamp]` as optional parameter the timestamp of the day passed to the adapter to test if the adapter is able to return a response based on a given time. Examples: ``` > npm test fees bitcoin ``` ``` > npm test dexs uniswap 1662110960 ``` # Oracles TVS Our TVS methodology is guided by the principle: "If the oracle malfunctions, would assets be lost?" **Total Value Secured (TVS)** is a metric used to calculate the value secured by each oracle. It estimates the potential financial loss in case an oracle malfunctions or reports incorrect data. The TVS for an oracle is determined by summing the Total Value Locked (TVL) of all protocols dependent on that oracle, which would be susceptible to loss if the oracle fails. ## Methodology * **Primary Calculation**: * TVS is calculated by aggregating the TVL of all protocols that rely on a specific oracle. * If an oracle failure would result in loss of funds in a protocol, that protocol's TVL is added to the oracle's TVS. * **Edge Cases**: * **Protocols Using Multiple Oracles**: * If the failure of any oracle used by a protocol could cause a total TVL loss, the full protocol TVL is added to the TVS of all involved oracles. * Example: Euler uses Chainlink and Uniswap v3 TWAPs for pricing different assets. A failure in either oracle could lead to the protocol being drained. Thus, Euler's TVL is included in the TVS of both Chainlink and Uniswap TWAPs. * **Different Oracles for Different Chains**: * TVL on each chain is attributed to the oracle used on that chain. * Example: If a protocol uses Chainlink on Ethereum and Switchboard on Solana, Ethereum's TVL counts towards Chainlink, and Solana's TVL counts towards Switchboard. * **Partial Oracle Usage**: * If an oracle secures only a small portion of a protocol (e.g., 5% of TVL), and a hack of the oracle won't lead to >50% TVL loss, that oracle is not counted. * These cases are rare and generally negligible (<0.1% effect on TVS numbers). * **Failover Mechanisms**: * For protocols with failover oracles, the primary question remains: *If the failover oracle malfunctioned, would assets be lost?* * If assets are unaffected by the failover oracle's failure, its TVS is not impacted. Loss occurs only if both the primary and failover oracles fail simultaneously. * **Exclusions**: * **Centralized Exchanges (CEXs)**: * Oracles used in CEXs, such as index price feeds for perpetuals, are excluded from TVS due to: 1. Aggregation with multiple data sources (e.g., spot prices from other CEXs). 2. Fail-safes in place (e.g., withdrawal rate limits, rollback of positions in case of manipulation). ## Oracle to Blockchain Assignment **Example:** ```javascript oraclesBreakdown: [ { name: "Chainlink", type: "Primary", proof: ["https://docs.yourprotocol.com/oracles"], startDate: "2023-01-01", chains: [ { chain: "ethereum" }, { chain: "polygon", startDate: "2023-03-01" }, ] }, { name: "RedStone", type: "Fallback", proof: ["https://github.com/yourprotocol/contracts/blob/main/RedstoneOracle.sol"] }, { name: "AnotherOracle", type: "RNG", proof: ["https://docs.yourprotocol.com/randomness"] } ] ``` **Supported type values:** * **"Primary"**: Main oracle that secures >50% of TVL. If compromised, a majority of funds would be at risk. * **"Secondary"**: Actively used oracle that secures <50% of TVL. * **"Fallback"**: Not used under normal conditions; used only if primary/secondary fails. * **"Aggregator"**: Used alongside other oracles in a combined feed (e.g., median across 3 sources). Failure alone does not cause TVL loss. * **"RNG"**: Used for randomness only (e.g., in games or lottery apps). No TVL is at risk. * **"Reference"**: Used for price display or off-chain quoting. Not directly used for critical protocol operations that would result in TVL loss if the oracle fails. * **"PoR"**: Proof of Reserve oracle, used to prove the protocol has the reserves to back the TVL **Required fields:** * `name`: Name of the oracle provider (e.g., Chainlink, Pyth). * `type`: Oracle classification as defined above. * `proof`: At least one link (docs, code, or audit) showing the oracle integration. **Optional fields:** * `startDate` / `endDate`: Use these to indicate the active period (format: YYYY-MM-DD).\ If `startDate` is not provided, we assume the oracle has been active since the protocol's launch. * `chains`: List of chain slugs from , with optional start/end dates per chain.\ If `chains` is not specified, we assume the oracle is used on **all chains** where the protocol is live. This structured format ensures accurate attribution of TVL to oracles based on actual usage and risk exposure. ## How to Add a New Oracle to DefiLlama To add a new oracle to DefiLlama, follow these steps: ### 1. Identify a Protocol Using the Oracle Find a protocol that uses the oracle and is tracked by DefiLlama. If it's not yet tracked, let us know on Discord. ### 2. Prepare the Oracle Metadata Locate the appropriate protocol entry and prepare the oracle information using the `oraclesBreakdown` format. Example: ``` oraclesBreakdown: [ { name: "Chainlink", type: "Primary", proof: ["https://docs.yourprotocol.com/oracles"], startDate: "2023-01-01", chains: [ { chain: "ethereum" }, { chain: "polygon", startDate: "2023-03-01" }, ] }, { name: "RedStone", type: "Fallback", proof: ["https://github.com/yourprotocol/contracts/blob/main/RedstoneOracle.sol"] }, { name: "AnotherOracle", type: "RNG", proof: ["https://docs.yourprotocol.com/randomness"] } ] ``` ### 3. Include the Following Information in Your Submission When submitting oracle metadata, include answers to the following questions: **Oracle Provider(s):** Specify the oracle(s) used (e.g., Chainlink, Band, API3, TWAP, etc.). **Implementation Details:** Briefly describe how the oracle is integrated into your project. **Documentation/Proof:** Provide links to documentation, source code, audits, or other resources that verify the oracle's usage. **Failure Scenario & Loss Quantification (for non-price oracles):** Describe a realistic scenario in which your oracle provides incorrect, stale, or manipulated non-price data. Explain how such a malfunction could lead to on-chain asset loss or protocol malfunction, and estimate the TVL at risk under that scenario. ### 4. Submit via Email Email all oracle metadata and supporting documentation to: [**metadata@defillama.com**](mailto:metadata@defillama.com) Please include: * Protocol name * Oracle provider(s) * Oracle type(s) * Supporting documentation and proof links * Chain-specific oracle usage (if applicable) * Failure scenario analysis (for non-price oracles) The DefiLlama team will review the submission and update the oracle metadata accordingly. # Token Rights ## What this Framework Does Understanding what a token represents requires substantial effort. Does it grant governance rights? Does it capture protocol revenue? Who owns the brand and IP? The answers exist, but they're often scattered across documentation, governance forums and entity structures. Each token is different, and finding these differences can be difficult and time-consuming. The Token Rights Framework puts the most important information in one place, with sources available to dive deeper. It provides a systematic way to evaluate and compare token rights across DeFi protocols by collecting and organizing data about governance power, economic benefits, and legal ownership. ### The Three Core Questions Every token holder should be able to answer these questions: 1. **Governance**: What decisions can token holders vote on? 2. **Economic**: How does the token capture value from a protocol? 3. **Ownership**: Who actually owns the protocol's assets? The framework organizes all data collection around these three categories. ### Classification Structure * **Governance Rights** Governance rights define what token holders can control through voting. This category tracks the scope and mechanics of onchain governance. Not all governance is equal. Some tokens let holders vote on everything from protocol parameters to treasury spending. Some limit voting or require staking to participate. Governance-only tokens can have value, but investors need to understand what power they actually have. If a protocol makes all meaningful decisions offchain or through a separate company, it's important for token holders to know that. * **Economic Rights** Economic rights define how token holders capture value generated by the protocol. This includes mechanisms like buybacks, burns, revenue sharing, fee burns, and the primary way a token accrues value, if at all. Revenue flows determine whether token holders benefit financially from protocol success. A protocol can generate millions in fees, but the token may not capture that economic activity. Many protocols have "fee switches" that can direct revenue to token holders. Understanding whether this economic function is active, pending, or non-existent is critical for valuation. * **Ownership Rights** Ownership rights identify who legally owns the protocol's assets and whether there are conflicts between token holders and equity holders. Protocols can have multiple entities (DAO, Foundation, Labs, equity-funded company, etc). The brand name, domain, IP, and development resources may be owned by a company, not by token holders. Understanding the entity structure helps token holders identify what might be included in an acquisition or corporate restructuring. ### Data Definitions ### Governance Rights #### **Governance Decisions** * Whether token holders can vote on governance proposals (Token / None / Unknown) * Detailed explanation of governance scope and mechanics * Why we track it: Base level governance right - can holders vote at all? Can holders vote on everything? Are there restrictions? Do they need to stake? Is there a token threshold to create proposals? #### **Treasury Decisions** * Whether token holders can vote on treasury allocation (Token / None / Unknown) * Detailed explanation of treasury governance mechanics and constraints * Why we track it: Treasury control is a key governance right - it determines if holders can direct what happens with a protocol’s treasury #### **Revenue Decisions** * Whether token holders can vote on revenue allocation (Token / None / Unknown) * Detailed explanation of revenue governance mechanics and allocation options * Why we track it: This determines if holders can activate fee switches or change how protocol revenue is used. Can holders vote to redirect revenue streams? Are there limitations on how revenue can be allocated? What percentage of revenue is within governance scope versus automatically distributed to other stakeholders? #### **Fee Switch Status** * Current state of the fee switch mechanism (ON / OFF / PENDING / UNKNOWN) * Why we track it: Indicates whether token holders are currently receiving value from protocol revenue, or might be in the future #### **Fee Switch Details** * Explanation of fee switch mechanics and history * Why we track it: Details are important for valuation. How much revenue goes to token holders? What's the governance process to turn it on? Has it been attempted before? ### Economic Rights #### **Buybacks** * Whether the protocol uses revenue to buy back tokens * Why we track it: Buybacks reduce circulating supply and are a form of value return to holders #### **Dividends / Revenue Share** * Whether token holders receive direct distributions from protocol revenue * Why we track it: Revenue sharing is a direct economic right granted to token holders, similar to equity dividends #### **Burns** * Whether tokens are burned (permanently removed from supply) * Why we track it: Burns directly reduce token supply, creating deflationary pressure #### **Value Accrual** * Main source by which value accrues to token holders * Why we track it: Summary of economic rights - shows the main way token holders capture value, if at all #### **Value Accrual Definition** * Detailed explanation of how value accrual works * Why we track it: The specifics of economic models vary widely and require explanation ### Ownership Rights #### **Associated Entities** * List of all entities involved (DAO, Labs, Foundation, DevCo, Equity Company, etc.) * Why we track it: Maps the organizational structure to identify who controls what #### **IP & Brand** * Who owns the intellectual property and brand/trademark (Entity name / DAO / Unknown) * Why we track it: IP ownership determines who can monetize the protocol name and who benefits in a potential acquisition #### **Domain** * Who owns the primary domain name (Entity name / DAO / Unknown) * Why we track it: Domain ownership controls user access and can be used to capture value independently of token holders #### **Raise History** * Whether the protocol raised funds through equity or token sales, including details and links * Why we track it: Equity raises create a separate class of stakeholders with potentially different incentives than token holders. Transparency about who invested, how much, and at what valuation helps identify potential conflicts #### **Equity Revenue Capture** * Whether equity holders capture protocol revenue separately from token holders (YES / NO / PARTIAL / UNKNOWN) * Why we track it: This is a key misalignment risk. If a Labs entity captures fees before they reach the DAO, this should be transparent. #### **Equity Statement** * Additional context about the equity/token relationship * Why we track it: Provides nuance about alignment or conflicts between stakeholders ### Resources #### **Foundation Multisigs / Addresses** * Links to publicly disclosed treasury addresses * Why we track it: Transparency check - can token holders verify treasury holdings? #### **Latest Treasury / Token Report** * Link to the most recent financial disclosure * Why we track it: Helps investors verify data and assess transparency practices ### Frequently Asked Questions #### Why do we separate governance, economic, and ownership rights? Because they're independent. A token can have strong governance rights but no economic rights. Or it can have economic rights (revenue sharing) but limited governance. Many protocols are different, and understanding the nuance is important. #### What's the difference between Revenue Decisions and a Fee Switch? Revenue Decisions ask: "Can token holders vote on what happens to protocol revenue?" A fee switch is a specific mechanism that directs revenue to token holders. You can have Revenue Decisions rights without having an active fee switch. #### Why does ownership matter if I have governance rights? Because governance doesn't always control everything. If a Labs entity owns the domain, brand, and IP, they can monetize those assets independently of governance. #### What's "Equity Revenue Capture" and why does it matter? This tracks whether equity holders (VC investors, team) receive protocol revenue through corporate structures separate from token holders. This helps token holders understand which parties benefit from protocol growth. #### Why track both "Buybacks" and "Burns"? They're different mechanisms. Buybacks use protocol funds to purchase tokens from the market (reducing circulating supply, potentially creating buy pressure). Burns permanently destroy tokens (reducing total supply). A protocol might do one, both, or neither. #### What if the protocol says "Fee Switch: OFF" but plans to turn it on later? That's why we track both Status and Details. The Status field shows current reality. The Details field explains plans, governance proposals, and history. Investors can assess both current value accrual and potential future value accrual. #### Why ask about fundraising history? Because it reveals potential conflicts. If a protocol raised $50M in equity funding, those investors have their own claims on value. Understanding the entity structure helps identify if equity and token interests are aligned or competing. #### What counts as "Utility"? Utility means functional benefits from holding the token beyond governance and speculation. Examples: staking for rewards, fee discounts, access to protocol features, liquidity mining incentives, collateral in lending, required holdings for certain actions. #### How do we verify this data? We ask protocols to provide documentation, links to governance proposals, onchain addresses, and official reports. Everything is cross-checked against public information. When data is unavailable or unclear, we mark it as "Unknown". Any protocol wishing to have their token rights added can fill out the form at the bottom of this page. #### Why not create risk scores or ratings? We present data, not opinions. An "alignment score" or "governance quality rating" would inject our judgment into what should be objective information. Our goal is to provide helpful data that investors can look at and reach their own conclusions about what matters to them. #### What if a protocol has multiple tokens? We track each token separately since they often have different rights. A protocol might have a governance token and a separate revenue-sharing token. The framework captures that distinction. #### Who uses this data? * Token holders trying to understand what they own * Prospective investors comparing protocols before buying * Protocols looking to benchmark their tokenomics * Researchers analyzing token design #### How is this different from existing token classification frameworks? Most frameworks classify tokens by technical properties (ERC-20 vs ERC-721) or high-level categories (governance vs utility). This framework focuses on rights and value capture. It asks: * What can token holders control? * How do they benefit economically? * Who owns the underlying assets? These are the questions that matter for investment decisions. ### Ready to submit your protocol’s Token Rights? ### [Fill out this form](https://forms.defillama.com/token-rights) # Overview ## Google Sheets ### Installation Open the extension page on [Google Workspace Marketplace](https://workspace.google.com/marketplace/app/defillama_sheets/571407189628) to install the add-on. ### Setup 1. **Extensions** β†’ **DefiLlama** β†’ **Open Sidebar** 2. Click **Sign In** 3. Authorize with your defillama account ### Test ```excel =DEFILLAMA("price", "Bitcoin") ``` *** ## Excel ### Installation 1. Open Excel 2. **Insert** β†’ **Add-ins** -> **More Add-ins** 3. Search "DefiLlama" 4. Click **Add** ### Setup 1. Click **DefiLlama Sheets** 2. Click **Sign In** 3. Authenticate with your account ### Test ```excel =DEFILLAMA("tvl", "Ethereum") ``` ### Troubleshooting * **#NAME? error**: Restart Excel, ensure add-in is enabled * **Auth issues**: Sign out and sign in again via task pane ### In case of any issues, questions or feedback, please contact us at *** ## Quick Examples ```excel // Current data =DEFILLAMA("tvl", "Ethereum") =DEFILLAMA("fees", "Uniswap", "24h") =DEFILLAMA("price", "Bitcoin") // Historical =DEFILLAMA_HISTORICAL("tvl", "Aave", "2024-01-01") // Yields =DEFILLAMA_YIELD("Arbitrum", "USDC", "apy", 10) =DEFILLAMA_YIELD_TOP_POOLS(20) // Stablecoins =DEFILLAMA_STABLECOIN_MCAP() // Total market cap =DEFILLAMA_STABLECOIN_MCAP("USDC", "Ethereum") ``` ## Next Steps * [Function Reference](/spreadsheet-functions/function-reference) - Complete parameter documentation * [Templates](/spreadsheet-functions/templates) - Templates for common use cases * [Support](mailto:support@defillama.com) - In case of any issues, questions or feedback # Function Reference ## Available Metrics | Metric | Description | | ----------------- | ------------------------------------ | | `tvl` | Total Value Locked | | `borrows` | Total borrowed amounts | | `fees` | Protocol fees | | `revenue` | Protocol revenue | | `holders-revenue` | Revenue distributed to token holders | | `volume` | DEX trading volume | | `perps` | Perpetuals trading volume | | `mcap` | Market capitalization | | `stablecoins` | Stablecoin market cap | | `fdv` | Fully diluted valuation | | `ofdv` | Outstanding FDV | | `price` | Token price | ## Core Functions ### DEFILLAMA Get current metrics for any protocol or chain. ``` DEFILLAMA(metric, name, [timeframe]) ``` **Parameters:** * `metric`: See [Available Metrics](#available-metrics) * `name`: Protocol or chain name * `timeframe`: `24h` (default), `7d`, `30d`, `all` (optional) - used for metrics like fees/volume/revenue **Returns:** Numeric value **Examples:** ```excel =DEFILLAMA("tvl", "Ethereum") =DEFILLAMA("fees", "Uniswap-v2", "24h") =DEFILLAMA("volume", "GMX", "7d") ``` *** ### DEFILLAMA\_HISTORICAL Get historical data for any metric. ``` DEFILLAMA_HISTORICAL(metric, name, startDate, [endDate]) ``` **Parameters:** * `metric`: See [Available Metrics](#available-metrics) * `name`: Protocol or chain name * `startDate`: Date format `yyyy-mm-dd` or numeric date * `endDate`: Optional, returns array if provided **Returns:** Single numeric value or 2-column array (dates, values) **Examples:** ```excel =DEFILLAMA_HISTORICAL("tvl", "Ethereum", "2024-01-01") =DEFILLAMA_HISTORICAL("fees", "Uniswap", "2024-01-01", "2024-01-31") ``` *** ### DEFILLAMA\_INFO Get all available metrics for a protocol or chain. ``` DEFILLAMA_INFO(entity) ``` **Parameters:** * `entity`: Protocol or chain name **Returns:** 2-column array with metric names and values **Example:** ```excel =DEFILLAMA_INFO("Aave") ``` *** ## Utility Functions ### DEFILLAMA\_METRICS List all available metrics. ``` DEFILLAMA_METRICS() ``` ## **Returns:** 2-column array with metric names and descriptions ### DEFILLAMA\_CHAINS List all supported blockchains. ``` DEFILLAMA_CHAINS() ``` **Returns:** 3-column array with chain name, ticker symbol, and TVL *** ### DEFILLAMA\_PROTOCOLS List all tracked protocols. ``` DEFILLAMA_PROTOCOLS() ``` **Returns:** 5-column array with protocol name, category, symbol, TVL, and market cap ## Yield Functions ### DEFILLAMA\_YIELD Filter and find yield pools. ``` DEFILLAMA_YIELD([chain], [token], [sortBy], [limit]) ``` **Parameters (all optional):** * `chain`: Blockchain name (e.g., "Ethereum", "Arbitrum") * `token`: Token symbol (e.g., "USDC", "ETH") * `sortBy`: `apy` (default), `tvl`, `apyBase`, `apyReward` * `limit`: Max results (default: 50) **Returns:** Array with pool name, chain, project, TVL, APY, tokens **Examples:** ```excel =DEFILLAMA_YIELD() =DEFILLAMA_YIELD("Ethereum", "USDC") =DEFILLAMA_YIELD("", "ETH", "tvl", 10) ``` *** ### DEFILLAMA\_YIELD\_POOL Get detailed information for a specific pool. ``` DEFILLAMA_YIELD_POOL(poolId) ``` **Parameters:** * `poolId`: Unique pool identifier **Returns:** Array with pool details (name, chain, TVL, APY breakdown, tokens, risk metrics) **Example:** ```excel =DEFILLAMA_YIELD_POOL("747c1d2a-c668-4682-b9f9-296708a3dd90") ``` *** ### DEFILLAMA\_YIELD\_TOP\_POOLS Get top performing yield pools. ``` DEFILLAMA_YIELD_TOP_POOLS([limit]) ``` **Parameters:** * `limit`: Number of pools (default: 20) **Returns:** Array with top pools sorted by APY **Example:** ```excel =DEFILLAMA_YIELD_TOP_POOLS(50) ``` *** ### DEFILLAMA\_YIELD\_CHAINS List available chains for yield filtering. ``` DEFILLAMA_YIELD_CHAINS() ``` **Returns:** Array of chain names available in yield pools **Example:** ```excel =DEFILLAMA_YIELD_CHAINS() ``` *** ### DEFILLAMA\_YIELD\_PROJECTS List available projects for yield filtering. ``` DEFILLAMA_YIELD_PROJECTS() ``` **Returns:** Array of project names available in yield pools *** ## Stablecoin Functions ### DEFILLAMA\_STABLECOINS List all tracked stablecoins. ``` DEFILLAMA_STABLECOINS() ``` **Returns:** Array with stablecoin name, symbol, market cap, price, dominant chain *** ### DEFILLAMA\_STABLECOIN\_MCAP Get stablecoin market cap. ``` DEFILLAMA_STABLECOIN_MCAP([name], [chain]) ``` **Parameters (all optional):** * `name`: Stablecoin name or symbol (default: "all" for total) * `chain`: Blockchain filter (default: "all" for aggregate) **Returns:** Numeric value (market cap in USD) **Examples:** ```excel =DEFILLAMA_STABLECOIN_MCAP() =DEFILLAMA_STABLECOIN_MCAP("USDC") =DEFILLAMA_STABLECOIN_MCAP("USDT", "Ethereum") ``` *** ### DEFILLAMA\_STABLECOIN\_HISTORY Get historical stablecoin data. ``` DEFILLAMA_STABLECOIN_HISTORY(name, startDate, [endDate], [chain]) ``` **Parameters:** * `name`: Stablecoin name, symbol, or "all" * `startDate`: Date format `yyyy-mm-dd` or numeric date * `endDate`: Optional end date (returns array if provided) * `chain`: Optional blockchain filter (default: "all") **Returns:** Single value or 2-column array (dates, market caps) **Examples:** ```excel =DEFILLAMA_STABLECOIN_HISTORY("USDC", "2024-01-01") =DEFILLAMA_STABLECOIN_HISTORY("USDT", "2024-01-01", "2024-12-31") =DEFILLAMA_STABLECOIN_HISTORY("all", "2024-01-01", "2024-12-31", "Ethereum") ``` *** # Templates Helpful templates to get you started with your analysis. ### **Stablecoin Yield Finder** Compare stablecoin yields across lending protocols and chains in real-time. Find the best returns on USDC, USDT, and others with live APY data from 2,000 pools that automatically updates. * Google Sheets template: [Stablecoin Yield Finder](https://docs.google.com/spreadsheets/d/1hiWuCNAFnaT0EFSMIdZXEtNBPMC_sdg_4Jh-L1njBF0/edit?usp=sharing) * Excel template: {% file src="/files/0dIs6U4CBo5PELRAVigd" %} ### **Multi-Chain Yield Finder with Earnings Calculator** Track yields across DeFi protocols on Ethereum, Arbitrum, Base, Solana, and more. Input your capital to calculate projected earnings and compare opportunities across chains and protocols. * Google Sheets template: [Multi-Chain Yield Finder with Earnings Calculator](https://docs.google.com/spreadsheets/d/1fnZR_in2OM_E5CaLMsYDHRPIzb9QEAZkvx1yhsunD7s/edit?usp=sharing) * Excel template: {% file src="/files/1rNbp6AgJyfejPtV1ZmD" %} ### **Protocol Comparison Table** Analyze and compare key metrics across DeFi protocols side-by-side including TVL, fees, revenue, and valuation ratios. Perfect for fundamental analysis and identifying undervalued protocols with strong revenue generation. * Google Sheets template: [Protocol Comparison Table](https://docs.google.com/spreadsheets/d/1fnZR_in2OM_E5CaLMsYDHRPIzb9QEAZkvx1yhsunD7s/edit?usp=sharing) * Excel template: {% file src="/files/2r00iwa0YZ1f34JrKUDG" %} ### **Chain Comparison Table** Compare Layer 1 and Layer 2 blockchain performance metrics including TVL, fee generation, and capital efficiency ratios. Compare which chains are capturing the most value and where DeFi activity is growing fastest. * Google Sheets template: [Chain Comparison Table](https://docs.google.com/spreadsheets/d/1FSFTLqKnD1Xn2DSnId_O5IIxpBlo1ptL-vVvtPOpLzI/edit?usp=sharing) * Excel template: {% file src="/files/Ftpgdoq0tzR9zN9DJWUS" %} ### **Advanced Revenue Table** Track the top revenue-generating protocols with comprehensive financial metrics including weekly & monthly fees, revenue, holders revenue, and valuation multiples. Identify which protocols are generating sustainable revenue and spot opportunities through metrics like take rate and Total Revenue Shared. * Google Sheets template: [Advanced Revenue Table](https://docs.google.com/spreadsheets/d/1YkV7ZOqtJSZPc07hFTXGsxebMSeDYB2tnxyY9DiO0ME/edit?usp=sharing) * Excel template: {% file src="/files/Ftpgdoq0tzR9zN9DJWUS" %} # Data Definitions ### 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. ### 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. 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. ### 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. Revenue, in the way we define it here, is closer to Gross Income 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. ### 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. ### 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$. ### Staked Value of governance coins that are staked in the protocol's staking system. ### 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. ### Total Raised Sum of all money raised by the protocol, including VC funding rounds, public sales and ICOs. ### 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. ### Treasury Value of coins held in ownership by the protocol. By default this excludes coins created by the protocol itself. 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. ### 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. ### Volume Volume traded on the DEX, this metric is only applicable to protocols that are DEXs (in this case only Saber), and it's just the sum of value of all trades that went through the DEX on a given day. ### 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. ### 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. ### Contributors Number of unique github accounts that made at least one commit to a repository in the github organization of a given project. ### Developers Number of unique github accounts that made at least one commit on three distinct months to a repository in the github organization of a given project. ### 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. # Custom columns Craft Your Own Metrics On-the-Fly Transform your DeFiLlama experience with **Custom Columns**. Go beyond our standard metrics and define your own, turning the protocol table into a personalized analysis powerhouse. Calculate bespoke ratios, track hyper-specific growth rates, combine data points in novel ways, or set conditional flags to instantly spot protocols meeting your criteria – all directly within DeFiLlama. ### Adding Custom Columns You can access this feature on the main page, at the bottom of the column selection dropdown. After pressing "Add Custom Column" you'll be able to input name and formula for your custom columns ### Defining Your Columns * Formula: Input your custom expression here. This field supports a rich syntax leveraging available protocol data, mathematical operators, and curated functions (detailed below). Real-time feedback warns about unrecognized inputs, and a preview shows the calculated result. * Format: Select the desired display format for your calculated values (`Auto`, `Number`, `USD`, `Percent`, `Boolean (βœ…/❌)`). "Auto" intelligently handles most types, including rendering boolean results as checkmarks. ### Crafting Formulas The formula engine supports curated set of powerful operations, giving you flexibility in creating the metrics that you need **Available Data Fields** * `mcap`, `tvl` * `tvlPrevDay`, `tvlPrevWeek`, `tvlPrevMonth` * `change_1d`, `change_7d`, `change_1m` (TVL changes in decimal format, e.g., `0.05`) * `fees_24h`, `fees_7d`, `fees_30d`, `fees_1y`, `average_fees_1y`, `cumulativeFees` * `pf` (Market Cap / Annualized Fees), `ps` (Market Cap / Annualized Revenue) * `revenue_24h`, `revenue_7d`, `revenue_30d`, `revenue_1y`, `average_revenue_1y`, `cumulativeRevenue` * `volume_24h`, `volume_7d`, `volumeChange_7d`, `cumulativeVolume` * `category` (String, e.g., "DEX", "Lending") {% hint style="info" %} Not every field is available in all protocols, for example volume is only available to protocol with DEXs category, if a protocol lacks a field your formula depends on, the result will be skipped for that row {% endhint %} **Operators** Standard mathematical (`+`, `-`, `*`, `/`, `%`, `^`) and logical (`and`, `or`, `not`) operators are available, along with comparison operators (`==`, `!=`, `>`, `>=`, `<`, `<=`). Use parentheses `()` for grouping. The ternary operator (`condition ? value_if_true : value_if_false`) is supported for conditional expressions. **Built-in Functions** We provide a focused set of functions relevant for protocol analysis. Autocomplete (`Ζ’` prefix) suggests these as you type, and selecting one adds `()` automatically. * `abs(x)`: Absolute value of x. * `ceil(x)`: Smallest integer greater than or equal to x (rounds up). * `floor(x)`: Largest integer less than or equal to x (rounds down). * `round(x)`: Rounds x to the nearest integer. * `roundTo(x, n)`: Rounds x to n decimal places. **(Highly useful for ratios)** * `sqrt(x)`: Square root of x. * `min(a, b, ...)`: Minimum value from the provided arguments. * `max(a, b, ...)`: Maximum value from the provided arguments. * `if(condition, true_val, false_val)`: Returns `true_val` if `condition` is true, else `false_val`. (Ternary `? :` is often cleaner). * `not(x)`: Logical NOT (inverts a boolean value). **Conditional Expressions & Flags** Create formulas that evaluate to `true` or `false`. Ideal for flagging protocols meeting specific criteria. With the "Format" set to "Auto" or "Boolean (βœ…/❌)", these display as intuitive checkmarks. * Example: `change_7d > 0.1 and revenue_7d > 100000` (Is 7d TVL growth > 10% AND 7d revenue > $100k?) -> βœ… / ❌ * Example: `category == "Lending" and tvl > 50000000` (Is it a Lending protocol with TVL > $50M?) -> βœ… / ❌ **Formatting** * Use the **Format** dropdown to control the appearance of results (Number, USD, Percent, etc.). "Auto" is often sufficient and handles booleans correctly. ### Use-Case examples 1. High Growth Alert * Formula: `change_7d > 0.15 and fees_7d > (fees_30d / 30 * 7 * 1.2)` * This will show you protocols that have >15% gain in the last 7 days and recent 7d fees significantly above prior run rate. 2. Revenue per TVL * Formula: `revenue_30d / tvl` * Give you ratio of protocol revenue (for the last 30 days) compared to their TVL 3. Annualized Fee Yield * Formula: `fees_1y / tvl` * Measures how well protocol monetizes its TVL # DAT Methodology Every other data provider lists a single mNAV number per DAT, but we believe that this can lead to incorrect assumptions, so instead we provide 3 numbers that define a range. ### Why one mNAV number can mislead you Look at Greenlane Holdings on November 30th, 2025: | Stat | Value | | ---------------------------------------- | ----------------------- | | Total BERA holdings | \~54.23 million BERA | | Treasury value | \~54.34 million dollars | | Share price | \~3.38$ | | Outstanding Share Count | \~4.8 million shares | | mNAV (marketcap / crypto treasury value) | 0.33 | Looking at this mNAV number you would conclude β€œGreenlane trades at 0.33 times its crypto treasury. This looks extremely cheap.” However, the company has many active contracts (that filings indicate are effectively certain to dilute over time / that are very likely to result in future share issuance), and when you account for this future dilution, the total share count that will have a claim on the treasury will be \~35.4m shares, resulting in an mNAV of \~2.42. So you might buy thinking you're getting a heavy discount to the crypto treasury and you're protected when in reality you're buying at \~2.42x premium over the crypto treasury value, very expensive and exposing yourself to a \~60% loss. To help investors avoid falling into this pitfall, and to provide more accurate metrics on the market, we created 3 versions of mNAV, each using a different share count: * **Realized mNAV**: The ratio of marketcap to crypto treasury value where marketcap = share price Γ— currently issued shares. * **Realistic mNAV**: The ratio of marketcap to crypto treasury value, where marketcap uses the economically most probable share count multiplied by the share price. * **Maximum mNAV**: The ratio of marketcap to crypto treasury value, where the marketcap is based on the fixed-count contractual dilution ceiling times the share price. Covers the case of the maximum number of shares that could be minted based on the current active contracts. ### Definitions #### Realized mNAV The ratio of marketcap to crypto treasury value where the marketcap is calculated by multiplying the share price by factual, legal share count today. Includes all completed share events after the latest filing using the outstanding share count and including all new issuances, settled ATM sales, executed conversions, exercises, repurchases, cancellations, splits, and ADS ratio changes. It answers: > β€œHow is the market valuing the crypto treasury on the shares that exist right now?” #### Realistic mNAV The ratio of marketcap to crypto treasury value, where the marketcap uses the economically most probable share count multiplied by the share price. Builds on the fully diluted realized share count, also known as outstanding shares, and adds dilution that is unavoidable under GAAP, such as diluted EPS share count, prefunded warrants, triggered convertibles or earnouts and mandatory conversions. Uses basic instead of diluted if the company reports a net loss. It answers: > β€œWhat does valuation look like once unavoidable dilution is priced in?” #### Maximum mNAV The ratio of marketcap to crypto treasury value, where the marketcap is based on the fixed-count contractual dilution ceiling times the share price. Covers all fixed share contracts such as options, warrants, RSUs, PSUs, fixed convertibles, and fixed share earnouts. Excludes dollar-based programs such as ATMs, shelves and equity lines because these are not fixed share counts, are not guaranteed to be used and are highly price and path dependent. It answers: > β€œWhat does valuation look like under the full fixed share contractual scenario?” ### Why this three line system is better * It reveals dilution instead of hiding it inside one opaque denominator. * It shows the factual baseline, the economic central case and the fixed contract ceiling. * It maintains one clear numerator and one clear denominator. * It provides consistent comparability across issuers. * It prevents errors caused by stale share counts, ATM capacity, ADS ratio drift and vague β€œfully diluted” claims. *** ### Exact methodology and sourcing to replicate DefiLlama's mNAV The sections above explain the intuition and definitions behind the three mNAV lines. This section specifies the exact data inputs and calculations used so that DefiLlama’s DAT mNAV can be replicated. #### 1. mNAV formula and notation For each dilution bucket `B` (Realized, Realistic, Maximum): `mNAV_B = (FD shares_B Γ— Share price) Γ· Crypto Treasury Value` Where: * `FD shares_B` is the fully diluted share count for bucket `B`. * `Share price` is the last trade on the primary exchange. * `Crypto Treasury Value` is the total USD value of crypto tokens the company directly holds. Numerator: * `Marketcap_B = FD shares_B Γ— Share price` Denominator: * `Crypto Treasury Value` Interpretation: * `mNAV_B > 1` β†’ the company trades at a **premium** to its crypto treasury. * `mNAV_B < 1` β†’ the company trades at a **discount** to its crypto treasury. #### 2. Crypto Treasury Value **Crypto Treasury Value** is the total USD value of all crypto tokens the company directly holds on a given date. Treasury includes: * Tokens in company-controlled wallets. * Tokens held with custodians. * Wrapped assets representing the same economic exposure. * Staked assets, valued at principal token units (not including future rewards). * Stablecoins classified as treasury reserves. **Multi-token treasuries** If a company holds multiple tokens, each token is valued separately and then summed: `Crypto Treasury Value = (BTC units Γ— BTC price in USD) + (ETH units Γ— ETH price in USD) + (WLD units Γ— WLD price in USD) + …` **Not included:** * Customer assets. * Cash, bonds, equities, or other non-crypto assets. * Equity stakes in other publicly traded companies, including other DAT names. Examples: * BMNR holding ORBS stock is **not** counted. * BMNR holding WLD tokens directly **is** counted. **Token count sourcing** DefiLlama uses authoritative, up-to-date sources in the following priority order: 1. SEC filings. 2. Company IR pages. 3. Treasury dashboards. 4. Custodian disclosures. 5. Verified wallets. 6. Official press releases via PR Newswire, GlobeNewswire, Business Wire, Accesswire. **Handling vague language** When disclosures are not precise: * β€œAt least 10,000 BTC” β†’ recorded as **10,000 BTC**. * β€œAround $1m of ETH” β†’ converted into ETH units using DefiLlama pricing at the reference date. * β€œSubstantial amount” β†’ ignored unless a quantifiable range can be derived. If only USD values are disclosed, DefiLlama uses that USD figure directly as part of **Crypto Treasury Value**. **Token pricing** DefiLlama uses aggregated, volume-weighted exchange pricing that is consistent across all DefiLlama products. #### 3. Fully diluted share buckets (FD) For a given date, **Crypto Treasury Value** is the same across all buckets. The difference between the three mNAV lines comes from the **FD share count used in the numerator** through `Marketcap_B`. All buckets: * Adjust for stock splits. * Adjust for reverse splits. * Normalize ADS structures and ADS ratio changes. **FD realized (Shares Outstanding, used for Realized mNAV)** FD realized corresponds to the **currently existing shares** that have legal claim today. The FD realized share count is composed of: * Shares outstanding from the latest filing. * Plus **completed** corporate actions after that filing: * New issuances (including ATM settlements). * Executed conversions. * Option and warrant exercises. * Repurchases and cancellations. * Splits and reverse splits. * ADS ratio changes. This FD share count is used as the `FD shares` input when calculating the **Realized mNAV** line. **FD realistic (GAAP likely dilution, used for Realistic mNAV)** FD realistic incorporates dilution that is effectively unavoidable under GAAP, starting from FD realized. The FD realistic share count is composed of: * FD realized shares. * Diluted weighted average shares from GAAP EPS. * Prefunded warrants. * Earnouts or conversions that filings indicate are certain or already triggered. * For issuers with a **net loss**, diluted EPS share count is replaced by basic (GAAP rule). This FD share count is used as the `FD shares` input when calculating the **Realistic mNAV** line. **FD maximum (fixed share contractual dilution, used for Maximum mNAV)** FD maximum captures the full fixed-share contractual ceiling, starting from FD realistic. The FD maximum share count is composed of: * FD realistic. * All fixed-share instruments, whether in- or out-of-the-money: * Options. * Warrants. * RSUs. * PSUs. * Fixed convertibles. * Fixed-share earnouts. Explicitly **excludes**: * Dollar-denominated ATM capacity. * Shelf registration capacity. * Equity lines and similar dollar-based facilities. These are excluded because they: * Are not fixed share counts. * Are not guaranteed to be used. * Are highly price- and path-dependent. This FD share count is used as the `FD shares` input when calculating the **Maximum mNAV** line. #### 4. Equity prices Share prices are sourced from Yahoo Finance: * Last traded price. * On the primary listing exchange. * Matched as closely as possible to the treasury valuation date used for token pricing. #### 5. How mNAV is calculated For each bucket `B`: 1. **Compute Crypto Treasury Value.**\ Aggregate all directly held tokens at their USD prices. 2. **Compute `Marketcap_B`.**\ `Marketcap_B = FD shares_B Γ— Share price`. 3. **Compute `mNAV_B`.**\ `mNAV_B = Marketcap_B Γ· Crypto Treasury Value`. DefiLlama then publishes three lines: * `mNAV_realized` * `mNAV_realistic` * `mNAV_maximum` #### 6. Why mNAV may differ from other sources mNAV values shown on DefiLlama may differ from other dashboards or broker data because: * DefiLlama **excludes** equity stakes in other DATs from Crypto Treasury Value. * Token counts can vary across IR pages, filings, custodians and PRs; DefiLlama reconciles and prioritizes sources as described. * Vague PR language is interpreted **conservatively**. * Some platforms include ATM capacity in their β€œfully diluted” share counts; DefiLlama does **not**. * Some platforms do not normalize for ADS structures or historical splits. * Pricing sources and reference times can differ. * Disclosure dates can differ across data vendors. * The method of calculating β€œmNAV” or β€œNAV multiple” can vary by platform and by company. #### 7. Acronyms * **DAT**: Digital Asset Treasury * **Crypto Treasury Value**: USD value of directly held tokens * **FD**: Fully Diluted * **FD realized**: Completed events only (shares outstanding plus completed actions) * **FD realistic**: GAAP likely dilution (FD realized plus unavoidable GAAP dilution) * **FD maximum**: All fixed-count contractual dilution (FD realistic plus all fixed-share instruments) * **mNAV**: Market to Net Asset Value multiple * **ATM**: At The Market program * **OTM**: Out of the Money * **ITM**: In the Money * **EPS**: Earnings Per Share * **RSU**: Restricted Stock Unit * **PSU**: Performance Stock Unit * **ADS**: American Depositary Share # How to change Ethereum's RPC To change the RPC endpoint used for Ethereum follow these steps: 1. Enter your MetaMask and click on your RPC endpoint at the top of your MetaMask. By default it says β€œEthereum Mainnet.” 2. Click β€œAdd Network” 3. Add the RPC URL you want to use, with a chainID of `1` and currency of `ETH`. 4. Click β€œSave” ![](/files/zUt9ki4frGQKfpp3bJ5j) # Add a new RPC endpoint Send a Pull Request to adding any RPCs to the array of each chain. # Frequently Asked Questions Answers to the most Frequently Asked Questions #### What is DefiLlama? DefiLlama is the largest TVL aggregator for DeFi (Decentralized Finance). Our data is fully open-source and maintained by a team of passionate individuals and contributors from hundreds of protocols. Our focus is on accurate data and transparency. #### What is TVL? Total Value Locked, or TVL, is the sum of the value of crypto assets that have been deposited by users to a protocol for the purpose of earning rewards or interest. #### How does DefiLlama get TVL data? Each project that is listed has an adapter/code that returns its TVL. Preference is given to protocols that make on-chain calls to return the TVL and these make up the majority, but some adapters use subgraphs or APIs. The adapters are all open-source, so they are open for review to everyone. #### How is DefiLlama funded? Previously DefiLlama was funded by self-funding, donations and grants. Currently DefiLlama is mainly funded by kickbacks from aggregators used on LlamaSwap and subscriptions. #### At what frequency is data updated on DefiLlama? * TVL, Total Borrows, Treasury, Stablecoin Supply, CEX Assets and Oracle TVS update every hour * For DEX Volume, Fees, Revenues, Earnings and other metrics that aren't based on snapshots like TVL but instead on time ranges: Most protocols are updated hourly, but some protocols only update daily, with updates happening on 0:00 UTC * Yield data (APY, Borrow APY, Pool TVL...) is updated hourly * Bridge data is updated hourly #### Why are the numbers from the API different from the numbers on the webpage? The webpage feeds off the API, so data from API is updated first and then webpage updates afterwards. Because website pages are cached for performance, you might see different values between both sources, but the delay will be 1 hour at most. #### What is Pool2 TVL? Pool2 refers to a type of farm that requires users to take exposure to native tokens issued by the protocol. It is a sort of β€œsecondary pool” to incentivize farmers to continue holding on to the protocol's tokens, or to provide liquidity for these tokens, instead of selling them. #### What is Staking TVL? * In many cases, a DeFi protocol will have their core smart contracts with TVL that provides some service, such as a DEX or a lending market, and then separately they'll have a contract where users can stake the protocol's governance token to earn rewards (usually revenue distribution or token inflation). Staking TVL refers to the TVL in these staking contracts, which are independent from the main protocol function. * Examples are CRV locked into veCRV, AAVE locked into stkAAVE, locked CAKE for veCAKE on PancakeSwap... * Staking TVL is never used for staking in Chains (eg ETH PoS staking), it's only for DeFi protocols. * Why we don't include this staking into core TVL by default:\ \- To avoid penalizing protocols that don't have a token or a staking program.\ \- Because this staking is independent from the core protocol function and so a large staking TVL doesn't mean that protocol has traction, it muddies TVL as a proxy for traction.\ \- This staking is largely riskless because if the contracts got hacked the protocol can always cover the loss by minting more governance tokens, and the risk of protocol hack is already baked into the protocol's token. However, for other tokens deposited into the protocol, if the protocol is hacked they would be completely lost. So core TVL provides a signal that the market considers the protocol trustworthy, but staking TVL doesn't provide that signal. Also, staking contracts are independent and simpler than core protocol contracts. #### What are borrows? Borrows is a metric found in Lending platforms and refers to the amount of value that has been borrowed through the protocol. #### What is doublecount? Doublecount is a toggle found on the DefiLlama website that gives users the option to count or not count tokens such as receipt tokens or LP tokens received from providing liquidity to a protocol and which have since been deposited to another protocol. #### Why doesn't DefiLlama count ADA/SOL/ETH staked into TVL? * At DefiLlama we don't count chain staked assets for ANY chain. Users use us to track DeFi adoption, and adding Chain Staking would overshadow the TVL from their DeFi protocols, making chain TVL just a proxy of token marketcap, completely removing usage as a metric to track DeFi adoption. We track liquid staking protocols but these are not included by default into chain TVL. * Example: As of 2025-03-20, Cardano TVL is 330m$, while 15.84bn$ in ADA are staked. Thus if we included staked ADA into TVL, DeFi would make up only 2% of TVL, and due to the frequent 2-5% daily movements in the price of ADA, users wouldn't be able to tell anything about DeFi from that chart. DeFi adoption could double overnight but if ADA price drops -2.5% the chart would go down. #### How to list your protocol? Getting your protocol listed on DefiLlama is very easy and only requires that we have an adapter that returns your projects TVL. We have a guide available on how to write an adapter [here](https://docs.llama.fi/list-your-project/submit-a-project). #### What is Treasury TVL? Treasury TVL refers funds in the protocol's treasury, not including the platform's own governance token. #### Does DefiLlama have an api? Yes. Our API is an open API and it free to use. Citing DefiLlama as the source is much appreciated. Find the API docs [here](https://defillama.com/docs/api). #### How can I download DefiLlama data? DefiLlama data is available to download in CSV format. You can find a β€œdownload” .csv button on various areas of the website: protocol page, chains page, overview and the bottom of the side menu bar. The amount of data retrieved depends on where the button is used, using it on the protocol page retrieves data for the specific protocol, using it on the chains page retrieves info by chain, the others retrieve all TVL data on the website. #### Why don't we include assets in other custodian under a CEX's assets? * Our users use our CEX asset metrics in order to see how much the market trusts a CEX with their capital, which is used as a proxy for how safe a CEX is to leave their money in. Deposits in a different custodian are completely independent from this and don't provide that safety market signal. * If we included custodians it'd open the door for our metric to be abused, for example by hypothetical CEX with 100m and 2bn in custodian vaults, displaying their assets as 2.1bn would give the signal that 2.1bn trust them with their money, when actually the opposite is true and 95% of their users trust them so little to keep the custody safe that theyre paying extra to have the custody segregated. If that CEX got hacked or had some issue and 95m was withdrawn, our metrics would show a 4.5% outflow, giving the signal that outflow is minimal and there's no danger of a run on the bank, when 95% have been withdrawn and actually the CEX is on the late stages of a bank run. * TLDR: by including custodian assets we'd end up giving the opposite signals for our users, and our goal is to provide data that helps in their decisions, not the opposite. #### Why does DefiLlama rank protocols by premium volume instead of notional volume? There was a huge problem with washtrading options that had huge notional value but tiny premiums, which led to highly inflated notional volumes. That's why we switched to using premium volume because it reflected usage much better. # Overview These guidelines define how DeFiLlama classifies, measures, and displays tokenized real-world assets on the [RWA dashboard](https://defillama.com/rwa). They cover evidence flags, metric definitions, access models, RWA classification rules, column definitions, type taxonomy, category taxonomy, and asset class taxonomy. The goal is consistent asset classification so that users can understand how assets are categorized and measured, and compare assets using standardized metrics. The RWA section is split into two dashboards: * [**RWA Dashboard**](https://defillama.com/rwa) β€” tracks tokenized assets, stablecoins, funds, credit, wrappers, and governance tokens. * [**RWA Perps Dashboard**](https://defillama.com/rwa/perps) β€” tracks perpetual futures markets tied to real-world reference assets such as equities, commodities, bonds, and ETFs. ## Subpages * [Eligibility & Exclusion](/real-world-assets/real-world-assets/eligibility-and-exclusion) β€” inclusion criteria, exclusion criteria, and expulsion rules that determine whether an asset belongs in the RWA universe. * [Methodology & Metrics](/real-world-assets/real-world-assets/methodology-and-metrics) β€” evidence flags, metric definitions, access models, and RWA classification rules. * [Definitions & Taxonomy](/real-world-assets/real-world-assets/definitions-and-taxonomy) β€” column definitions, type taxonomy, category taxonomy, and asset class taxonomy. * [RWA Perps](/real-world-assets/real-world-assets/rwa-perps) β€” dashboard guide, column definitions, asset class taxonomy, and reference asset group taxonomy for the RWA Perps dashboard. * [RWA Token Submission Form](https://forms.defillama.com/rwa-submission) β€” required fields for submitting a new RWA token to the dashboard. # Eligibility & Exclusion This page explains how DeFiLlama decides whether an asset belongs in the RWA universe. The goal is simple: include assets that have a real link to something offchain, and exclude assets that do not. This page is about eligibility. It does not replace the [category taxonomy](/real-world-assets/real-world-assets/definitions-and-taxonomy), [access model](/real-world-assets/real-world-assets/methodology-and-metrics), or [evidence flags](/real-world-assets/real-world-assets/methodology-and-metrics). Instead, it sits above them and answers a basic question: should this asset be listed as part of the RWA universe at all? *** ## Why This Page Exists Not every RWA looks the same. Some tokens give a direct claim on an underlying asset. Others give economic exposure through a fund, trust, note, SPV, or other legal structure. Some are transferable and self-custodial. Others can only be held through a platform or approved wallet. That means an asset should not be excluded just because its structure is different. Instead, the focus should be on whether the asset has a real offchain basis, a clear explanation of how the token connects to it, and enough public information to support the listing. *** ## Scope The inclusion criteria below apply to entries that claim to represent real-world asset exposure. A small number of entries such as Non-RWA Stablecoins and Crypto Funds are tracked on the dashboard for context and comparison purposes even though they are not themselves RWA-backed. These entries are governed by their own category definitions rather than the inclusion criteria on this page. Similarly, entries typed as Platform or Wrapper are eligible provided they have a meaningful connection to the RWA ecosystem. A platform that facilitates issuance, custody, or trading of tokenized real-world assets belongs on the dashboard. A wrapper that repackages one or more assets that themselves meet the inclusion criteria is also eligible, provided the wrapper's structure and underlying holdings are publicly documented. A token with no meaningful RWA involvement should not be listed, regardless of how it is submitted. *** ## Inclusion Criteria An asset can be included in the RWA universe if all of the following are true. ### 1. It Points to a Real Offchain Asset or Exposure The token must represent one of the following: a real-world asset, a claim on a real-world asset, a fund or trust interest, a commodity holding, a property interest, a receivable or credit exposure, a security or private-market position, or another clearly explained offchain economic exposure. If there is no real offchain reference point, it does not belong in the RWA universe. ### 2. The Connection Is Explained Publicly There must be a clear public explanation of how the token connects to the offchain asset or exposure. Examples include custody of the underlying asset, reserve backing, SPV exposure, fund structure, note or certificate terms, a redemption process, a servicing structure, or a property or project structure. The exact structure can vary. What matters is that the connection is real and explained. ### 3. A Responsible Entity Can Be Identified There must be a party that can be identified as responsible for the product, such as an issuer, operator, manager, SPV, trust, fund, platform entity, or other accountable legal or operating party. This does not require perfect regulatory clarity. It does require that the product is not anonymous or impossible to attribute. ### 4. There Is Enough Public Evidence to Support the Listing At minimum, an includable asset should have an official product page or issuer page (or both), a live token or contract where applicable, a description of what the token represents, and enough supporting material to understand the structure. Supporting material can include legal terms, reserve pages, redemption terms, offering documents, custody disclosures, fund documents, prospectuses, proof-of-reserves pages, or other category-appropriate documentation. Different asset types will have different kinds of proof. A commodity token and a tokenized fund should not be expected to prove themselves in exactly the same way. Whether the available evidence is sufficient is assessed by the DeFiLlama RWA team on a case-by-case basis. ### 5. The Product Is Live The asset must be a live tokenized product or a live onchain exposure. Prelaunch pages, abandoned products, dead contracts, placeholders, and discontinued instruments should not be included as active RWA assets. *** ## Exclusion Criteria An asset should be excluded if any of the following are true. ### 1. No Real Offchain Asset or Exposure Can Be Identified If the token does not map to a real-world asset, claim, fund interest, commodity holding, property interest, security, receivable, or clearly explained offchain exposure, it should be excluded. ### 2. No Credible Linkage Mechanism Is Disclosed If there is no public explanation of how token value links to the offchain asset or exposure, the asset should be excluded. Claims such as "backed" or "linked" are not enough on their own. There must be enough information to understand what that means in practice. ### 3. No Responsible Entity Can Be Identified If no issuer, operator, SPV, trust, fund, manager, or platform entity can be identified, the asset should be excluded. ### 4. The Public Evidence Is Too Thin If there is no official product page, no issuer information, no legal terms, no product description, and no meaningful supporting documentation, the asset should be excluded. ### 5. The Product Is Materially Misleading If the public presentation materially misstates the nature of the asset β€” such as implying direct ownership when the product only provides indirect exposure β€” the asset should be excluded until the listing can be corrected. ### 6. The Product Is Not Live If the product is prelaunch, discontinued, inactive, abandoned, or represented only by a dead or obsolete contract, it should be excluded. *** ## What Does Not Automatically Exclude an Asset The following should not be treated as automatic reasons to exclude an asset: no direct shareholder rights, no voting rights, no dividend rights, SPV-backed structure, note-based or certificate-based structure, permissioned minting or redemption, allowlisting, lack of self-custody, lack of transferability, and lack of public attestation. These features may change how an asset is classified or displayed. They do not, by themselves, make the asset ineligible. *** ## Expulsion Criteria An asset may be removed after listing if new information shows that it no longer meets the standard for inclusion. An asset should be expelled if any of the following become true: the underlying exposure is shown to be false or unsupported, the responsible entity disappears or disclaims responsibility, the token no longer maps to the underlying asset or exposure, the product is terminated or becomes economically inactive, material deception becomes evident, or the listing becomes a dead, duplicate, or obsolete contract. Assets that materially change their structure, backing, or responsible entity may be reclassified or placed under review rather than expelled outright. Where the issue is temporary or still under review, the asset can be placed in a pending or review state instead of being removed immediately. Expelled assets are moved to an internal excluded list and are not deleted from the data. They can be reinstated if the conditions that led to expulsion are resolved. *** ## Summary The RWA universe aims to be broad enough to capture the real range of tokenized real-world assets, while still being strict about substance. That means an asset should not be excluded just because it uses a trust, SPV, note, platform account, or other non-standard structure. It does mean that assets lacking a real offchain basis, a clear linkage mechanism, an identifiable responsible entity, a live product, or enough public information to support the listing should be excluded. # Methodology & Metrics This page describes how DeFiLlama evaluates and measures the tokenized real-world assets tracked on the [RWA dashboard](https://defillama.com/rwa). It covers evidence flags, metric definitions, access model classification, and the RWA classification framework. *** ## Evidence Flags Each asset is tagged with seven factual signals. A value of **Yes** means the claim has been publicly verified. A value of **x** covers both negative answers and cases that have not yet been verified. | Flag | What it records | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Attestations | Public proof-of-reserves or asset-verification reports from the issuer. | | Redeemable | A documented redemption pathway allowing holders to redeem for underlying assets. | | CEX Listed | Availability on at least one centralized exchange. | | KYC for mint/redeem | Identity verification (KYC/KYB/onboarding) required to mint or redeem through the issuer. | | KYC/Allowlisted/Whitelisted to Transfer/Hold | Prior verification or allowlisting required to hold or transfer the token, enforced at the token, contract, or venue level. | | Transferable | The token can be transferred freely between onchain addresses. | | Self Custody | The token can be held in a user-controlled wallet. | *** ## Metrics ### Onchain Marketcap Total USD value of the asset that exists onchain across all tracked chains. Calculated by multiplying circulating supply (excluding burned tokens) by the reference price sourced via DeFiLlama. ### Active Marketcap The portion of Onchain Marketcap that is taking real market risk in user or protocol hands. Active Marketcap isolates independent market ownership by including self-custody holdings and third-party DeFi positions, while excluding issuer wallets, custody omnibus accounts, and internal operational flows. The economic test is whether compromise of a given wallet would enable meaningful value extraction by a third party. ### DeFi Active TVL The subset of Active Marketcap that is deployed in third-party DeFi protocols tracked by DeFiLlama. Issuer-managed contracts and exchange wallets are excluded. ### Utilization The ratio of DeFi Active TVL to Onchain Marketcap, expressed as a percentage. This shows how much of the total onchain supply is actively being used in DeFi protocols. *** ## Access Model The Access Model describes how users can hold and transfer the asset. Five categories are assigned based on a deterministic hierarchy that evaluates allowlist requirements first, then transferability and self-custody in sequence. | Access Model | Meaning | | ---------------- | ------------------------------------------------------------------------------------- | | Permissioned | Requires KYC/AML verification to hold or transfer the asset. | | Permissionless | Open to any wallet address without identity verification. | | Non-transferable | Holdable but locked to the original wallet; cannot be transferred to other addresses. | | Custodial Only | Must be held through an authorized custodian; no self-custody option. | | Unknown | Access requirements have not been disclosed. | *** ## RWA Classification Every entry receives one of five classification labels that describe its economic nature. These labels are derived from the evidence flags and structural properties of the asset. | Classification | Meaning | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | True RWA | Tokenized real-world asset that is transferable and self-custodial, with both documented redemption and reserve/asset verification. | | RWA | Tokenized real-world asset that is transferable and self-custodial, with either documented redemption or reserve/asset verification. | | Programmable Finance | RWA-linked onchain products such as wrappers, strategy/pool tokens, synthetics, or restricted fund tokens that are not transferable or self-custodial. | | Non-RWA (Platform) | Platform or infrastructure item related to RWAs, not an asset token or RWA exposure instrument. | | Non-RWA (Gov/Utility) | Governance or utility token that is not a tokenized real-world asset or RWA exposure instrument. | A two-tier badge system is used on the dashboard. Green badges are awarded to assets that meet both attestation and redemption requirements. Standard badges are shown for assets that meet either condition. *** ## Dashboard Guide The [RWA dashboard](https://defillama.com/rwa) is the primary interface for exploring tokenized real-world assets tracked by DeFiLlama. It is organized into the following sections. ### Top-Level Metrics Four summary cards are displayed at the top of the page: | Card | Description | | ---------------------- | ----------------------------------------------------------------- | | Total RWA Active Mcap | Aggregate Active Marketcap across all tracked RWA assets. | | Total RWA Onchain Mcap | Aggregate Onchain Marketcap across all tracked RWA assets. | | DeFi Active TVL | Total value of RWA assets deployed in third-party DeFi protocols. | | Total Asset Issuers | Count of distinct issuers across all tracked assets. | ### Navigation Tabs The dashboard has five tabs: **Overview**, **Chains**, **Platforms**, **Asset Groups**, and **Categories**. The Overview tab shows the full asset list across all views. Chains, Platforms, Asset Groups, and Categories provide filtered and aggregated views by each dimension. ### Chain Filters A row of chain pills below the tabs allows filtering all data by blockchain. Selecting a specific chain (e.g. Ethereum, Arbitrum, Base) restricts the metrics, chart, and table to assets deployed on that chain. ### Time Series Chart An interactive chart sits below the metrics cards and can display Active Mcap, Onchain Mcap, or DeFi Active TVL over time. The chart type can be toggled (e.g. Time Series Chart) and data can be grouped by Asset Group. The chart is exportable as CSV or PNG. ### Assets Rankings Table A searchable, sortable table lists every tracked asset. The default columns are: Name, Asset Group, Active Marketcap, Onchain Marketcap, DeFi Active TVL, Utilization, Category, Asset Class, Access Model, and Type. A column selector allows users to show or hide additional fields. The table can be exported as CSV. # Definitions & Taxonomy This page defines every column on the [RWA dashboard](https://defillama.com/rwa) and documents the full taxonomy used to classify assets by type, category, and asset class. *** ## Column Definitions ### Identifier Fields | Column | Definition | | ------- | ---------------------------------------------------------- | | Ticker | Canonical ticker symbol assigned to the asset or platform. | | Name | Human-readable name of the asset or platform. | | Website | Official website for the issuer, asset, or platform. | | Twitter | Official Twitter/X profile for the project or issuer. | ### Blockchain Fields | Column | Definition | | ------------- | ------------------------------------------------------------------------------------------------------------------------------ | | Primary Chain | Single chain slug representing the chain where the asset or platform is primarily issued or anchored. | | Chain | List of chain slugs separated by semicolons representing all chains where the asset exists or is deployed. | | Contracts | List of canonical onchain contracts formatted as `chainslug:address`. Use `x` when the asset has no single canonical contract. | ### Classification Fields | Column | Definition | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Category | High-level economic bucket describing the type of RWA or financial product represented. See the Category Taxonomy below. | | Asset Class | Granular economic type within a Category describing how the exposure is structured. See the Asset Class Taxonomy below. | | Type | Structural designation for the entry: Asset, Platform, or Wrapper. See the Type Taxonomy below. | | RWA Classification | High-level classification describing the economic nature of the entry. See [Methodology & Metrics](/real-world-assets/real-world-assets/methodology-and-metrics). | | Access Model | Indicates how users interact with the asset. See [Methodology & Metrics](/real-world-assets/real-world-assets/methodology-and-metrics). | ### Issuer & Verification Fields | Column | Definition | | -------------------- | ----------------------------------------------------------------------------------------------------- | | Issuer | Legal entity or organization responsible for issuing or controlling the asset. | | Issuer Source Link | Primary public reference confirming issuer information. | | Issuer Registry Info | Identifiers or registry data for the issuer from corporate or regulatory databases. | | ISIN | International Securities Identification Number, where applicable. | | Attestation Links | URLs to public proof-of-reserves or asset-verification reports. | | Attestations | Whether the issuer provides periodic attestations or assurance reports regarding reserves or backing. | ### Evidence Flags | Column | Definition | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Redeemable | Whether the token can be redeemed for underlying assets. | | CEX Listed | Whether the token is listed on a centralized exchange. | | KYC for mint/redeem | Whether minting or redeeming through the issuer requires KYC/AML verification. | | KYC/Allowlisted/Whitelisted to Transfer/Hold | Whether holding or transferring the token requires prior verification or allowlisting, enforced at the token, contract, or venue level. | | Transferable | Whether the token can be transferred freely between onchain addresses. | | Self Custody | Whether the token can be held in a user-controlled wallet. | ### Metric Fields | Column | Definition | | ----------------- | --------------------------------------------------------------------------------------- | | Onchain Marketcap | Total USD value of the asset that exists onchain across tracked chains. | | Active Marketcap | Portion of Onchain Marketcap taking real market risk in user or protocol hands. | | DeFi Active TVL | Subset of Active Marketcap deployed in third-party DeFi protocols tracked by DeFiLlama. | | Utilization | Ratio of DeFi Active TVL to Onchain Marketcap, expressed as a percentage. | ### Other Fields | Column | Definition | | ----------------- | ----------------------------------------------------------------------------- | | Parent Platform | The issuer or platform entry that this asset belongs to, when applicable. | | Description/Notes | Free-text field with structural details or modeling context. | | Yield Bearing | Whether the token passes through yield to holders. | | Oracle Provider | The oracle service providing price or reserve data for the asset. | | Oracle Proof Link | URL to the oracle feed or proof used for the asset. | | Claimed TVL | Issuer-reported AUM or TVL in USD. | | Derivatives | Notes describing derivative or wrapper instruments built on top of the asset. | *** ## Type Taxonomy Every entry is assigned one of three structural types. | Type | Definition | | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | Asset | Primary token representing real-world asset exposure being tracked, not the platform enabling issuance, and not a wrapper of another tracked asset. | | Platform | Protocol, issuer, or infrastructure entry that enables issuance, custody, trading, or management of RWAs, but is not the RWA exposure token itself. | | Wrapper | Token that wraps, pools, tranches, or strategies one or more underlying assets, creating RWA exposure via a derivative or structured product. | *** ## Category Taxonomy Each asset is assigned to one of the following high-level categories. Assets on the RWA Perps dashboard use the **RWA Perps** category; all other categories apply to the main RWA dashboard. | Category | Definition | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Bond & MMF Funds | Tokens representing shares in fund-like products invested in cash and fixed income, such as Treasury bills, bond funds, and money market funds. Holding the token is meant to mirror holding a slice of the underlying fund. | | Carbon & Environment | Tokens representing carbon credits and other standardized environmental units, such as verified emissions reductions, emissions allowances, and similar environmental certificates. | | Crypto Funds | Tokens representing shares in managed funds whose holdings are cryptoassets, such as index funds or crypto hedge funds. Fund-style exposure rather than direct ownership of a single coin or token. | | ETFs | Tokenized ETFs providing onchain exposure to exchange-traded fund shares, either fully backed by custodied shares or via synthetic replication. | | Fiat Stablecoins | Stablecoins designed to track a fiat currency such as USD or EUR. Typically issued and redeemed by an issuer and backed by off-chain reserves like cash, bank deposits, and short-term government bills. | | Gold & Commodities | Tokens tied to commodities, most often vaulted precious metals like gold. Typically backed by physical inventory or a clear issuer claim, and may be redeemable (directly or via approved partners) for the underlying commodity. | | Governance Tokens | Tokens used to govern an RWA-related protocol. They usually give voting rights and sometimes a share of fees, but are not a direct claim on a specific off-chain asset like a Treasury bill, loan, or commodity. | | Non-RWA Stablecoins | Stablecoins that aim to hold a peg using onchain mechanisms, such as crypto collateral, algorithms, or hedging, rather than cash and real-world assets held off-chain. | | Other RWAs | Tokens tied to less common real-world assets such as art, collectibles, royalties, or intellectual property, plus platforms that issue or enable trading of them. | | Private Credit | Protocols that finance real-world borrowing and receivables, for example private credit, trade finance, real estate credit, structured credit, or reinsurance-linked credit. Includes pools, originators, and markets that package or distribute credit onchain. | | Real Estate | Tokens giving exposure to real estate, either a single property or a pool. Structures include fractional ownership, revenue sharing, or real-estate-backed debt. | | RWA Perps | Perpetual markets tied to real-world reference assets such as public equities, ETFs, equity indices, bonds, and commodities. These markets provide margined, cash-settled price exposure rather than direct ownership or redemption rights in the underlying asset. Includes both individual perp markets and the venues that list them. | | RWA Stablecoins | Fiat-pegged stablecoins where the main backing is real-world assets, for example Treasury bills, bonds, credit, or commodities. Redemptions depend on those assets' value and liquidity, and some versions pass through yield. | | RWA Wrappers | Products that wrap RWA tokens (or RWA-backed stablecoins) into a simpler onchain position. They often issue a receipt token and may bundle assets, standardize yields, or split and repackage returns. | | Stocks & Equities | Tokens that provide exposure to stocks or equity baskets. Exposure may be backed 1:1 by shares held by a custodian, or track prices synthetically. This category also includes platforms that issue and trade them. | *** ## Asset Class Taxonomy Each asset is further classified into a granular asset class within its category. The tables below are organized by category. ### Fiat Stablecoins | Asset Class | Definition | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | | USD Stable | Stablecoins pegged to USD and backed mainly by cash, bank deposits, and short-term government paper held by a centralized issuer or custodian. | | EUR Stable | Stablecoins pegged to EUR and backed mainly by euro cash, bank deposits, and short-term government paper. | | Other Fiat Stable | Stablecoins pegged to non-USD, non-EUR fiat currencies such as GBP, CHF, SGD, or baskets of fiat. | | Bank Deposit Token | Tokens that represent a direct, redeemable claim on a bank or central bank deposit account at par value. | | Yield Fiat Stable | Fiat-pegged stablecoins that pass through some or all of the yield on reserve assets directly to token holders. | ### RWA Stablecoins | Asset Class | Definition | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | RWA Fiat Stable | Fiat-pegged stablecoins whose reserves are primarily real-world assets such as Treasury bills, bonds, or commodity holdings (e.g. gold), but where yield is retained by the issuer rather than paid directly to token holders. | | Yield RWA Stable | Fiat-pegged stablecoins whose reserves are real-world asset portfolios and where yield is paid directly to token holders via an increasing balance or rebase. | | Multi-Asset RWA Stable | Stablecoins backed by a mix of real-world assets and onchain collateral, where neither side is clearly dominant. | ### Non-RWA Stablecoins | Asset Class | Definition | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Crypto Stable | Stablecoins backed primarily by onchain crypto collateral (e.g. ETH, stETH, LP tokens) with no material allocation to real-world assets. | | Algo Stable | Stablecoins that rely mainly on algorithmic mechanisms or undercollateralized backing rather than fully reserved collateral. | | Synthetic Stable | Stablecoins backed by synthetic crypto or derivatives strategies (such as delta-neutral basis trades or perp hedging) rather than direct fiat or real-world asset reserves. | ### Bond & MMF Funds | Asset Class | Definition | | ------------------- | ----------------------------------------------------------------------------------------------------------------------- | | T-Bills | Tokens that give direct or near-direct exposure to short-term government Treasury bills or ETFs that hold them. | | Sovereign Bond Fund | Tokenized vehicles that hold government notes and bonds with longer duration than T-bills. | | Corp Bond Fund | Tokenized funds that hold corporate bonds, securitized credit, or similar corporate fixed-income instruments. | | MMF | Tokenized shares in a money market fund that holds short-duration, high-quality money market instruments. | | Mixed RWA Fund | Tokenized funds that hold a planned mix of sovereign debt, credit, and cash-like assets where no single type dominates. | ### Gold & Commodities | Asset Class | Definition | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Gold | Tokens backed by physical gold, whether allocated to specific bars or held in pooled, unallocated form by a custodian. | | Silver | Tokens backed primarily by physical silver held in secure custody. | | Platinum | Tokens backed primarily by physical platinum. | | Palladium | Tokens backed primarily by physical palladium. | | Uranium | Tokens backed primarily by uranium or uranium inventory. | | Other Commodity | Tokens backed by a single physical commodity that is not a precious metal or uranium, such as crude oil, natural gas, agricultural products, or metals outside the precious metals category. | | Commodity Basket | Tokens backed by a basket of commodities rather than a single underlying asset. | ### Real Estate | Asset Class | Definition | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------- | | Single Property | Tokens that give equity-style exposure to a single property or real estate project. | | REIT | Tokens that mirror units in a pooled real estate fund, REIT structure, or diversified basket/index of real estate exposures. | | RE Revenue Share | Tokens whose primary claim is to a share of rental income or other property revenue streams. | | RE Credit | Tokens backed primarily by loans, mortgages, or credit notes secured against real estate or property. | ### Stocks & Equities | Asset Class | Definition | | --------------- | -------------------------------------------------------------------------------------------------------- | | Stock Synthetic | Tokens that track a single listed equity using synthetic replication rather than full custody of shares. | | Stock Backed | Tokens backed by held underlying shares in custody that map 1:1 to a single listed equity. | | Equity Basket | Tokens that track a basket or index of equities or equity ETFs. | | PE / Venture | Tokens that represent interests in private company equity, venture capital funds, or similar vehicles. | ### Private Credit | Asset Class | Definition | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Credit Pool | Pools or funds backed by diversified private loans such as SME, corporate, or consumer credit, including managed private credit funds and feeder vehicles that allocate across lending strategies. | | Trade Finance | Pools backed by invoices, receivables, or other trade-finance assets. | | Structured Credit | Credit backed by niche or structured assets such as revenue-based finance, litigation finance, project finance, or asset-backed fleet financing. | | Other Credit | Private credit pools that are clearly real-world lending exposures but do not fit the more specific labels. | | Reinsurance Pool | Pools where the primary risk and return come from reinsurance or insurance underwriting exposure. | | Lending Venue | Protocols or markets that primarily facilitate issuance, trading, or lending against RWA collateral or private credit pools, rather than representing a single pool token. | ### RWA Wrappers | Asset Class | Definition | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Stable Yield Wrapper | Wrappers whose underlying is one or more stablecoins and that issue a yield-bearing receipt token. | | Single Asset Wrapper | Wrappers that mainly hold one underlying RWA token or fund and issue a single receipt token. | | RWA Basket Vault | Wrappers that hold a basket of RWA tokens or funds and present them as one composite position or index-like exposure. | | RWA LP Wrapper | Tokens that represent LP positions where the majority of exposure is to RWA tokens or RWA stablecoins. | | Leveraged RWA Vault | Wrappers that apply leverage or active rebalancing on top of RWA collateral to modify yield or duration. | | Structured Note | Tokens that embed structured payouts or note-like features on top of underlying RWA collateral. | | Yield Pool | Tokens that directly represent a yield-generating RWA pool that is not positioned as a stablecoin. | | Active Vault | Vault tokens representing deposits into a discretionary, manager-directed strategy that may allocate across RWAs and other onchain yield sources, and that issue a receipt token. | ### Carbon & Environment | Asset Class | Definition | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Carbon Credit | Tokens representing carbon credits, including project-based voluntary offsets and allowances from regulated cap-and-trade or compliance carbon markets. | | Carbon Reserve | Tokens that function as reserve or treasury assets and are backed by baskets of carbon credits or similar environmental units, rather than representing individual retireable offset claims. | | Other Environmental | Tokens linked to other environmental or impact units such as renewable energy certificates or biodiversity credits. | ### Governance Tokens | Asset Class | Definition | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Governance Token | Tokens that confer governance rights, voting power, or protocol control over an RWA platform or product suite, without being a direct 1:1 claim on the underlying assets. | | Revenue Share | Tokens that entitle holders to a share of protocol revenues or fees from an RWA platform while not being a direct claim on underlying asset pools. | ### Other RWAs | Asset Class | Definition | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | Collectibles | Tokens backed by art, collectibles, or other non-financial real assets such as luxury goods. | | IP / Royalty | Tokens whose primary claim is to intellectual property or revenue/royalties from IP such as music, patents, or media catalogs. | | Other Exotic | Tokens backed by niche real-world assets that do not fit other categories, such as AI hardware, fleet assets, or other specialized equipment. | | Domain Venue | Marketplaces/venues that fractionalize off-chain DNS domains into onchain tokens and facilitate primary issuance and secondary trading. | | Collectibles Venue | Platforms/marketplaces that enable tokenization, trading, custody/vaulting, and redemption of physical collectibles via onchain tokens/NFTs. | ### Crypto Funds | Asset Class | Definition | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Crypto Index Fund | Tokenized fund shares providing beneficial exposure to a diversified basket of cryptocurrencies via a disclosed index methodology or systematic allocation strategy. | | Crypto Hedge Fund | Tokenized fund shares providing beneficial exposure to an actively managed digital-asset fund pursuing absolute-return strategies across spot and/or derivatives markets. | ### ETFs ETFs on the main RWA dashboard use the asset classes **ETF Backed** (tokens fully backed by custodied ETF shares) or share asset classes with Stocks & Equities where applicable. ### RWA Perps Perpetual market asset classes are documented separately. See the [RWA Perps](/real-world-assets/real-world-assets/rwa-perps) page for the full perps asset class taxonomy, column definitions, and dashboard guide. | Asset Class | Definition | | -------------- | ----------------------------------------------------------------------------------- | | Stock Perp | Perpetual markets that track the price of an individual public company's equity. | | ETF Perp | Perpetual markets that track the price of an exchange-traded fund. | | Equity Perp | Perpetual markets that track a public-equity benchmark or basket. | | Commodity Perp | Perpetual markets that track a commodity or commodity benchmark. | | Bond Perp | Perpetual markets that track a bond or bond benchmark. | | Perp Venue | Venues that list and operate perpetual markets tied to real-world reference assets. | *** ## Asset Group Taxonomy Asset Groups are broader user-facing groupings used to pull related assets and markets into a single dashboard view. They appear in the Asset Group column on both the main RWA dashboard and the RWA Perps dashboard, and are used for chart grouping and the Asset Groups tab. | Asset Group | Definition | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Agricultural Commodities | Assets tied mainly to crops, farmland yield rights, livestock-related commodity flows, or other agricultural commodity exposure. | | AI & Compute Infrastructure | Assets tied mainly to physical AI and compute infrastructure, such as GPUs, data centers, robotics equipment, tokenized compute capacity, or financing backed by those assets. | | Bonds | Assets tied mainly to government or corporate debt instruments, money market funds, or similar fixed-income exposures where returns come mainly from interest and principal payments. | | Carbon Credits | Assets tied mainly to carbon credits, emissions allowances, or other standardized environmental units used to represent avoided, reduced, or removed emissions. | | Collectibles & Luxury Goods | Assets tied mainly to art, watches, wine, jewelry, rare cars, luxury goods, or similar collectible markets. | | Commodity Baskets | Assets spanning multiple commodity types without one clearly dominant commodity. | | Digital Assets | Assets tied mainly to cryptocurrencies, blockchain network activity, tokenized mining or hashrate, domain names, or investment funds whose reference assets are digital assets. | | Energy | Assets linked mainly to power generation, electricity, fuel infrastructure, or other energy-sector cash flows that are not best described as oil or natural gas alone. | | Equity ETFs | Assets whose primary reference is one or more exchange-traded funds that hold public equities. | | Equity Indices | Assets tracking broad or thematic equity indexes rather than a single company or a specific ETF. | | Fiat Currencies | Assets whose value is designed mainly to track a fiat currency or closely related cash unit, whether fully reserve-backed or maintained synthetically. | | Industrial Metals | Assets tied mainly to industrial metals such as copper, aluminum, nickel, or similar materials used in manufacturing and infrastructure. | | Intellectual Property & Royalties | Assets tied mainly to copyrights, music royalties, film rights, patents, trademarks, or other contractual cash flows from intellectual property. | | Mixed Public Markets | Assets spanning multiple public-market reference types, such as equities, ETFs, indices, bonds, or commodities, without one clearly dominant sleeve. | | Multi-Asset RWAs | Assets or platforms with meaningful exposure to multiple real-world asset sectors, such as bonds, credit, equities, real estate, or commodities, without one dominant reference asset. | | Natural Gas | Assets tied mainly to natural gas benchmarks or gas-linked commodity exposures. | | Oil | Assets tied mainly to crude oil benchmarks or related petroleum exposures. | | Precious Metals | Assets tied mainly to gold, silver, platinum, palladium, or similar precious-metals exposure. | | Private Credit | Assets tied mainly to privately originated loans, receivables, trade finance, structured credit, or similar non-public lending exposures. | | Private Equity & Venture | Assets tied mainly to ownership stakes in private companies, venture investments, or platform equity that behaves more like private-company exposure than public-market shares. | | Public Equities | Assets tied mainly to publicly listed companies or diversified baskets of listed shares. | | Real Estate | Assets linked mainly to property values, rental income, home equity, or portfolios of real estate assets. | | Reinsurance | Assets tied mainly to insurance-linked or reinsurance risk, where returns depend on underwriting performance, premium flows, and loss outcomes. | | RWA Infrastructure | Tokens or platforms tied mainly to the issuance, trading, settlement, compliance, or governance rails used to bring real-world assets onchain, rather than a single underlying asset class. | # RWA Perps The [RWA Perps dashboard](https://defillama.com/rwa/perps) tracks perpetual futures markets tied to real-world reference assets. Unlike the main RWA dashboard, which tracks tokenized assets with onchain supply and market capitalization, the perps dashboard tracks derivative markets that provide margined, cash-settled price exposure to assets such as public equities, commodities, bonds, ETFs, and equity indices. These markets do not confer ownership of, or redemption rights in, the underlying real-world asset. All entries on the RWA Perps dashboard belong to the **RWA Perps** category. *** ## Dashboard Guide ### Overview Tab The Overview tab is the default view and provides a market-level picture of all tracked RWA perpetual contracts. #### Top-Level Metrics Four summary cards appear at the top of the page: | Card | Description | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Total Open Interest | Aggregate USD notional of all outstanding perpetual contracts across all tracked venues. Shown with a 24-hour percentage change. | | Total 24h Volume | Aggregate USD notional volume traded across all tracked markets in the last 24 hours. Shown with a 24-hour percentage change. | | Total Markets | Count of individual perpetual markets being tracked. | | Est. Protocol Fees 24h | Estimated fees earned by all tracked protocols from trading activity in the last 24 hours. | #### Visualization Below the metrics cards is an interactive visualization that can be toggled between three views using the tabs: * **Open Interest** β€” a treemap or chart showing the distribution of open interest across markets, grouped by Asset Group or Base Asset. * **Volume** β€” the same visualization using 24-hour trading volume instead of open interest. * **Markets** β€” a count-based view showing how many markets exist per group. The visualization supports multiple chart types (Treemap Chart is the default), can be nested by Base Asset or Asset Group, and is exportable as CSV or PNG. Hovering over a segment shows the parent group, child asset, open interest or volume value, share of parent, and share of total. #### Markets Rankings Table A searchable, sortable table lists every tracked perpetual contract. The table has a configurable column selector and can be exported as CSV. Default columns are: | Column | Description | | ------------------- | ---------------------------------------------------------------------------------------------------------------- | | Contract | Ticker symbol of the perpetual futures contract as listed on the venue. | | Venue | Protocol or exchange where the perpetual contract is listed and traded. | | Base Asset | Underlying real-world asset the perpetual contract tracks (e.g. Crude Oil (WTI), Tesla, Gold). | | Asset Group | Broader grouping of the base asset used for dashboard aggregation (e.g. Oil, Public Equities, Precious Metals). | | Asset Class | High-level economic category of the underlying asset. See the Asset Class Taxonomy below. | | Open Interest | Total USD value of outstanding perpetual contracts that have not been settled or closed. | | 24h Volume | Total USD notional volume traded on this contract in the last 24 hours. | | Price | Latest traded price of the perpetual contract in USD. | | 24h Price Change | Percentage change in contract price over the last 24 hours. | | Latest Funding Rate | Most recent periodic funding rate paid between long and short position holders. Positive means longs pay shorts. | | Premium | Percentage difference between the perpetual contract price and the underlying asset's spot or index price. | | Max Leverage | Maximum leverage multiplier available for this contract on the venue. | Additional columns available via the column selector include: | Column | Description | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Category | Classification category for the market entry (all entries belong to RWA Perps). | | Parent Platform | Parent protocol or platform that operates the venue. | | Margin Asset | Margin currency used by the market (e.g. USDC, USDT). | | Settlement Asset | Cash-settlement currency for the contract (e.g. USDC, USDT, USDH). | | Issuer | Entity responsible for issuing or managing the underlying real-world asset. | | Oracle Provider | Oracle service used for price feeds on the contract. | | RWA Classification | Classification label assigned to the entry. See [Methodology & Metrics](/real-world-assets/real-world-assets/methodology-and-metrics). | | Access Model | Whether trading the contract requires KYC, permissioning, or is permissionlessly accessible. | | Maker Fee | Fee rate charged to the maker side of a trade on this contract. | | Taker Fee | Fee rate charged to the taker side of a trade on this contract. | | Deployer Fee Share | Percentage of protocol fees allocated to the deployer of the market. | | Cum. Funding / Unit | Cumulative funding payments per unit of the contract since inception. | | Oracle Px | Latest oracle price for the underlying asset. | | Mid Px | Mid-market price of the perpetual contract. | | Prev Day Px | Closing price of the contract from the previous day. | | Volume 7d | Total USD notional volume traded on this contract over the last 7 days. | | Volume 30d | Total USD notional volume traded on this contract over the last 30 days. | | Volume All Time | Total USD notional volume traded on this contract since inception. | | Est. Protocol Fees 24h | Estimated fees earned by the protocol from trading activity on this contract in the last 24 hours. | | Est. Protocol Fees 7d | Estimated fees earned by the protocol from this contract over the last 7 days. | | Est. Protocol Fees 30d | Estimated fees earned by the protocol from this contract over the last 30 days. | | Est. Protocol Fees All Time | Total estimated fees earned by the protocol from this contract since inception. | ### Venues Tab The Venues tab provides a venue-level view, aggregating market data across all contracts listed on each protocol or exchange. #### Venue Filters A row of venue pills allows filtering by specific venue. Selecting "All" shows aggregated data across all venues. #### Venue Chart An interactive stacked area chart shows historical open interest, volume, or market counts per venue over time. The chart can be filtered by Base Asset and is exportable as CSV or PNG. #### Venues Table A table below the chart lists each venue with the following columns: | Column | Description | | --------------------- | ---------------------------------------------------------------------- | | Venue | Name of the protocol or exchange. | | Open Interest | Total USD open interest across all markets on the venue. | | % of Total OI | Venue's share of total open interest across all tracked venues. | | 24h Volume | Total USD volume across all markets on the venue in the last 24 hours. | | % of Total 24h Volume | Venue's share of total 24-hour volume. | | Markets | Count of individual perpetual markets listed on the venue. | *** ## Column Definitions The tables below document every column on the RWA Perps dashboard. For columns shared with the main RWA dashboard (such as Access Model and Issuer), see [Definitions & Taxonomy](/real-world-assets/real-world-assets/definitions-and-taxonomy). ### Market Identification | Column | Definition | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Contract | Ticker symbol of the perpetual futures contract as listed on the venue. | | Venue | Protocol or exchange where the perpetual contract is listed and traded. | | Base Asset | Underlying real-world asset the perpetual contract tracks (e.g. Crude Oil (WTI), Tesla, Gold). | | Asset Group | Grouping of the base asset by product family, used for dashboard aggregation. | | Asset Class | High-level economic category of the underlying asset, such as commodities, equities, or fixed income. See the Asset Class Taxonomy below. | | Canonical Market ID | Venue-qualified market identifier used when the entry is a market rather than a token contract, such as `xyz:GOLD` or `cash:GOLD-USDT`. This is the canonical internal market slug, not the frontend trading pair. | | Pair | Displayed trading pair or quote convention for perpetual markets, such as GOLD-USDC or TSLA-USDT. Use `x` when the row is not a market or when no pair is applicable. | | Margin Asset | Margin currency used by the market, such as USDC or USDT. | | Settlement Asset | Cash-settlement currency for the contract, such as USDC, USDT, or USDH. This shows the settlement unit used by the market rather than the tracked underlying. | | Parent Platform | Parent protocol or platform that operates the venue. | | Oracle Provider | Oracle service used for price feeds on the contract. | | Reference Asset | Normalized exact asset, benchmark, ETF, company, or commodity tracked by the market. Used for exact cross-venue alignment and exact-asset dashboard pages. Examples: Gold, Silver, S\&P 500, Tesla, Crude Oil (WTI). | | Reference Asset Group | Broader user-facing grouping used to pull related markets into a single dashboard view across venues. Examples: Oil, Precious Metals, Public Equities, Equity Indices. See the Asset Group Taxonomy in [Definitions & Taxonomy](/real-world-assets/real-world-assets/definitions-and-taxonomy). | ### Market Metrics | Column | Definition | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Open Interest | Total USD value of outstanding perpetual contracts that have not been settled or closed. This replaces Onchain Marketcap as the primary sizing metric for perps. | | 24h Volume | Total USD notional volume traded on the contract in the last 24 hours. | | Price | Latest traded price of the perpetual contract in USD. | | 24h Price Change | Percentage change in contract price over the last 24 hours. | | Latest Funding Rate | Most recent periodic funding rate paid between long and short position holders. A positive rate means longs pay shorts; negative means shorts pay longs. | | Premium | Percentage difference between the perpetual contract price and the underlying asset's spot or index price. A positive premium means the perp trades above spot. | | Max Leverage | Maximum leverage multiplier available for the contract on the venue. | | Maker Fee | Fee rate charged to the maker side of a trade on this contract. | | Taker Fee | Fee rate charged to the taker side of a trade on this contract. | | Deployer Fee Share | Percentage of protocol fees allocated to the deployer of the market. | | Cum. Funding / Unit | Cumulative funding payments per unit of the contract since inception. | | Oracle Px | Latest oracle price for the underlying asset, as reported by the contract's oracle provider. | | Mid Px | Mid-market price of the perpetual contract, calculated as the midpoint between best bid and best ask. | | Prev Day Px | Closing price of the contract from the previous day. | | Volume 7d | Total USD notional volume traded on the contract over the last 7 days. | | Volume 30d | Total USD notional volume traded on the contract over the last 30 days. | | Volume All Time | Total USD notional volume traded on the contract since inception. | | Est. Protocol Fees 24h | Estimated fees earned by the protocol from trading activity on this contract in the last 24 hours. | | Est. Protocol Fees 7d | Estimated fees earned by the protocol from this contract over the last 7 days. | | Est. Protocol Fees 30d | Estimated fees earned by the protocol from this contract over the last 30 days. | | Est. Protocol Fees All Time | Total estimated fees earned by the protocol from this contract since inception. | *** ## Asset Class Taxonomy All entries on the RWA Perps dashboard fall under the **RWA Perps** category. Within that category, each market is assigned one of the following asset classes. | Asset Class | Definition | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Stock Perp | Perpetual markets that track the price of an individual public company's equity. They provide margined, cash-settled equity exposure and do not confer ownership of the underlying shares. | | ETF Perp | Perpetual markets that track the price of an exchange-traded fund. They provide margined, cash-settled fund exposure and do not represent ownership of fund shares or redemption rights. | | Equity Perp | Perpetual markets that track a public-equity benchmark or basket. They provide margined, cash-settled index exposure rather than a directly backed token or ownership claim on constituent shares. | | Commodity Perp | Perpetual markets that track a commodity or commodity benchmark, such as gold or crude oil. They provide margined, cash-settled commodity exposure and do not represent title to physical inventory. | | Bond Perp | Perpetual markets that track a bond or bond benchmark, such as government bonds, bond ETFs, or fixed-income indices. They provide margined, cash-settled fixed-income exposure and do not represent ownership of the underlying securities. | | Perp Venue | Venues that list and operate perpetual markets tied to real-world reference assets such as public equities, ETFs, equity indices, bonds, and commodities. | *** ## Key Differences from the Main RWA Dashboard The RWA Perps dashboard differs from the main RWA dashboard in several important ways: **Primary sizing metric.** The main dashboard uses Onchain Marketcap and Active Marketcap to measure asset size. The perps dashboard uses Open Interest (outstanding notional exposure) instead, since perpetual contracts do not have a circulating token supply in the traditional sense. **No redemption or attestation flags.** Perpetual contracts are cash-settled derivatives and do not represent direct claims on underlying assets. The evidence flags (Attestations, Redeemable) that are central to the main dashboard's classification framework do not apply to perps. **Venue-centric structure.** Each market on the perps dashboard is tied to a specific venue. The same underlying asset (e.g. Tesla) may have separate entries for each venue that lists a perpetual contract for it. The Venues tab provides aggregated venue-level metrics. **Funding rate and premium.** These metrics are unique to perpetual markets and reflect the cost of maintaining leveraged positions and the divergence between perp and spot prices. **Reference Asset and Reference Asset Group.** These fields enable cross-venue comparison by normalizing the underlying asset name across different venues that may use different contract tickers for the same exposure. The Reference Asset Group taxonomy is shared with the main RWA dashboard and is documented in [Definitions & Taxonomy](/real-world-assets/real-world-assets/definitions-and-taxonomy). # Pricing DefiLlama offers Pro and API subscriptions to enhance your DeFi analytics with premium features. Upgrade today to access advanced tools, custom dashboards, LlamaAI, excel/google sheets integrations an ### **Subscription Tiers** #### **Open** (Free) The Open plan provides essential access to DefiLlama's comprehensive DeFi data. **Features:** * Access to TVL (Total Value Locked), revenue/fees, and prices. * Access to **LlamaFeed** for real-time updates. * Support via Email and public Discord channel. *** #### **Pro** ($49/month or $490/year) **Free 7-day trial available** Unlock premium DefiLlama features designed for power users and researchers. **Features:** * **LlamaAI** – conversational analysis of DefiLlama data * Deep research: 5 questions/day (3 questions during trial) * **DefiLlama Pro Dashboards** – build custom dashboards * **CSV Downloads** – export any dataset (disabled during trial) * **Custom Columns** – personalized analysis * **LlamaFeed** – real-time premium insights * **DefiLlama Sheets** – access blockchain data in google sheets or excel * Access to upcoming DefiLlama products **Note:** API access is not included in the Pro plan. *** #### **API** ($300/month or $3,000/year) Designed for developers requiring additional API endpoints and higher limits. **Features:** * All features included in the Pro tier * Access to TVL, revenue/fees, and prices API endpoints * Access to all data categories (unlocks, active users, token liquidity, and more) * Priority support **API Limits:** * 1,000 requests per minute * 1 million API calls per month * $0.60 per 1,000 additional calls after the 1M limit **API docs page**: *** #### **Enterprise plan** **Features:** * All features included in Pro and API tiers * Direct raw access to our database * Custom bespoke solutions that fit your needs * Hourly data * Access to non-public data, such as TVL breakdowns by token address * Custom data licensing agreements To request an enterprise plan, please contact us at *** **Payment Options:** * Crypto * Credit card Both monthly and yearly billing options available. **How to Upgrade** Go to