LiquidityPool's Non-Compliance with ERC-4626 Due to Rounding Issues #562
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
duplicate-34
satisfactory
satisfies C4 submission criteria; eligible for awards
sufficient quality report
This report is of sufficient quality
Lines of code
https://github.com/code-423n4/2023-09-centrifuge/blob/main/src/LiquidityPool.sol#L160-L162
https://github.com/code-423n4/2023-09-centrifuge/blob/main/src/InvestmentManager.sol#L392
https://github.com/code-423n4/2023-09-centrifuge/blob/main/src/InvestmentManager.sol#L616
https://github.com/code-423n4/2023-09-centrifuge/blob/main/src/InvestmentManager.sol#L692
Vulnerability details
Impact
Other protocols that integrate with centrifufge may wrongly assume that the functions are EIP-4626 compliant.
Proof of Concept
EIP 4626's Security Considerations (https://eips.ethereum.org/EIPS/eip-4626).
If (1) it’s calculating how many shares to issue to a user for a certain amount of the underlying tokens they provide or (2) it’s determining the amount of the underlying tokens to transfer to them for returning a certain amount of shares, it should round down.
If (1) it’s calculating the amount of shares a user has to supply to receive a given amount of the underlying tokens or (2) it’s calculating the amount of underlying tokens a user has to provide to receive a certain amount of shares, it should round up.
The
LiquidityPool
, which claims to adhere to the ERC-4626 standard, has been found to have a significant discrepancy in its internal logic. The primary functions,previewMint
andpreviewWithdraw
, which are expected to round up as per the standard, are currently rounding down.Tools Used
VS Code
Recommended Mitigation Steps
previewMint
andpreviewWithdraw
should round upAssessed type
ERC4626
The text was updated successfully, but these errors were encountered: