Liquidity Health Score Formula

$S = x * LS+y*LC+z*LO$

Each of the three components has a weighted coefficient (x, y, and z) to factor in the importance of each feature in the overall score. Currently:

1. Liquidity Strength (LS) = 50% of score

2. Liquidity Ownership (LO) = 35% of score

3. Liquidity Concentration (LC) = 15% of score

These three category scores are then weighted through ApeBond’s custom-built formula above to generate an aggregate Liquidity Health Score on a scale of 0-100. The Liquidity Health Score is the primary metric that will be shown when sharing information from the Liquidity Health Dashboard.

Sustainability Range

The Sustainability Range defines what ApeBond believes is an appropriate amount of liquidity for any given MCAP. This is a range, with an upper and lower bound, we believe if you are inside the range you are in a healthy spot.

This is the backbone of the liquidity health dashboard and the LS and LO scores are derived off this range.

Methodology

ApeBond gathered liquidity data on over 1500 active projects on EVM compatible chains and plotted them on a chart, looking at extractable liquidity and market capitalization.

Through various exploratory analyses on the industry's data, ApeBond created a deep understanding of what tendencies to look for. Using those tendencies, ApeBond modeled a custom function to describe the average behavior and optimized its parameters to fit the industry's current situation.

ApeBond then analyzed that data based on the experience of running a DEX for over two years, knowledge of how consistently crypto projects fail, and working closely with liquidity. It discovered that the industry average is very low, the entire industry does not put enough emphasis on liquidity.

ApeBond then optimized the equation parameters to define the lower bound of the "sustainability range". This included breaking the parameters up for projects below $250M and above, resulting in two formulas that integrated a number of important insights:

1. The industry is clearly undercapitalized - this is a primary driver why so many token charts are down and to the right.

2. When a project prints tokens, it must back those tokens with capital. Projects tend to launch tokens, put millions of dollars worth of the token into circulation, then put less than $250k backing the token. That degree of leverage is typically impossible to sustain.

3. Newer projects need more liquidity backing their token. With a smaller MCAP, there is more risk, as the project is less established, and needs a better trading environment to start.

4. All tokens need liquidity backing the token. If a project has no liquidity backing the token, then the token is worthless. If one cannot sell it for a hard asset, it is effectively worthless.

ApeBond then further pressure tested this model with slippage and price impact analysis on how much liquidity a project needs to be able to facilitate reasonable trade sizes with a slippage tolerance of roughly 5% and a price impact tolerance of 10%. This validated the model even further.

Summary

ApeBond used the industry average as the backbone of the sustainability range, defining an industry formula with tunable parameters. It then used the constant product formula, slippage and trade size analysis, and logical arguments from working with over 250 projects to dial in a final sustainability range.

Liquidity Concentration (LC) measures the degree to which the liquidity for a project’s token is concentrated to a certain number of liquidity pools. This metric is simple - the fewer pools you have scattered across the blockchain, the more concentrated your liquidity is and the more accessible that liquidity will be with lower slippage and price impact when trading.

Simply put, LC looks to answer the following question: Is this project’s liquidity too spread out?

Liquidity Concentration Formula

$LC = \frac{tel}{\sum_{n=1}^{N} ((1+P(n))*eln)+\sum elu}$

where:

$P(n) = (n-1)*\frac{a}{n^k}$

Constants configs.:

$a = 1$

$k = 0$

Variables description:

$n$: The order each 'penalizable pool' gets assigned by applying the criteria defined below

$u$: Tag that stands for 'untracked'

$eln$: Extractable Liquidity in pool $n$

$elu$: Extractable liquidity in pools with $u$ tag

$tel$: Total extractable liquidity of the project

$N$: Total number of pools in the $n$ list

Scoring

We look at the overall concentration of pools, and see if the project is spreading their capital too thin.

If any pool has more than $250k of Extractable liquidity then it is automatically not penalized. That is driven by the fact that a pool of that size is material enough to actually benefit your token and provide a decent trading experience for users.

Additionally the first pool below $250k of EL is also not penalized. Depending on a project's goals, it is reasonable to be working on building up an additional liquidity pool.

If there are invalid pairs they are thrown out as that liquidity is likely useless.

The weight of the penalty depends on the number of additional liquidity pools you have below $250k EL and their proportional weight to the overall extractable liquidity the project has.

To put simply, if you have one liquidity pool you automatically get a score of 100. If you have multiple pools all above $250k you also get a score of 100, or if you have a single pool after those multiple pools that is below $250k.

When you start to have multiple pools below $250k you begin to get penalized based on how large those pools are compared to the sum total liquidity you have.

Notes

• Only valid pair pools are considered, and must be ordered by decreasing extractable liquidity value.

• Lastly, assign each pool in the ordered list an $n$ value or a $u$ tag ($u$ standing for ‘untracked’), starting with 1 for the first of the $n$ kind, and increasing by 1 for each subsequent pool of the same kind. Pools with extractable liquidity greater or equal than $250,000 should be assigned a $u$ tag, and should not be assigned an $n$ value, nor should these pools have any effect on the $n$ value assigned to the rest of the pools in the list.

Example 1: Project with no $u$ tag pools

LC calculation:

Pool 1 -> $100,000 extr. liq. BANANA-WMATIC (‘valid pair’) -> $n=1$

Pool 2 -> $85,000 extr. liq. BANANA-USDC (‘valid pair’) -> $n=2$

Pool 3 -> $23.000 extr. liq. BANANA-BUSD (‘valid pair’) -> $n=3$

Then:

$LC = \frac{100,000+85,000+23,000}{(1+(1-1))*100,000+(1+(2-1))*85,000+(1+(3-1))*23,000}$

Example 2: Project with $u$ tag pools

LC calculation:

Pool 1 -> $300,000 extr. liq. BANANA-WBNB (‘valid pair’) -> $u$ tag

Pool 2 -> 250,000 extr. liq. BANANA-BUSD (‘valid pair’) -> $u$ tag

Pool 3 -> $100,000 extr. liq. BANANA-WMATIC (‘valid pair’) -> $n=1$

Pool 4 -> $85,000 extr. liq. BANANA-USDC (‘valid pair’) -> $n=2$

Pool 5 -> $23.000 extr. liq. BANANA-WBTC (‘valid pair’) -> $n=3$

Then:

$LC = \frac{300,000+250,000+100,000+85,000+23,000}{300,000+250,000+(1+(1-1))*100,000+(1+(2-1))*85,000+(1+(3-1))*23,000}$

Liquidity Ownership (LO) measures the ratio between the amount of token liquidity that a project owns compared to the amount of liquidity a project should own. This metric is designed to look at a project’s “liquidity debt”: the difference between a project’s owned, extractable liquidity and a baseline level of sustainable liquidity.

Simply put, LO looks to answer the following question: Does this project own ample liquidity to back the token based on its MCAP?

Liquidity Ownership Formula

$LO = (\frac{ovel/X}{susline})^{po}$ for $ovel/X< SL(X)$

$LO=1$ for $ovel/X >= SL(X)$

where:

$susline = SL(X)$ for $SL(X) < 1$

$susline = 1$ for $SL(X) >= 1$

where:

$SL(X)= (0.7/t1)^{1/α}*(\frac{e^{X/s} - e^{-X/s}}{e^{X/s} + e^{-X/s}})^{-β/α}$

Constants configs.:

$po = 0.5$

For M. Caps. <= $250M:

$t1=14.4$

$s=1,062,000,000$

$β=0.31$

$α=0.69$

For M. Caps. > $250M:

$t1=18.4$

$s=3,000,000,000$

$β=0.37$

$α=0.63$

Variables description:

$X$: Market cap. in usd

$Y$: Extractable liquidity to market cap. ratio

$ovel$: Owned valid extractable liquidity in usd

$susline$: The $ovel / X$ ratio considered the minimum health standard for any given market cap.

Scoring

We directly compare owned extractable liquidity vs the sustainability range lower bound.

The difference between this and LS is what sustainability range bound we compare to (upper for LS vs lower for LO) & whether or not rented liquidity is factored in (rented + owned for LS vs owned for LO).

The more owned liquidity you have, the better score you receive. If you have no Protocol Owned Liquidity you would receive a 0 score. If owned liquidity is equal to or greater than the sustainability range lower bound, then you score a perfect 100. That would signify the project owns the minimum amount of liquidity that we have determined is sustainable. Anything in between scores from 0 to 100.

One thing to note - projects get rewarded with more points towards their score early on. Think of it as a simple sqrt(x) graph, where your score goes up faster at the beginning and slower towards the end. For example, right now if a project owns 25% of the liquidity we deem they should, we are giving them a score of 50/100. This is purposeful to drive the importance of POL.

Please review the glossary of terms and tags used in the Liquidity Health Dashboard below.

Terms

• Hard Assets: The tokens one would consider as the exit liquidity for all other tokens, generally "blue chip", high market cap tokens and stablecoins

  • Hard asset list as of 7/5/2023: USDC, USDT, BUSD, DAI, FRAX, WBTC, ETH, BNB, MATIC, WCRO, FTM, SOL, AVAX

• Valid Pair: Any altcoin that is paired with a hard asset

• Non-Valid Pair: All altcoin-altcoin pairs (any token paired with a non-hard asset)

• Total Liquidity: The sum of ALL liquidity pools the token has (includes liquidity classified as ‘not valid’)

• Total Valid Liquidity: The sum of only the valid liquidity pools

• Total Extractable Liquidity: The sum of the hard assets liquidity in all of the valid pairs

• Circulating Supply (CS): Tokens that are in circulation, pulled from CoinGecko

• Market Capitalization (MCAP): The circulating supply multiplied by the spot price of the token, pulled from CoinGecko

• Extractable Liquidity / MCAP ratio (EL/MCAP): Provides a ratio on the current extractable liquidity compared to the project's MCAP, used as a benchmark how much extractable liquidity a project should have based on its MCAP, expressed as a percentage

• Sustainability Range: The acceptable range of Extractable Liquidity any project should have based on our methodology here.

  • Sustainability Range Upper Bound: The top of the sustainability range

  • Sustainability Range Lower Bound: The bottom of the sustainability range

• Owned Liquidity: Liquidity that is held and owned by a protocol in a known protocol address, or ideally locked behind a vesting contract / in a gnosis safe, also known as protocol-owned liquidity (POL)

  • Owned Liquidity has 2 types:

    1. Known Liquidity - Ownership addresses the ApeBond has manually verified and curated (or a 3rd party has submitted a PR)

    2. Suspected Liquidity - Ownership addresses that ApeBond found through automated mechanics (such as searching block explorers and confirming the address is a multisig or locking contract) by checking the bytecode of the contract.

• Rented Liquidity: Liquidity that is crowdsourced through yield farming or liquidity mining

• Unlocked Supply: Tokens that are unlocked on-chain

Tags

ApeBond aims to become a thought leader in standardizing best practices for liquidity health, tokenomics, and treasury diversification, while breaking down the complexities for easy public consumption and creating the first ever industry-wide credentialing system. The tools that ApeBond has worked to create have been built around three core values: objectivity, uniformity, and ease of use; starting with a laser focus on liquidity as a key concept for users and projects to understand, and expanding from there.

In pursuit of those values, ApeBond has created new opportunities for users and projects to evaluate crypto assets for themselves through the Liquidity Health Dashboard.

How the Liquidity Health Dashboard Works

The Liquidity Health Dashboard (or "LHD") synthesizes liquidity data from over 1500 crypto projects around the world to provide a metric by which users can assess the status of a project's liquidity: their Liquidity Health Score. The Liquidity Health Score is designed to be consistent (in that it can be used to compare projects of all shapes and sizes), objective (in that it is not inherently biased towards or away from any particular characteristics of a crypto project), and accurate (in that the data used to create it is pulled directly from the blockchain or reputable, up-to-date sources).

The formula that dictates the Liquidity Health Score consists of three primary factors: Liquidity Strength, Liquidity Ownership, and Liquidity Concentration. Each score is measured on a scale of 0-100, with 0 representing the weakest score and 100 representing the strongest.

Finally, we take a weighted average of the three individual scores to provide an overall score for the token: their Liquidity Health Score.

For a detailed breakdown of how the Liquidity Health Score is calculated, visit the Methodology page:

For a comprehensive list of the terms used in relation to the LHD, visit the LHD Glossary & Tags page:

How to Use the Liquidity Health Dashboard

If you are new to the concept of liquidity and liquidity health, the Liquidity Health Dashboard is a great place to start, because it provides at-a-glance, digestible information about whether a particular project is maintaining the quantity and quality of liquidity that it needs for its token in order to survive in the intermediate and long term. It is important to understand that the Liquidity Health Dashboard is not designed to tell you what tokens to buy. As always, ApeBond does not and will never provide financial advice! Instead, It gives users and projects a way to evaluate long term project and token health, and is most useful when combined with other independent research about a project.

With that said, scores from the Liquidity Health Dashboard can help guide your research in the right direction - think of them as risk ratings, where a lower score means the token is likely more risky to hold, and a higher score means the project is likely more stable and sustainable.

With the Liquidity Health Dashboard, users are now able to access and act on liquidity information about crypto projects that have been hiding in plain sight on the blockchain. The LHD will allow users to more fully understand whether their favorite project has been making liquidity decisions for their token that align with the best long-term interests of the project’s users and token holders as well as the tokenomics data they share on their site or documentation.

There are two main views to interact with when using the LHD: the List View, and the Project View.

List View

The List View shows 50 projects per page, with a summary of the following information:

• Market Cap: The current market capitalization of the token.

• 24h Change: The percentage change in the market capitalization of the token over the last 24 hours.

• Extractable: The total extractable liquidity for the token - the sum of the hard assets liquidity in all of the valid liquidity pairs for the token.

• Strength: The ratio of the available liquidity of a token to its current market capitalization.

• Ownership: The ratio between the amount of token liquidity that a project owns to the amount of liquidity that the project should own.

• Concentration: A metric that illustrates how well a project establishes deep liquidity in the pools it makes available for the token.

Project View

When you click on a specific project in the List View, you'll see a detailed breakdown for that project's liquidity in the Project View. Within the Project View, you can see the following information:

Token Info (1): Includes token price, price change over the last 24 hours, chains, market cap, and social links for the project.

Liquidity Health Score (2): Shows the project’s liquidity subscores for each category as well as the overall score, along with a Share feature (3) that allows users to share live LHD data about this project to Twitter.

Liquidity Strength Summary (4): Provides detailed liquidity information for the selected project’s token.

Token Liquidity Strength (5): Shows the token’s relative liquidity strength in terms of the Extractable Liquidity to Market Cap ratio. Users can zoom for more refined info and can hover over token logos for additional details.

Liquidity Concentration (6): Shows a list of the status of all liquidity pools/chains, the extractable liquidity held within those pools, and the block explorer links to each pool.

Liquidity Ownership (7): Shows the relative share of owned vs. non-owned liquidity for the project, along with a list of whitelisted addresses (8) for protocol-owned liquidity.

Liquidity Strength (LS) measures the ratio between the available liquidity of a token compared to its market capitalization. This is calculated by dividing a project’s total valid extractable liquidity (the sum of the hard assets in all valid liquidity pairs across all pools) by the project’s market capitalization (the circulating supply of the token multiplied by the spot price of the token). This metric is designed to look at if a project is maintaining enough liquidity compared to how large the market for the project’s token is. In other words: is there enough capital backing the token you are holding, or are you holding an empty bag that you cannot actually liquidate because the token is illiquid?

Simply put, LS looks to answer the following question: Does this project have enough liquidity based on its MCAP?

Liquidity Strength Formula

for

for

where:

Boundaries for plots ("sus" region):

Constants configs.:

For MCaps <= $250M:

For MCaps > $250M:

Variables description:

Scoring

Anything below the range entirely is considered unsustainable liquidity. Those projects score between 0 and 70. If you are on the lower bound of the sustainability range you would have a score of 70. As you move higher into the range, you can reach a score of 100. Anything above the range is also defined as 100 for now.

In a later version of the LHD credentialing system we will start to look at what is ‘too much’ liquidity that it is capital inefficient. But for now we are focusing on what's the minimum amount of liquidity a project needs as most of the industry is undercapitalized from a liquidity perspective.

Updating Project Information

If you own or work for a crypto project whose token liquidity is reflected in the Liquidity Health Dashboard, and you notice that it shows out of date information, you can use the Submit Data Update feature found at the top left of the LHD List View page or the bottom of your Project View page to submit a GitHub pull request with accurate, updated information.