Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LiquidityPool's Non-Compliance with ERC-4626 Due to Rounding Issues #562

Closed
c4-submissions opened this issue Sep 14, 2023 · 3 comments
Closed
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

Comments

@c4-submissions
Copy link
Contributor

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).

Finally, ERC-4626 Vault implementers should be aware of the need for specific, opposing rounding directions across the different mutable and view methods, as it is considered most secure to favor the Vault itself during calculations over its users:

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 and previewWithdraw, which are expected to round up as per the standard, are currently rounding down.

Tools Used

VS Code

Recommended Mitigation Steps

previewMint and previewWithdraw should round up

Assessed type

ERC4626

@c4-submissions c4-submissions added 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 labels Sep 14, 2023
c4-submissions added a commit that referenced this issue Sep 14, 2023
@c4-pre-sort
Copy link

raymondfam marked the issue as sufficient quality report

@c4-pre-sort c4-pre-sort added the sufficient quality report This report is of sufficient quality label Sep 15, 2023
@c4-pre-sort
Copy link

raymondfam marked the issue as duplicate of #34

@c4-judge
Copy link

gzeon-c4 marked the issue as satisfactory

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Sep 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

3 participants