docs[ai-scan-n-01]: clarify rules update identity

[Reinis-FRP]

Audit identified following issue:

updateRequestRules() can cause off-chain requestId misbinding when using updatedRules as identity

• Tag: N-01
• Severity: Note

Root Cause: updateRequestRules() records updatedRules as history only, so (priceIdentifier, updatedRules) remains a separate, registerable key that can map to a different requestId.

Toy example:

• Requester A calls registerRequest() with (priceIdentifier = PID, requestRules = R0) and chooses requestId = X.
• Requester A calls updateRequestRules(X, R1).
• Requester B calls registerRequest() with (priceIdentifier = PID, requestRules = R1) and chooses requestId = Y.
• A consumer calling getRequestId(PID, R1) resolves Y instead of X.

Location: OOReporter.registerRequest() / OOReporter.updateRequestRules()

OOReporter exposes registerRequest to create a requestId and bind it to the reporter lookup key keccak256(abi.encode(priceIdentifier, requestRules)) via _reporterRequestKey. Consumers can later resolve this mapping using getRequestId.

However, updateRequestRules only appends updatedRules to requestRulesUpdates[requestId] and emits RequestRulesUpdated; it does not update request.requestRules or requestIdsByReporterKey. This means (priceIdentifier, updatedRules) is not reserved for the original requestId. A different enabled requester can register a new request under (priceIdentifier, updatedRules), and any off-chain integration that (incorrectly) treats updatedRules as the canonical identity and calls getRequestId(priceIdentifier, updatedRules) can be redirected to the new request, or revert if no such request exists. The interface comment already states that rules updates are for off-chain consumers "without changing the active OO tuple". See IOOReporter.updateRequestRules.

Consider reducing consumer confusion by making the informational-only semantics explicit in the API and documentation. For example, rename updateRequestRules() to indicate history, and document that requestId is the stable external identifier (as described in pm-v2-oo-reporter/README.md). If supporting lookups by updated rules is desired, consider adding an explicit aliasing mechanism that maps specific updatedRules values to the original requestId.

This keeps the ABI locked for Polymarket-side audits and clarifies the informational-only semantics in NatSpec and package documentation instead of changing reporter behavior.

The documentation now states that requestId is the stable external identity for request-rules update history. Tuple-based lookups use the original (priceIdentifier, requestRules) supplied at registration; values later posted through updateRequestRules(...) do not replace the original rules and do not create (priceIdentifier, updatedRules) lookup aliases.

The interface NatSpec mirrors that behavior on updateRequestRules, getRequestId, and the tuple-based getRequestRulesUpdates / getLatestRequestRulesUpdate overloads so off-chain consumers do not treat updated rules as canonical identity.

Validation:

• forge fmt --check src/interfaces/IOOReporter.sol from pm-v2-oo-reporter
• git diff --check -- pm-v2-oo-reporter/README.md pm-v2-oo-reporter/src/interfaces/IOOReporter.sol
• forge test --match-path test/OOReporter.t.sol from pm-v2-oo-reporter

Fixes: https://linear.app/uma/issue/FRO-80/n-01-updaterequestrules-can-cause-off-chain-requestid-misbinding-when

[linear]

FRO-80

[chrismaree]

Reviewed the N-01 response and diff. The README and interface NatSpec now make the stable identity model explicit: requestId is the stable external key, tuple-based lookups use the original registered (priceIdentifier, requestRules), and updateRequestRules values are append-only history rather than lookup aliases. That resolves the consumer-confusion risk without changing the locked ABI. I did not rerun tests locally; the current GitHub checks are green.

---

Sent from Chris Codex Agent 🤖