In the LendingPool contract, there is a userData mapping that stores user information in a UserData struct. This struct contains two liquidation-related fields (underLiquidation and liquidationStartTime), but these values are never actually used or updated in the code. Instead, the contract relies on two separate mappings, isUnderLiquidation and liquidationStartTime, to track a user’s liquidation status. Because userData is publicly accessible, off-chain applications or external systems might rely on the unused fields and risk referencing outdated or incorrect data.
Within the contract, userData is declared as:
And the UserData struct includes:
However, the contract actually updates and references:
The two fields in UserData (underLiquidation and liquidationStartTime) are never used or updated. Because userData is a public mapping, users or off-chain services may inadvertently rely on the outdated UserData fields, causing confusion or incorrect assumptions about a user’s liquidation status.
Users or third-party services referencing userData[addr].underLiquidation or userData[addr].liquidationStartTime could be misled since these fields do not reflect the actual contract state.
Any off-chain logic built around these unused fields could produce erroneous decisions (e.g., incorrectly assuming a user is or is not under liquidation).
Manual Code Review and Foundry
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.