When multiple requests are sent in quick succession for different house NFT IDs, there is a chance that all price updates will apply to the same, most recently set ID. Furthermore, if responses arrive out of order in an asynchronous environment, a later request could overwrite an earlier request’s intended price, leaving the earlier NFT ID without an updated price.
The contract relies on a global variable (lastHouseId) to store the NFT ID before processing oracle responses. In an asynchronous setting like Chainlink Functions, rapid or simultaneous requests can lead to two primary issues:
If multiple requests are in flight, slow oracle responses can result in all updates writing to the same ID, causing temporary or permanent mispricing.
If the response order is reversed (the later request arrives first), the wrong NFT ID might receive the price meant for another ID, potentially becoming a persistent error.
While the sendRequest function is limited to the owner, the likelihood increases if the owner submits many requests at once for multiple NFTs.
Although the sendRequest function to send the request can only be executed by the owner, given the existence of multiple house NFTs and the fact that various NFTs will be added in the future, the owner may send the request at once for faster processing. This can be problematic enough.
Incorrect pricing for multiple house NFTs
Potentially permanent mispricing if subsequent requests do not override the erroneous updates
Reduced trust in the pricing mechanism, negatively affecting the overall system
Manual Code Review and Foundry
Include the NFT ID in the oracle’s response and use it to determine which house NFT price to update, instead of relying on a single global variable.
Verify that the received ID matches the intended house NFT ID before setting the price.
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.