thisvishalsingh - protocol NapierPool.sol rely on pool reserves can be an be manipulated, especially using a flashloan.
thisvishalsingh
High Risk
protocol NapierPool.sol rely on pool reserves can be an be manipulated, especially using a flashloan.
Summary
The contract NapierPool.sol is vulnerable to flash loan attacks due to reliance on pool reserves, which can be manipulated, especially using flashloans.
Various aspects of the protocol, including liquidity provision, removal, swaps, state loading and writing, skim function, fee setting, balance checks, token approvals, callbacks, and minting/burning functions, all depend on the integrity of the pool reserves.
This reliance poses a significant risk as it could potentially lead to the manipulation of the pool's assets and expose the protocol to various vulnerabilities if not adequately managed.
Vulnerability Detail
Here are the points where the protocol relies on pool reserves:
Liquidity Provision: When liquidity is added to the pool, the addLiquidity function updates the totalUnderlying and totalBaseLpt state variables to reflect the new amounts of assets in the pool. This is done by adding the amounts of underlying and base LP tokens deposited by the liquidity provider.
Liquidity Removal: The removeLiquidity function uses the totalUnderlying and totalBaseLpt state variables to calculate the amounts of underlying and base LP tokens to be withdrawn. It then updates these state variables after the withdrawal to reflect the new state of the pool's assets.
Swaps: The swapPtForUnderlying and swapUnderlyingForPt functions use the totalUnderlying and totalBaseLpt state variables to calculate the amounts of underlying and base LP tokens to be swapped. They also update the state variables after the swap to reflect the new state of the pool's assets.
State Loading: The _loadState function loads the current state of the pool, including the totalUnderlying and totalBaseLpt values, into a PoolState struct. This state is used in various calculations throughout the contract.
State Writing: The _writeState function writes the updated state of the pool back to storage after certain operations, such as swaps and liquidity removals.
Skim Function: The skim function transfers excess tokens to the fee recipient, which could potentially be used to manipulate the pool reserves if not properly managed.
Fee Setting: The setFeeParameter function allows the factory owner to set fee parameters, which could indirectly affect the pool reserves if the fees are not properly accounted for in the calculations.
Balance Checks: The _balance function is used to check the balance of the contract's own tokens, which is a form of relying on the pool reserves.
Token Approvals: The constructor approves the Curve pool to transfer principal tokens, which could potentially be manipulated if the approvals are not properly managed.
Callbacks: The contract interacts with callback functions, which could potentially be manipulated if not properly secured.
Minting and Burning: The _mintLiquidity and _burnLiquidity functions use the totalUnderlying and totalBaseLpt state variables to calculate the amounts of LP tokens to be minted or burned.
Impact
Relying on pool reserves can be risky, as they can be manipulated, especially using a flashloan.
thisvishalsingh
medium
thisvishalsingh - protocol
NapierPool.sol
rely on pool reserves can be an be manipulated, especially using a flashloan.thisvishalsingh
High Risk
protocol
NapierPool.sol
rely on pool reserves can be an be manipulated, especially using a flashloan.Summary
The contract
NapierPool.sol
is vulnerable to flash loan attacks due to reliance on pool reserves, which can be manipulated, especially using flashloans. Various aspects of the protocol, includingliquidity provision, removal, swaps, state loading and writing, skim function, fee setting, balance checks, token approvals, callbacks, and minting/burning functions
, all depend on the integrity of the pool reserves. This reliance poses a significant risk as it could potentially lead to the manipulation of the pool's assets and expose the protocol to various vulnerabilities if not adequately managed.Vulnerability Detail
Here are the points where the protocol relies on pool reserves:
Liquidity Provision: When liquidity is added to the pool, the
addLiquidity
function updates thetotalUnderlying
andtotalBaseLpt
state variables to reflect the new amounts of assets in the pool. This is done by adding the amounts of underlying and base LP tokens deposited by the liquidity provider.Liquidity Removal: The
removeLiquidity
function uses thetotalUnderlying
andtotalBaseLpt
state variables to calculate the amounts of underlying and base LP tokens to be withdrawn. It then updates these state variables after the withdrawal to reflect the new state of the pool's assets.Swaps: The
swapPtForUnderlying
andswapUnderlyingForPt
functions use thetotalUnderlying
andtotalBaseLpt
state variables to calculate the amounts of underlying and base LP tokens to be swapped. They also update the state variables after the swap to reflect the new state of the pool's assets.State Loading: The
_loadState
function loads the current state of the pool, including thetotalUnderlying
andtotalBaseLpt
values, into aPoolState
struct. This state is used in various calculations throughout the contract.State Writing: The
_writeState
function writes the updated state of the pool back to storage after certain operations, such as swaps and liquidity removals.Skim Function: The skim function transfers excess tokens to the fee recipient, which could potentially be used to manipulate the pool reserves if not properly managed.
Fee Setting: The
setFeeParameter
function allows the factory owner to set fee parameters, which could indirectly affect the pool reserves if the fees are not properly accounted for in the calculations.Balance Checks: The
_balance
function is used to check the balance of the contract's own tokens, which is a form of relying on the pool reserves.Token Approvals: The constructor approves the Curve pool to transfer principal tokens, which could potentially be manipulated if the approvals are not properly managed.
Callbacks: The contract interacts with
callback
functions, which could potentially be manipulated if not properly secured.Minting and Burning: The
_mintLiquidity
and_burnLiquidity
functions use thetotalUnderlying
andtotalBaseLpt
state variables to calculate the amounts of LP tokens to be minted or burned.Impact
Relying on pool reserves can be risky, as they can be manipulated, especially using a flashloan.
Code Snippet
https://github.com/sherlock-audit/2024-01-napier/blob/main/v1-pool/src/NapierPool.sol#L606 https://github.com/sherlock-audit/2024-01-napier/blob/main/v1-pool/src/NapierPool.sol#L166 https://github.com/sherlock-audit/2024-01-napier/blob/main/v1-pool/src/NapierPool.sol#L274
and similarly other should reconsider as above mentioned in Vulnerablity Details
Tool used
Manual Review
Recommendation
Implement alternative methods or checks without relying solely on pool reserves