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
function getPoolTotalEstimatedValue()
publicviewreturns (uint256poolTotalEstimatedValue_)
{
int256 poolTotalEstimatedValueSigned =int256(totalPrincipalTokensCommitted)
+int256(totalInterestCollected) +int256(tokenDifferenceFromLiquidations)
-int256(totalPrincipalTokensWithdrawn);
//if the poolTotalEstimatedValue_ is less than 0, we treat it as 0.
There are multiple reasons why the pools share value can sharply increase/decrease:
The possible value of tokenDifferenceFromLiquidations for an auction ranges from (764% * amountDue , -amountDue) and is updated when the dutch auction for the collateral liquidation settles. This allows for a user to either front-run and deposit (in case the auction will be settling at a higher price) or prepare for a withdrawal and then withdraw their share at a higher price before the auction settles at a lower price inflicting the loss to the other shareholders. This also affects the new depositors since the _minSharesAmountOut won't be effective
Interest repayment: In case of a large interest repayment, users who monitor for this can front run this repayment and then queue a withdrawal. This way they won't be deposited into the pool but will still earn the interest
Internal pre-conditions
No response
External pre-conditions
No response
Attack Path
User monitors a large repayment of interest
User front-runs this tx and deposits into the pool
User then queues withdrawal for their shares to take the profit
Impact
Naive users can suffer unfair losses
PoC
No response
Mitigation
Implementing a depsoit queue could solve the share value increase issue
The text was updated successfully, but these errors were encountered:
Dandy Caramel Tortoise
Medium
Sudden drop/increase in share value allows users who monitor to gain at the expense of the others
Summary
Sudden drop/increase in share value allows users who monitor to gain at the expense of the others
Root Cause
The pools value is calculated as:
https://github.com/sherlock-audit/2024-11-teller-finance-update/blob/0c8535728f97d37a4052d2a25909d28db886a422/teller-protocol-v2-audit-2024/packages/contracts/contracts/LenderCommitmentForwarder/extensions/LenderCommitmentGroup/LenderCommitmentGroup_Smart.sol#L430-L440
There are multiple reasons why the pools share value can sharply increase/decrease:
The possible value of
tokenDifferenceFromLiquidations
for an auction ranges from (764% * amountDue , -amountDue) and is updated when the dutch auction for the collateral liquidation settles. This allows for a user to either front-run and deposit (in case the auction will be settling at a higher price) or prepare for a withdrawal and then withdraw their share at a higher price before the auction settles at a lower price inflicting the loss to the other shareholders. This also affects the new depositors since the_minSharesAmountOut
won't be effectiveInterest repayment: In case of a large interest repayment, users who monitor for this can front run this repayment and then queue a withdrawal. This way they won't be deposited into the pool but will still earn the interest
Internal pre-conditions
No response
External pre-conditions
No response
Attack Path
Impact
Naive users can suffer unfair losses
PoC
No response
Mitigation
Implementing a depsoit queue could solve the share value increase issue
The text was updated successfully, but these errors were encountered: