The distributeAssets
function in the LiquidationPool
smart contract is designed to distribute rewards among participants.
However, its current implementation results in an uneven distribution based on the order of assets in the tokenManager. This can lead to scenarios where either the users or the protocol disproportionately inherit bad debt exposure, particularly in volatile market conditions.
For example, if ETH (the first asset in a pool) appreciates in value while an exotic asset like LUNA (added later in the tokenManager) depreciates sharply, users may end up with a significant amount of appreciated ETH while the protocol is left holding devalued LUNA. (Example in the POC)
Conversely, if a pool contains IN ORDER a small amount of ETH, a larger quantities of LUNA and another stable asset like WBTC in large quantity, users might receive a majority of LUNA (now a bad asset) and minimal WBTC, leaving the protocol with the more stable WBTC, which will be consider unfair for the users.
To be able to run the test in this finding follow the following recommendation
Follow the following tutorial to install foundry in your local repo
https://hardhat.org/hardhat-runner/docs/advanced/hardhat-and-foundry
When hardhat-foundry
is installed, rename the current test folder to hardhat_test
so forge won't look at it.
Create/Update the foundry.toml fil with the current setup, to allow compilation with viaIR
Create a new test
folder, with the following file test contract in it, this contract deploy the whole contract stack.
The smartVaultManager is deployed with the proxy.
NFTMetadataGenerator is replaced by a Dummy address to lower the compilation time.
2 helpers are used in all the pocs:
_deployVault: Used to deploy the user Vault and retrieve the vault address
_send: Is used to send ETH
The provided Proof of Concept demonstrates a scenario where uneven asset distribution leads to the protocol acquiring 'bad' assets (devalued LUNA) and the user acquiring 'good' assets (appreciated ETH).
This situation arises when the price of LUNA crashes while the price of ETH rises significantly.
In this PoC, a user mints EUROs against a collateral mix of ETH and LUNA.
When the price of LUNA crashes, the liquidation process is triggered, but due to the order of asset distribution, Stackers ends up with only discounted ETH, while the protocol absorbs the loss by acquiring the devalued LUNA.
This uneven distribution mechanism can significantly impact both the protocol's financial health and the users' asset values.
It can lead to scenarios where the protocol or users are left with assets that have severely depreciated if the liquidation is trigger during the crash and users don't have time to liquidate the asset on time, while the others party endup in a safer position with an increasing asset.
Potentially leading to considerable financial losses and undermining trust in the protocol's fairness and risk management capabilities.
Manual Review
A critical refactor of the distributeAssets function is recommended.
The new implementation should ensure an equitable distribution of assets between the protocol and the user so risk could be shared between the protocol and the user.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.