Kima's Liquidity Management Algorithms (LIMA) is a set of algorithms running on the Kima blockchain, collecting data from Kima's pools, calculating the optimal liquidity positions of every pool, and based on that the related penalties and bounties.
LIMA calculates these parameters for every pool:
K1 - the lower bound of the optimal liquidity of the pool
K2 - the upper bound of the optimal liquidity of the pool
K3 - the maximum liquidity of the pool
As we will see, the LIMA rebalancing algorithms reduce financial risks for liquidity providers and maximize capital efficiency for users.
Let us establish that our user (Jane) wishes to send USDT from her address on Ethereum to her USDC address on Solana. By doing so, she is, in fact, requesting liquidity from the USDC pool on Solana. If the liquidity is below the pool optimal liquidity level, as calculated by LIMA (in the diagrams below, the range between K1-K2), Jane request to take liquidity (“Taker”) is charged a “taker penalty.”
This penalty grows as the requested amount reduces liquidity further below the optimal liquidity. As the liquidity level approaches zero, extracting an asset from this pool becomes significantly more expensive.
Similarly, if the liquidity is below the optimal level, a transaction that deposits USDC to the pool earns a bonus - a “maker bounty.” The bounty decreases as liquidity decreases and approaches the optimal liquidity.
The “taker penalty” is higher than the “maker bounty”, which means that the protocol collects (in advance) more than it needs to pay out in bounties for replenishment (or grooming) of the pools.
As long as the liquidity in the pool is optimal (between K1 and K2), the pool is in equilibrium and depositing into the pool earns no bounty, and withdrawing from the pool does not cost a penalty. In this case, Jane’s only cost to transfer assets is the Kima network fee (0.05%).
In summary, her total cost would be:
Fee = Taker Penalty | Bounty + Network fee - Maker Penalty | Bounty
Network fee = 0.05% of the transfer amount.
The diagram below describes a pool Maker and Taker Bounties and Penalties behavior:
Click the image to enlarge.
A taker withdrawing $a below K1 pays a penalty that increases as liquidity approaches zero
A taker withdrawing $b above K1 and below K2 pays no penalty (just the network fee)
A taker withdrawing $c above K2 receives a bounty that grows as liquidity is further above K2
A maker depositing $a below K1 receives a bounty that grows as liquidity approaches zero
A maker depositing $b above K1 and below K2 receives no bounty
A maker depositing $c above K2 pays a penalty that grows as liquidity is further above K2
As can be seen, transactions taking place between K1 and K2 do not incur penalties. However, as soon as liquidity goes out of this range (meaning someone paid the penalty), there is an incentive for someone else to bring the liquidity back to the K1-K2 range and collect a bounty.
K2 is much larger than K1, allowing for large transfers to pass, paying only the network fee and no penalties. As a result, in rare scenarios a transaction can be charged a deposit penalty. K2 serves as an upper limit for liquidity to ensure a pool’s balance does not grow too much (and out of alignment with the market). It is also a failsafe mechanism to ensure the Kima platform is protected against extreme dumping scenarios. Specifically, when the assets in the pool are stablecoins (e.g., USDT, USDC, or DAI), this protects the system against players who seek to dump off-pegged stablecoins in one pool and extract pegged stablecoins from another pool. This event's overall risk and cost has an upper limit K3. Specifically, at some point above K2, depositing into the pool will incur a penalty that equals the value of the deposited assets, making the transaction uneconomic for the depositor.
The penalty and bounty curves adapt dynamically to the activity in the pool. As activity in the pool increases or decreases, the actual values K1, K2, and K3 change accordingly.
Higher activity means more transfer volume which will increase K1, K2 and K3 proportionally. A decrease in activity will contract the curve, decreasing K1, K2, and K3