The contract uses a single global variable, lastUpdateTimestamp, to record the update time for all token prices rather than maintaining individual timestamps for each token. This means that whenever any token's price is updated, the timestamp is overwritten for all tokens, regardless of whether their individual prices have changed.
->
The root cause is the use of a global lastUpdateTimestamp instead of tracking timestamps on a per-token basis. Each token's price should have its own associated timestamp to accurately reflect when it was last updated. Without this, the system cannot distinguish between tokens updated recently and those that haven’t been refreshed in a long time.
Explain in relevant detail using numbers and creating scenarios demonstrating the impact
Consider the following scenario:
TokenID 1: Price updated at time T (e.g., now) with a value of $400K.
TokenID 2: Price was last updated one year ago at time T - 365 days with a value of $300K.
The oracle updates the price for TokenID 1, setting lastUpdateTimestamp to the current time T.
When the lending protocol queries getLatestPrice for TokenID 2, it receives the stale price of $300K alongside the recent timestamp T, misleading the protocol into treating the stale price as fresh.
A borrower then uses TokenID 2 as collateral and is allowed to borrow $400K based on the perceived price.
Later, when the true price of TokenID 2 is realized say,
it remains $300K or drops further , the loan is found to be undercollateralized, resulting in a potential loss of $100K for the protocol.
Because the freshness of a token's price is determined by the update timestamp, a recently updated price for one token can make stale prices for other tokens appear current. This can lead to critical mispricing in protocols relying on these values. For instance, a lending platform could use an outdated and inaccurate price for collateral calculations, resulting in loans that are undercollateralized and increasing the risk of bad debt.
To fix this issue, the contract should maintain individual timestamps for each token. One approach is to change the mapping to store a struct containing both the price and its associated timestamp for each token. For example:
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.