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:
Liquidity Strength (LS) = 50% of score
Liquidity Ownership (LO) = 35% of score
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.
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.
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:
The industry is clearly undercapitalized - this is a primary driver why so many token charts are down and to the right.
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.
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.
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.
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?
where:
Constants configs.:
Variables description:
: The order each 'penalizable pool' gets assigned by applying the criteria defined below
: Tag that stands for 'untracked'
: Extractable Liquidity in pool
: Extractable liquidity in pools with tag
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.
Only valid pair pools are considered, and must be ordered by decreasing extractable liquidity value.
LC calculation:
Then:
LC calculation:
Then:
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?
for
for
where:
for
for
where:
Constants configs.:
For M. Caps. <= $250M:
For M. Caps. > $250M:
Variables description:
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.
: Total extractable liquidity of the project
: Total number of pools in the list
Lastly, assign each pool in the ordered list an value or a tag ( standing for ‘untracked’), starting with 1 for the first of the 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 tag, and should not be assigned an value, nor should these pools have any effect on the value assigned to the rest of the pools in the list.
Example 1: Project with no tag pools
Pool 1 -> $100,000 extr. liq. BANANA-WMATIC (‘valid pair’) ->
Pool 2 -> $85,000 extr. liq. BANANA-USDC (‘valid pair’) ->
Pool 3 -> $23.000 extr. liq. BANANA-BUSD (‘valid pair’) ->
Example 2: Project with tag pools
Pool 1 -> $300,000 extr. liq. BANANA-WBNB (‘valid pair’) -> tag
Pool 2 -> 250,000 extr. liq. BANANA-BUSD (‘valid pair’) -> tag
Pool 3 -> $100,000 extr. liq. BANANA-WMATIC (‘valid pair’) ->
Pool 4 -> $85,000 extr. liq. BANANA-USDC (‘valid pair’) ->
Pool 5 -> $23.000 extr. liq. BANANA-WBTC (‘valid pair’) ->
: Market cap. in usd
: Extractable liquidity to market cap. ratio
: Owned valid extractable liquidity in usd
: The ratio considered the minimum health standard for any given market cap.
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?
for
for
where:
Boundaries for plots ("sus" region):
Constants configs.:
For MCaps <= $250M:
For MCaps > $250M:
Variables description:
: Market cap. in usd
: Extractable liquidity to market cap. ratio
We look at the relationship between total valid extractable liquidity (from rented + owned) and the sustainability range upper bound.
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.