As the protocol keeps its own accounting and doesn't use the ERC20 method balanceOf() to keep track of balances, the protocol will not work with tokens with elastic supply (rebasing tokens), and tokens that charge fees on transfer, and may suffer issues if tokens are burned from any of its addresses. Actions in the protocol (mints and redeems) are organized into epochs, which further amplifies the issue: If a token rebases mid epoch, the entire epoch data is wrong.
Proof of Concept
See above
Tools Used
None
Recommended Mitigation Steps
You will either need to change the design of the protocol, wrap tokens, or you will need to accept this and properly document it for the future lending pool creators.
Lines of code
https://github.com/code-423n4/2023-01-ondo/blob/f3426e5b6b4561e09460b2e6471eb694efdd6c70/contracts/cash/CashManager.sol#L221
Vulnerability details
Impact
As the protocol keeps its own accounting and doesn't use the ERC20 method
balanceOf()
to keep track of balances, the protocol will not work with tokens with elastic supply (rebasing tokens), and tokens that charge fees on transfer, and may suffer issues if tokens are burned from any of its addresses. Actions in the protocol (mints and redeems) are organized into epochs, which further amplifies the issue: If a token rebases mid epoch, the entire epoch data is wrong.Proof of Concept
See above
Tools Used
None
Recommended Mitigation Steps
You will either need to change the design of the protocol, wrap tokens, or you will need to accept this and properly document it for the future lending pool creators.