Rejected as Invalid. Publicized as Critical. Reported as Fixed. Where Is the Fix—and Who Was the Source?

1

Do Not Present an Unverified Critical-Fix Narrative as Fact

This post is not primarily a request for another private review of my reports. It is a demand that OP Labs, the Optimism Foundation, and Immunefi stop allowing an inaccurate public narrative to stand.

After my governance disclosure, a story appeared in which Optimism discovered and fixed a “critical” vulnerability before exploitation. But the public record does not establish:

  • Who supplied the information used by the articles.
  • Whether the articles relied on my governance post, another private report, an Optimism statement, or an automated summary.
  • Who first reported each underlying technical finding.
  • Which exact commit supposedly fixed the reported defect.
  • Whether the Verify-path defect described in my post was actually fixed.

What is established is that my reports were closed, I received no bounty or refund, and my substantive communications remain unanswered.

The chronology and technical overlap create a serious provenance question, but they do not answer it. That is precisely why an unverified success narrative should not be presented as established fact.

The eight closed reports and their contradictory explanations matter because they establish the record behind that public narrative.

I am not asking the community to accept my original severity estimates without examination. During my investigation, I corrected and narrowed several of my own claims when later testing did not support them.

What I am asking for is much simpler:

If a report is technically wrong, identify the precise error. If it is a duplicate, identify the earlier report and timestamp. If it was already fixed, identify the fixing commit. If it was out of scope, identify the exact published rule in force on the submission date.

I initially assumed that, as a new security researcher, I had misunderstood the program rules. I investigated the rejection reasons so that I could improve my future reports. Instead, I repeatedly found public code and official statements that contradicted or materially qualified the explanations I had received.

That is why a further private and unexplained decision is not sufficient. The inaccurate public record requires a public answer and, if unsupported, a public correction.

1. The documented report history

Report Submitted Closed Recorded reason
#82258 June 18, 04:15 June 18, 04:32 Claimed impact out of scope; asset and severity stated to be in scope
#82416 June 19, 18:46 June 19, 18:56 Critical consequences marked “NOT PROVEN”; insufficient live fault-proof evidence
#82517 June 20, 23:21 June 21, 06:38 Changed input producing a changed root was not considered a soundness defect; alloy-op-evm and Kona said not to be listed assets
#83109 June 26, 15:39 June 26, 15:55 Impact and asset in scope; severity out of scope
#83447 June 30, 04:06 June 30, 19:59 The cited op-chain-ops/pkg/sdm/workload.go was said not to exist
#83583 July 1, 15:24 July 2, 19:52 It was subsequently acknowledged that workload.go:313 contained the recompute/equality check I described, but a consensus split was said not to be established
#83996 July 5, 23:34 July 7, 04:58 The code-level asymmetry was acknowledged as technically accurate, but Lagoon was not active on a production chain
#84638 July 13, 13:52 July 14, 16:37 Treated as reconsideration of previous reports rather than a new vulnerability

All eight reports were closed. None was labelled “Duplicate,” and no bounty or refund was paid.

Some decisions were made extremely quickly:

  • #82258 was closed after 17 minutes.
  • #82416 was closed after 10 minutes.
  • #83109 was closed after 16 minutes, after a 50 USDC submission payment.

Speed alone does not prove that a review was inadequate. It does, however, make verifiable reasoning and exact references especially important.

2. A concrete contradiction in the closure explanations

Report #83447 was rejected with this statement:

“the cited Go enforcement at op-chain-ops/pkg/sdm/workload.go does not exist in the codebase”

In the following report, #83583, the response stated:

“Line 313 in op-chain-ops/pkg/sdm/workload.go is indeed a recompute-equality check … exactly as you described”

These statements concern the same file and the same check.

I have not received a correction or explanation for the first statement. If the initial rejection resulted from reviewing the wrong branch, revision, or repository state, please identify what was reviewed and correct the record.

3. “Already exists” was asserted without identifying an equivalent consensus check

The response to #82517 stated:

“The recompute-and-compare logic the report recommends already exists in the selected in-scope asset rust/op-reth”

The response referred generally to post-exec-replay, but did not identify the precise op-reth file and line that supposedly performed the equivalent consensus rejection.

I later located:

rust/op-reth/crates/post-exec-replay/src/replay.rs

That component is described as a debugging/counterfactual replay tool. It uses PostExecMode::Produce, can record mismatches in a vector, and returns a replay result containing those mismatches.

That is not obviously equivalent to having the consensus PostExecMode::Verify path reject an invalid producer-supplied refund.

If another implementation performs that consensus-enforced comparison, please provide the exact repository, commit, file, line, and test.

4. The Lagoon explanation and the published pre-production scope

For #83996, Immunefi wrote:

“The report describes a real code-level asymmetry.”

and:

“This is a technically accurate observation about the code.”

The report was nevertheless closed because Lagoon was ForkCondition::Never on the named production chains and the behavior was therefore not exploitable on a production chain at that time.

However, Optimism had publicly announced that its bounty program was being extended to cover proposed protocol upgrades before they go into production:

Optimism Extends $2 Million Bug Bounty Program to Protocol Upgrades Ahead of Superchain Interop

The public repository also showed:

  • SDM marked as a code-complete milestone in issue #20452.
  • SDM gated directly on the Lagoon hardfork in PR #21105.
  • Public work coordinating the interop_time to lagoon_time rename in issue #21135.
  • Lagoon scheduling support in the deployment configuration in PR #21148.

I am not claiming that SDM was part of the Upgrade 16 payload or already active on OP Mainnet. My question is narrower:

What exact published rule, effective on the submission date, excluded implemented but not-yet-activated protocol-upgrade code from the announced pre-production bounty coverage?

“Not active on production” does not, without further explanation, resolve that question when the public program expressly invited research into upgrades before production.

5. The unresolved attribution and chronology around #82258 and PR #21434

Report #82258 was submitted at 04:15 UTC on June 18 and closed at 04:32 UTC.

Later that day, PR #21434 was merged. Its description refers to Immunefi report #81847.

PR #21434 describes, among other things:

  • Fee-vault settlement touches claiming a rebate.
  • Caller, target, and created addresses claiming a rebate because they were intrinsically warm.

These are also specific phantom-refund causes described in #82258.

This chronology and content overlap do not, by themselves, prove unauthorized use. They do require a transparent provenance review.

I therefore request:

  1. The submission timestamp and relevant technical contents of #81847.
  2. A timestamped comparison of #81847 and #82258.
  3. An explanation of why #82258 was closed as out of scope instead of being classified as a duplicate, if #81847 already contained the same finding.
  4. Confirmation of which report supplied each technical finding implemented by PR #21434.
  5. Correction of the public credit if the timestamped records show that attribution is incomplete.

Because the reports are private, only Optimism and Immunefi currently possess the records necessary to resolve this question conclusively.

6. An unverified critical-fix narrative presented as an Optimism success story

This is the most serious issue of governance integrity and compliance.

An official governance forum should serve as a record of public accountability. After my disclosure appeared there, a success narrative emerged in which Optimism discovered and fixed a “critical” vulnerability before exploitation. However, no exact fixing commit has been identified, the information source has not been disclosed, and the relationship between that narrative and the disputed private reports remains unknown.

Examples include:

My governance post identifies me as the author of that post and states that the underlying Verify-path issue remained unresolved. That proves neither that I was the first reporter of every overlapping technical point nor that the articles used my post as their source.

Likewise, the present public record does not prove that the articles relied on #81847, on information supplied by Optimism, or on an automated aggregation process. The source is unknown and should be disclosed.

PR #21434 addressed particular phantom-rebate sources. I have not found a change there that makes verifier_post_exec_refund_for_tx recompute and compare the producer-supplied refund in the consensus Verify path.

A disputed and unresolved technical record must not be converted into corporate security publicity without establishing its source, attribution, and actual fixing commit.

If that occurred here, it is not merely a dispute over bounty eligibility. It is a serious failure of attribution, transparency, governance integrity, and compliance that the Collective must investigate publicly.

I therefore request that Optimism state publicly:

  • Whether it considers the Verify-path issue fixed.
  • The exact fixing PR and commit.
  • Which organization or statement was the source for the media claim that it was patched.
  • Which report or disclosure first documented each technical finding, based on verifiable timestamps.
  • Whether the media reports accurately identify their source and the responsible researcher, if any.
  • Whether a correction will be requested if those claims are inaccurate.

I am not asserting, without source records, that Optimism supplied the information to these publications or that I am necessarily the original reporter of every overlapping point. I am stating that the published success narrative cannot presently be verified from the governance post, private-report references, and code history available to the public.

7. What my current technical evidence establishes—and does not establish

My current tests establish the following narrower behavior:

  • The SDM Verify path accepts a producer-supplied refund without independently recomputing it.
  • On an SDM-enabled development environment, a forged refund was accepted with a VALID payload result.
  • In a five-transaction test, the forged refund reduced expected fee income from 525,000,052,500,000 wei to zero.
  • The unpaid amount remained in the sender’s L2 balance.
  • I separately demonstrated initiating a withdrawal of retained L2 balance.

I have also expressly withdrawn or limited claims that my evidence did not establish.

My present evidence does not establish:

  • Theft of unrelated third-party principal.
  • A profit exceeding the malicious sender’s own transaction costs.
  • Completion of an L1 withdrawal using the same SDM-derived test balance.
  • A full real-Kona and permissionless FaultDisputeGame reproduction.

These corrections are part of responsible research. They do not erase the separately demonstrated verification behavior or the need for a precise technical response.

8. Payments and mediation

The payment history shows:

  • Five Optimism submission payments of 50 USDC each: 250 USDC total.
  • A separate 100 USDC identity-verification payment.
  • Two separate Wormhole submission payments totalling 50 USDC.

The total platform payments shown are 400 USDC, but only 250 USDC represents Optimism report-submission payments. There is no corresponding payment row in the available history for the first three Optimism reports.

No Optimism bounty or refund was paid.

I did not pay for or commence mediation.

The mediation interface for #84638 displayed:

  • A free Standard queue, but stated that free mediation was unavailable for reports closed by the Immunefi team.
  • A further message stating that the project required Priority mediation.
  • Priority mediation priced at 250 USDC.
  • A warning that payment would not influence the result and would not guarantee a favorable decision.

Therefore, the official route proposed after closure was visible to me only as a paid 250 USDC option. I did not purchase it.

9. Unanswered communications

I preserved ten outgoing .eml files representing nine unique Message-IDs. They include communications sent to support and later expanded to information, contact, legal, and team addresses.

The preserved archive contains no incoming Immunefi email resolving the technical questions, attribution issue, or refund request.

There was one platform response from Customer Support on July 15. It referred me to mediation, mentioned my report-validity rating, and warned about publication rules. It did not answer the refund request or the technical contradictions listed above.

Subsequent requests recorded on the platform received no further substantive response through August 3.

10. The effect on the researcher

I initially believed that these outcomes might simply reflect my inexperience with bug-bounty rules.

I therefore spent approximately one month reviewing code across multiple implementations and layers, reproducing behavior, preparing tests and proposed patches, and correcting my own claims where the evidence required it.

Instead of receiving explanations that allowed me to understand and improve, I repeatedly encountered reasons that could be contradicted or materially qualified using public GitHub code and Optimism’s own published materials.

This has seriously disrupted my work as an audio engineer and caused substantial psychological distress.

Compensation matters. But the more fundamental issue is receiving a coherent, evidence-based decision:

  • If the report is technically wrong, identify the precise error.
  • If it is a duplicate, identify the earlier report and its timestamp.
  • If it was already fixed, identify the fixing commit.
  • If it was out of scope, identify the exact published rule that applied on the submission date.
  • If public credit is incorrect, correct it.
  • If a media report incorrectly says the vulnerability was fixed, identify the actual fix or request a correction.

Researchers cannot investigate against secret rules.

Required public correction and accountability

My principal request is not another opaque internal review. I require OP Labs, the Optimism Foundation, and Immunefi to address the public representation directly:

  1. Stop representing the disclosure as an Optimism critical-fix success story unless that claim can be substantiated.
  2. Identify the exact PR and commit that fixed the defect described in my governance post.
  3. Identify the source supplied to, or relied upon by, the publications that described the issue as patched.
  4. Publish a timestamp-based attribution record identifying which report or researcher first supplied each relevant technical finding.
  5. Request corrections from publications if the “patched before exploitation” claim or attribution is inaccurate.
  6. Publish a timestamped comparison of #81847 and #82258 sufficient to resolve precedence and credit.
  7. Correct the contradictory workload.go statements and provide the exact consensus code said to implement recompute-and-compare protection.
  8. Identify the contemporaneous rule used to exclude #83996 despite the published pre-production-upgrade coverage.
  9. Address bounty eligibility and the 250 USDC in Optimism submission payments only after the public technical and attribution record has been corrected.
  10. Provide a named, authorized contact and a substantive response.

I am not publishing private exploit parameters in this post. I am prepared to provide the preserved reports, receipts, email files, hashes, code references, and test materials through an authorized channel.

I do not want another generic instruction to submit a new report, purchase mediation, or wait for an unspecified internal review. I want the unsupported success narrative stopped and the public record corrected.

Honor the rules and representations you publish. If they cannot be honored, do not ask researchers to rely on them.

Continued silence does not resolve these issues. Its practical effect is to leave the researcher with no accessible review path except to abandon the matter.

I am asking publicly whether that is the intended outcome—and, if it is not, who will take responsibility for resolving this record.

Perhaps I can say this precisely because I am an engineer from another industry: if other researchers already know that such opaque and unreasonable treatment occurs, why has it been allowed to remain unspoken?

I am writing this in the sincere hope that the many diligent and talented researchers who may have endured the same frustration will no longer be forced into silence, and will finally receive the recognition and fair treatment they deserve.

[Edit/Update]: Special thanks to John and the team for following up directly on the separate security matter. As that issue is now being handled through appropriate channels, I have removed the previous note to keep this forum post focused solely on the governance and public attribution record.

— Yomibito Shirazu / Yohei Ishijima