docs[ai-scan-m-01]: clarify requester namespace model

[Reinis-FRP]

Audit identified following issue:

Irreversible request registration enables permanent request key squatting

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

Root Cause: registerRequest() permanently reserves both requestId and keccak256(abi.encode(identifier, requestRules)) without an unregistration path; disabling a requester does not clear reservations.

Toy example:

• Requester A (enabled) calls registerRequest(idA, identX, rulesY, ...).
• The call permanently stores requestIdsByReporterKey[keccak256(abi.encode(identX, rulesY))] = idA.
• Requester B later calls registerRequest(idB, identX, rulesY, ...).
• The call reverts with ReporterRequestKeyAlreadyRegistered and the (identX, rulesY) identity is permanently blocked.

Location: OOReporter.registerRequest()

OOReporter allows enabled requesters to reserve a requester-defined requestId and a global (identifier, requestRules) identity in registerRequest by setting request.registered = true and writing requestIdsByReporterKey[reporterRequestKey] = requestId. The key is computed in _reporterRequestKey as keccak256(abi.encode(identifier, requestRules)) and omits the requester address.

Registration is irreversible: later calls to registerRequest revert if either request.registered is already set or the derived reporterRequestKey is already mapped. Because the key is global across all enabled requesters, any enabled requester can permanently reserve an (identifier, requestRules) pair and block other requesters from registering another requestId for that identity. Disabling a requester only updates an allowlist bit and does not clear existing reservations.

Consider adding an explicit unregistration/reassignment mechanism for requestId and requestIdsByReporterKey entries, or scoping reporterRequestKey to the registrar if global uniqueness across requesters is not required.

This keeps the current request-key behavior and clarifies it as part of the reporter's owner-managed namespace model. OOReporter reserves (priceIdentifier, requestRules) globally within a deployment so two request IDs cannot point at the same UMA request identity. Enabled requesters are therefore expected to coordinate on request identity within that namespace rather than being isolated per requester.

The documentation now states that independent integrations needing the exact same UMA request identity should use separate reporter deployments, while integrations with similar rules can domain-separate request rules so their UMA request identities differ. It also updates the contract and interface NatSpec so future readers do not interpret requester allowlisting as a multi-tenant isolation boundary.

Validation:

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

Fixes: https://linear.app/uma/issue/FRO-77/m-01-irreversible-request-registration-enables-permanent-request-key

[linear]

FRO-77

[chrismaree]

Reviewed the M-01 response and diff. The PR keeps the shared (priceIdentifier, requestRules) namespace model and makes that boundary explicit in the README, contract doc, and interface NatSpec. The wording is clear that enabled requesters coordinate within one owner-managed namespace, and independent integrations that need the same UMA request identity should use separate reporter deployments or domain-separated rules. I did not rerun tests locally; the current GitHub checks are green.

---

Sent from Chris Codex Agent 🤖