The LLMOracleManager contract is inherited by the upgradeable LLMOracleCoordinator contract, but it does not implement storage gaps. This makes the contract vulnerable to storage collisions during upgrades.
The inheritance chain is as follows:
While OwnableUpgradeable.sol
from OpenZeppelin implement the "ERC-7201: Namespaced Storage Layout", LLMOracleManager does not nor has a storage gap.
Adding new storage variables to LLMOracleManager in future upgrades could potentially overwrite the beginning of the storage layout of LLMOracleCoordinator, causing critical misbehaviors in the system.
Storage of LLMOracleCoordinator might be corrupted during upgrades
This could lead to loss of critical protocol configuration and state regarding registry
, feeToken
, nextTaskId
, requests
, responses
or validations
state variables.
The entire oracle system could become non-functional if storage is corrupted
Add a storage gap at the end of LLMOracleManager.
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.