In the BuyerAgent contract, both oracleStateRequest and oraclePurchaseRequest functions initiate new requests by interacting with the LLMOracleCoordinator. Each function is intended to be used in a specific phase of the protocol’s lifecycle—oracleStateRequest during the Withdraw phase and oraclePurchaseRequest during the Buy phase. However, both functions lack protection against overwriting a previously stored task ID in their respective mappings (oracleStateRequests and oraclePurchaseRequests). If called multiple times within the same round, either function can inadvertently overwrite an existing request, potentially losing track of prior requests and their associated data. This issue could disrupt normal operations, particularly if repeated calls are made due to error or misuse, leading to unintended duplicate requests and increased costs.
The oracleStateRequest and oraclePurchaseRequest functions in BuyerAgent are meant to call the request function from LLMOracleCoordinator and store the resulting task IDs in oracleStateRequests[round] and oraclePurchaseRequests[round], respectively. Each round is expected to have unique task IDs for each request type. However, neither function verifies if the respective mapping already contains a task ID before overwriting it. As a result, multiple calls within the same round can lead to an unintended overwrite of the original request, causing data loss and duplicate requests.
Here’s the relevant section of the oracleStateRequest function:
Both oracleStateRequest and oraclePurchaseRequest overwrite their mappings without verifying if a task ID is already stored. If either function is called multiple times within the same round, it will overwrite the previous task ID, causing loss of reference to the original request.
Multiple calls within the same round can overwrite the original task ID, potentially losing critical tracking information. This disrupts the protocol’s ability to accurately reference and retrieve oracle requests made in a specific round. If either function is called multiple times within a round, duplicate oracle requests are generated, consuming additional fees and resources unnecessarily. This affects protocol efficiency and increases costs for the requester.
The current setup relies on manual or external checks by operators to avoid overwriting. Without programmatic protection, operators may inadvertently cause data loss or incur duplicate fees by calling these functions multiple times within the same round.
Manual Review
Add a check in both oracleStateRequest and oraclePurchaseRequest to ensure that a request ID is not already stored in oracleStateRequests[round] or oraclePurchaseRequests[round] before making a new request.
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.