docs[ai-scan-m-03]: clarify reporter-requested OO parameters

[Reinis-FRP]

Audit identified following issue:

Request-manager overrides can desync OOReporter parameters and brick proposals

• Tag: M-03
• Severity: Medium
• Status: Open

Root Cause: ManagedOptimisticOracleV2 mutates bond/liveness and enforces proposer whitelists at proposal time using a timestamp-less key; OOReporter validates/emits parameters at request time only.

Toy example:

• A request is registered with liveness bounds [1 day, 2 days].
• An oracle initializer calls initializeRequest(..., liveness = 1 day, proposalBond = 100).
• A request manager configures a custom proposer whitelist that contains no addresses for the managed-request key.
• All proposals revert, so no disputes/settlements occur and OOReporter never emits RequestRerequestAllowed (set in _allowRerequest).

Location: ManagedOptimisticOracleV2.sol#L354-L379

OOReporter registers per-request liveness bounds in registerRequest and enforces them at initialization and manual re-request time via _requireValidRequestLiveness. It also stores and emits proposalBond and liveness during initializeRequest and re-requests (via _executeRerequest). Consumers may therefore treat these stored/emitted values as authoritative for the active oracle request.

However, ManagedOptimisticOracleV2 applies request-manager “preconfigs” during proposal: proposePriceFor overwrites request.requestSettings.bond and request.requestSettings.customLiveness and enforces an effective proposer whitelist for both proposer and msg.sender. These settings are controlled by accounts with REQUEST_MANAGER_ROLE (gated by onlyRequestManager). The overrides are keyed by getManagedRequestId(requester, identifier, ancillaryData), which omits the timestamp, so the same overrides apply across OOReporter re-requests that only change requestTimestamp. This can (a) make the oracle’s effective liveness/bond diverge from OOReporter’s stored values (including outside the registered bounds), misleading onchain/offchain consumers, and (b) permanently brick a request by configuring a proposer whitelist that excludes all callers. In the “no proposal possible” case, the request remains in State.Requested (_getState), no callbacks execute, and OOReporter’s manual re-request entrypoint stays blocked by RequestRerequestNotAllowed.

Consider hardening integration boundaries by either (a) prohibiting request-manager overrides for OOReporter requests (role separation / dedicated oracle instance), or (b) making OOReporter treat oracle-side settings as the source of truth (e.g., emit/serve “effective” parameters by reading oracle.getRequest(...) at consumption time). Consider adding a recovery path for requests stuck in State.Requested (e.g., an owner/initializer override to bypass the request.rerequestAllowed gate checked in rerequest after a timeout), and require proposer whitelists to be either disabled or non-empty.

This keeps the existing Managed OO trust boundary and documents the parameter semantics at the OOReporter interface instead of changing reporter behavior. Managed OO request-manager preconfigs are privileged oracle-level configuration and can still affect the effective proposal-time bond, liveness, or proposer whitelist for a request.

The documentation now states that proposalBond and liveness are reporter-requested parameters for the active Managed OO request, not final attestations of the effective proposal-time settings. The interface NatSpec also clarifies this on the stored request state, RequestInitialized / RequestRerequested events, and initializeRequest / rerequest parameters.

This mirrors the existing production UmaCtfAdapter trust boundary while making the split OOReporter interface less ambiguous for downstream consumers. PM-side market recovery remains in the v2 adapter/aggregator layer, where OracleAggregator.resolveResult(...) can finalize by arbitrator or admin override without requiring OOReporterModule.report(...) to succeed.

Validation:

• forge fmt --check src/interfaces/IOOReporter.sol from pm-v2-oo-reporter
• git diff --check -- pm-v2-oo-reporter/src/interfaces/IOOReporter.sol

Fixes: https://linear.app/uma/issue/FRO-79/m-03-request-manager-overrides-can-desync-ooreporter-parameters-and

[linear]

FRO-79

[chrismaree]

Reviewed the M-03 response and diff. The interface now clearly states that proposalBond and liveness are reporter-requested values and that effective proposal-time values can differ if Managed OO request-manager preconfigs apply. That is the right documentation-only response if the Managed OO request-manager remains a privileged/trusted configuration layer and market-side recovery remains outside OOReporter. I did not rerun tests locally; the current GitHub checks are green.

---

Sent from Chris Codex Agent 🤖