feat[oz-retainer-07]: add reversible pre-proposal pause and reward recovery

[md0x]

Feature

FRO-106 adds a reversible pre-proposal pause and reward-recovery flow for active Managed OO requests. This is an additional Retainer 07 feature rather than an audit finding.

References: FRO-106 · audited scope tag

Resolution

• Add requester and request-manager reward setters that are available only while a request is in Requested.
• Pull reward increases from the caller and return reductions to the original requester, using the existing deferred-payout path when a transfer fails.
• Add the reporter initializer path, fund only the effective delta, and synchronize its cache from the Managed OO request and dispute refund.
• Preserve zero-reward proposal semantics: pausing uses a real enabled proposer whitelist with no members; address(0) restores the default whitelist, while DisabledAddressWhitelist remains permissionless.
• Document the pause/restore order, proposal race, timestamp-independent whitelist persistence, initializer reward caps, and working-balance guidance.
• Lower the root optimizer runs from 25 to 1 to keep ManagedOptimisticOracleV2 deployable under EIP-170.

Validation

• forge test --match-contract 'ManagedOptimisticOracleV2Test|DeferredPayoutTest' — 73 tests passed
• Polygon fork suites — 15 tests passed
• cd pm-v2-oo-reporter && forge test --match-path test/OOReporter.t.sol — 45 tests passed
• forge build --sizes — ManagedOptimisticOracleV2 24,319 B (257 B margin)
• cd pm-v2-oo-reporter && forge build --sizes --optimize false — OOReporter 24,490 B (86 B margin)
• cd pm-v2-oo-reporter && forge fmt --check
• git diff --check

[linear]

FRO-106

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[Reinis-FRP]

Approved. The implementation preserves the intended requester/request-manager funding and refund boundaries and keeps OOReporter synchronized for re-requests. The targeted ABI decoding and guarded unchecked arithmetic are acceptable maintainability compromises to stay within the tight EIP-170 bytecode limits.

Reinis Codex coding agent 🤖

[Reinis-FRP]

why make distinction here as setReward always binds request with msg.sender, so only the original requester can call this?

[md0x]

Correct—on setReward, msg.sender is both the caller and requester. The distinction came from the shared _setReward path, where requestManagerSetReward has a different payer and refund recipient. I tightened the implementation and interface NatSpec in c2fc9c5 to state directly that the requester funds increases and receives decreases.

[chrismaree]

FRO-106’s current acceptance criteria say direct request-manager reward changes “must not leave OOReporter.RequestData.reward stale” and that OOReporter keeps its cached reward synchronized with MOOv2. This head intentionally permits temporary staleness after requestManagerSetReward; the test asserts it, and the README documents resynchronization only on a later initializer update or dispute callback.

The execution paths appear safe because reporter-side updates read the live oracle reward and the dispute callback resynchronizes before an automatic re-request. The public getRequest() cache is nevertheless non-authoritative during that interval, so the implementation does not satisfy the issue as written.

Please either add an explicit synchronization mechanism, or get product/security acceptance for temporary cache staleness and update FRO-106’s requirements and docs to make that relaxation unambiguous. This is a scope/contract decision rather than a small local patch.

---

Sent from Chris Codex Agent 🤖

[md0x]

The temporary cache lag after a direct request-manager update is now accepted and documented behavior. FRO-106’s limitations, acceptance criteria, and focused-test wording now make Managed OO authoritative during that interval. Commit c2fc9c5 also clarifies the README: getRequest(requestId).reward can retain its prior value until setRequestReward reads the live oracle reward or a dispute callback synchronizes the refund before an automatic re-request. No functional contract behavior changed.

@chrismaree please re-review the updated scope and documentation.