You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelMediumA Medium severity issue.RewardA payout will be made for this issue
When providing liquidity to the AMM during new DS issuance, when depositing to the vault, or with fees, the protocol checks the current price ratio of RA:CT in order to calculate how much RA and CT are needed to be sent to the pair. Current implementation account for the case where the pool might be empty and calculating the ratio based on the reserves in it wont work. This provides an opportunity for attackers to manipulate the price ratio before the first provision of liquidity.
Vulnerability Detail
____getAmmCtPriceRatio() is used to get the current RA:CT price ration in the AMM.
function __getAmmCtPriceRatio(State storageself, IDsFlashSwapCore flashSwapRouter, uint256dsId)
internalviewreturns (uint256ratio)
{
// This basically means that if the reserve is empty, then we use the default ratio supplied at deployment
ratio = self.ds[dsId].exchangeRate() - self.vault.initialDsPrice;
// will always fail for the first deposittry flashSwapRouter.getCurrentPriceRatio(self.info.toId(), dsId) returns (uint256, uint256_ctRatio) {
ratio = _ctRatio;
} catch {}
}
Since Ethereum’s mainnet has a public mempool, attackers can monitor when the first vault deposit is about to occur. It is expected that the initial liquidity provision will use a specific price ratio set by the protocol. However,since the AMM pair is empty, an attacker can frontrun the transaction by providing a small amount of liquidity to the pool first. This allows the attacker to set an incorrect RA:CT price ratio that deviates significantly from the expected initial ratio.
Consider the following scenario: (for simplicity AMM X*Y =K is not correct in the current example, but is close to a correct one)
1. New issuance has occured with exchange rate between RA:CT+DS = 1.
2. Attacker mints 10 CT + 10 DS by providing 10 RA
3. Another user decide to deposit 50 RA to the LV
4. It is expected that liquidty sent to the AMM would be ~50% RA ~ 50% CT
5. Attacker frontrun the deposit transaction and deposits 1 RA and 0.1 CT
6. Now the price ration between RA:CT would be much higher than expected.
7. Only small amount of the user's 50 RA would be used to mint CT and almost all of it(RA) are going to be provided to the pair
8. New pair reserves are going to be ~45 RA and 4.5 CT
9. Now attacker can provide his CT tokens in order to get more RA than initially invested.
This deviation from the initial price would persist over time, undermining the protocol’s core functionality and making it unusable. The issue arises because the protocol does not provide initial liquidity to the newly created pair, leaving it vulnerable to manipulation. Without setting the initial price through a controlled liquidity provision, attackers can easily deviate the RA:CT price ratio, causing long-term imbalances that disrupt the protocol's intended operations.
Impact
Protocol is going to be completely unusable as intended.
sherlock-admin3
changed the title
Raspy Silver Finch - Initial AMM price ratio can be manipulated
vinica_boy - Initial AMM price ratio can be manipulated
Sep 25, 2024
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelMediumA Medium severity issue.RewardA payout will be made for this issue
vinica_boy
High
Initial AMM price ratio can be manipulated
Summary
When providing liquidity to the AMM during new DS issuance, when depositing to the vault, or with fees, the protocol checks the current price ratio of RA:CT in order to calculate how much RA and CT are needed to be sent to the pair. Current implementation account for the case where the pool might be empty and calculating the ratio based on the reserves in it wont work. This provides an opportunity for attackers to manipulate the price ratio before the first provision of liquidity.
Vulnerability Detail
____getAmmCtPriceRatio()
is used to get the current RA:CT price ration in the AMM.Since Ethereum’s mainnet has a public mempool, attackers can monitor when the first vault deposit is about to occur. It is expected that the initial liquidity provision will use a specific price ratio set by the protocol. However,since the AMM pair is empty, an attacker can frontrun the transaction by providing a small amount of liquidity to the pool first. This allows the attacker to set an incorrect RA:CT price ratio that deviates significantly from the expected initial ratio.
Consider the following scenario: (for simplicity
AMM X*Y =K
is not correct in the current example, but is close to a correct one)1. New issuance has occured with exchange rate between RA:CT+DS = 1.
2. Attacker mints 10 CT + 10 DS by providing 10 RA
3. Another user decide to deposit 50 RA to the LV
4. It is expected that liquidty sent to the AMM would be ~50% RA ~ 50% CT
5. Attacker frontrun the deposit transaction and deposits 1 RA and 0.1 CT
6. Now the price ration between RA:CT would be much higher than expected.
7. Only small amount of the user's 50 RA would be used to mint CT and almost all of it(RA) are going to be provided to the pair
8. New pair reserves are going to be ~45 RA and 4.5 CT
9. Now attacker can provide his CT tokens in order to get more RA than initially invested.
This deviation from the initial price would persist over time, undermining the protocol’s core functionality and making it unusable. The issue arises because the protocol does not provide initial liquidity to the newly created pair, leaving it vulnerable to manipulation. Without setting the initial price through a controlled liquidity provision, attackers can easily deviate the RA:CT price ratio, causing long-term imbalances that disrupt the protocol's intended operations.
Impact
Protocol is going to be completely unusable as intended.
Code Snippet
VaultLib.onNewIssuance()
:https://github.com/sherlock-audit/2024-08-cork-protocol/blob/db23bf67e45781b00ee6de5f6f23e621af16bd7e/Depeg-swap/contracts/libraries/VaultLib.sol#L92
VaultLib.deposit()
:https://github.com/sherlock-audit/2024-08-cork-protocol/blob/db23bf67e45781b00ee6de5f6f23e621af16bd7e/Depeg-swap/contracts/libraries/VaultLib.sol#L191
VaultLib.provideLiquidityWithFee()
:https://github.com/sherlock-audit/2024-08-cork-protocol/blob/db23bf67e45781b00ee6de5f6f23e621af16bd7e/Depeg-swap/contracts/libraries/VaultLib.sol#L602
VaultLib.__getAmmCtPriceRatio()
:https://github.com/sherlock-audit/2024-08-cork-protocol/blob/db23bf67e45781b00ee6de5f6f23e621af16bd7e/Depeg-swap/contracts/libraries/VaultLib.sol#L139
Tool used
Manual Review
Recommendation
Always provide initial liquidity to newly created pairs to set the initial price ratio.
Duplicate of #186
The text was updated successfully, but these errors were encountered: