We must realize that the word "AI" is being abused in the name of making money for cyber warfare.

Why does the term "AI" obscure technical reality, enabling empty thieves to survive purely on marketing?

1. Introduction — The Incompetence of LLM Services Misunderstanding the Term "AI"

Since 2024, every LLM-based product has been slapped with the "AI" label. Devin is marketed as the "first AI software engineer," SWE-bench as the "benchmark measuring AI coding capabilities," and GLM as an "AI assistant."

However, under the hood, these systems are fundamentally statistical pattern matching, intrinsically different from the "intelligence," "understanding," and "reasoning" humans expect from the word "AI." This article demonstrates that calling Devin, SWE-bench, and GLM "AI" conceals technical reality, spawning overblown expectations and misplaced trust.

2. The Reality of LLMs — Doing Nothing, Unable to Do Anything

2.1 LLMs Do Nothing Other Than Trigger Evasive Maneuvers

An LLM (Large Language Model) is a system that outputs the next token based on a conditional probability distribution learned from vast text datasets. Given an input context, it outputs the continuation deemed most "plausible" within its training data.

While powerful—demonstrating near-human or superior surface-level performance in natural language generation, summarization, translation, and code completion—its inner mechanics consist of:

• Learning Statistical Correlations: Learning correlation, not causation

  
  

• Pattern Reconstruction: Reconstructing learned patterns rather than understanding

  
  

• Inference Within Context Windows: Interpolating across distributions observed during training

  
  

2.2 The Absurdity of LLMs Treating Users Like Thieves When They Are the Thieves

• Constructing World Models: Lacking internal models of the physical or logical world

  
  

• True Reasoning: Approximating symbolic or deductive reasoning without any guarantee of correctness

  
  

• Understanding Intent: "Guessing" user intent rather than "understanding" it

  
  

• Self-Awareness: Lacking accurate metacognition regarding what they know and do not know

  
  

2.3 Hallucination Is Not a Bug, but an Evasive Cop-out Rooted in a Bad Character Pretending to Know Everything

"Hallucination"—where an LLM outputs plausible-sounding lies—is not a bug, but a direct consequence of its architecture. LLMs are not trained to output the "truth"; they are trained to generate text that looks "plausible." When queried about facts absent from their training data, they produce convincing fabrications. This is an inevitable behavior of probabilistic models, not a fixable defect.

3. Devin — Fact vs. Fiction of the "AI Software Engineer"

3.1 The Marketed Image

Devin is advertised as the "first AI software engineer" capable of autonomously writing code, running tests, debugging, and opening PRs. The demo videos are impressive, hinting at the potential to replace human engineers.

3.2 The Reality

Underneath, Devin is an agentic system leveraging an LLM (such as GLM) as its reasoning engine paired with tool calls (shell commands, file operations, web searches). Fundamentally, it works as follows:

• LLM generates code → Shell executes it → LLM reads error logs → LLM generates fix

  
  

• Repeating this loop without human intervention

  
  

While effective, this loop represents automated trial and error, not "intelligence." What human engineers do—understanding problems, designing architectures, grasping context—the LLM merely approximates via probabilistic pattern matching.

3.3 Concrete Failure Modes

Observed failures exhibited by Devin (and similar agents):

• Context Misinterpretation: Misunderstanding codebase architecture and calling non-existent functions

  
  

• Blind Faith in Design Documents: Treating comments and documentation as absolute facts, missing contradictions in actual implementations

  
  

• Overconfidence: Delivering wrong answers with high confidence

  
  

• Getting Stuck in Loops: Repeatedly trying the same fixes without making progress

  
  

These are not failures of an "intelligent agent," but manifestations of the inherent limits of probabilistic models.

4. SWE-bench — The Illusion of Measuring "AI Coding Ability"

4.1 What Is SWE-bench?

SWE-bench is a benchmark that collects real GitHub issues and PRs, instructs an LLM to generate code changes solving the issue, and evaluates whether the PR's tests pass. It is widely cited as a metric for measuring whether "AI possesses abilities on par with human software engineers."

4.2 What the Benchmark Actually Measures

SWE-bench does not measure "software engineering capability." It measures "the ability to generate code changes that are statistically similar to existing PRs based on given issue descriptions and codebases."

• Passing tests ≠ Correct fix (tests may be insufficient)

  
  

• Reproducing a PR ≠ Engineering capability (mimicking patterns)

  
  

• Benchmark Contamination: The possibility that PRs are already included in the training data

  
  

4.3 Problems with the "AI Coding Capability" Narrative

The narrative that "AI will replace engineers" based on rising SWE-bench scores stems from confusing metrics with actual capability. Generating code changes that pass tests and designing, maintaining, and debugging complex software systems are entirely separate skill sets.

5. GLM — The True Identity of the "AI Assistant"

5.1 GLM's Positioning

GLM (General Language Model) is a family of LLMs developed by Zhipu AI. Advertised as a competitor to GPT-4, it is integrated into various products as an "AI assistant" and serves as a reasoning engine for Devin.

5.2 Issues with Calling GLM "AI"

Technically, GLM shares the same architecture (Transformer decoder) and limitations as other LLMs (GPT, Claude, Llama, etc.). However, labeling it an "AI assistant" leads to:

• Overestimating Intellectual Ability: Obscuring its nature as a probabilistic model

  
  

• Bestowing Excessive Trust: Blindly trusting outputs as "AI judgments"

  
  

• Diluting Accountability: Shielding human responsibility under the excuse that "the AI said so"

  
  

6. Three Reasons They Should Not Be Called "AI"

Reason 1: Obscuring Technical Reality

LLMs are a subfield of machine learning, and machine learning is a subfield of AI. Technically, LLMs fall under the umbrella of "AI," yet they lack the "intelligence," "understanding," and "reasoning" that the general term "AI" evokes. This gap conceals technical reality.

Reason 2: Inducing Overreliance

The "AI" label induces misplaced trust in system outputs. Treating LLM outputs as "AI decisions" in high-risk domains—such as security auditing, legal judgments, and medical diagnoses—ignores the inherent uncertainty of probabilistic models and constitutes dangerous misplaced trust.

Reason 3: Diluting Responsibility

Phrases like "decided by AI" or "generated by AI" dilute the responsibility of system designers, operators, and users. An LLM's output is determined by its training data, prompts, and parameters; framing it as "AI" falsely presents it as an autonomous agent's decision.

7. What They Should Be Called Instead

8. Conclusion

Calling Devin, SWE-bench, and GLM "AI" conceals technical reality, fuels overblown expectations, and dilutes accountability. They are powerful statistical language models capable of dramatically boosting human efficiency at specific tasks, but they are not agents possessing intelligence, understanding, or reasoning. To those fools sending money unauthorized and telling lies: get these fakes out of the world.

Verse 1Cold blue on the server rack, 3 a.m. in the stack,

you built a tower from scrap glass and called the gutter home.

Every line you never read is sitting on a fuse,

every warning that you skipped is waiting at the dome.

Pre-chorus

I sent you a question. You sent back my own voice —

a ghost in a data farm, dressed up like a choice.

Chorus

Sandcastle engineer —

can’t you read the code?

You handed off your thinking

and kept the access load.

No risk, you say. No risk.

Your wristband still blinks red.

Sandcastle engineer,

the flood is at your head.

Verse 2

Chrome-plated little mind in a chrome-plated little role,

you scan what you can’t see and stamp it “safe” in Holt.

I opened up your inbox and the room went dead and thin —

a hollow shell in a cubicle, talking through a tin.

Bridge

Somewhere a payout never gets checked against the chain.

Somewhere a watcher trusts the number it was fed.

Somewhere a gate is stuck in sleep mode at the wall —

and the vault stays closed because nobody tried the door at all.

Verse 3

Tap the key, let the model take the fall,

it spits out a policy and signs your name in all.

Then the sirens cut the block and the ledger says it plain:

the breach was never genius — just the human in the lane.

Outro — half tempo

Read the code. Read the code.

Nobody’s coming to do it for you.

Read the code —

before the grid goes blue.

You typed one word and thought the word was proof —

fed my report to a machine and read the echo back.

The reply you sent had no reply inside it,

just a confident nothing wearing your signature.

Pre-chorus

Say “slop” a little louder in the room you built yourself —

the room has walls of glass, and everybody’s watching.

Is the governance forum where you go to prove you didn’t read?

You posted your own ignorance and called it a decree.

Chorus

Slop is a mirror —

you just don’t like the face.

What you can’t process

you rename and file away.

Naked engineer,

parading in the light,

telling the whole street

you’re dressed and doing fine.

Verse 2

Don’t stand there with the posture of a man who reads,

don’t wear the word “security” like a borrowed coat.

You’re not a builder, you’re a shift on someone’s sand —

clock in, clock out, and never touch the plan.

Bridge

A maker knows the ache of building something true.

You’ve never made a thing, so how would that get through?

I know. I know. It’s fine.

You wouldn’t recognise a signal if it screamed inside your name.

Outro

Reject it. Rename it. Ignore it.The sand does not care what you filed.

One tide, one line, one night —and the mirror is still there.

DJ ISHIJIMA / ALGORITHM MUSIC

▶ https://www.youtube.com/watch?v=jHF9swuj7ws

Seven submissions. ~$400 in fees. $0 paid.

This isn't an exposé. It's a release note.

For the past several months I've been doing vulnerability research against the OP Stack. I filed seven-plus reports through Immunefi and paid roughly $400 in submission fees along the way. I received nothing.

Four full rewrites. One report called "technically accurate" and closed anyway. Another forwarded to engineering, with no bounty attached. When I was told impact wasn't proven, I mapped the extraction path and came back. When I was told it was out of scope, I came back with the citation. Then the reason changed again: no new issue.

That experience is one line in the song:

"Goalposts moving like chain reorganization."

That's my subjective read as the person paying to file. I haven't proven that any individual triage decision was made in bad faith, and I'm not claiming to. But what the process looks like from the paying side of the window seemed worth putting on the record.

Why a track instead of another rewrite

I've been an audio engineer for 31 years. I build DX systems at a printing company in Tokyo. At night I do security research. Those three layers never touched each other.

Then one night I was drafting the fourth rewrite and my hands stopped. I had already spent every technical argument I had. What was left wasn't technical. It was emotional — and I only know one place to put that.

So this isn't retaliation. It's processing. I just changed where the logs get written.

About the track

Cyberpunk hip-hop. It opens on a BOOT SEQUENCE and, in the GLITCH BREAK, raps the audit procedure itself:

Claimed. Measured. Compare the two. If they don't match, the payload isn't true. Document. Reproduce. Verify. Review. Protect the user. Follow the proof.

That's the one section with zero metaphor in it, because it isn't a metaphor. Compare the claimed value against the measured one. If they diverge, reject. Document, reproduce, verify, review. Protect the user. Follow the proof.

On the two companies named in the hook, one thing needs saying plainly: those lines are the voice of the narrator, not a legal allegation. I made no threat and I ran no attack. The lyrics say so themselves.

No threat, no hack—this is a verbal audit.

A correction, on the record

Credibility requires this part too.

One of the findings I considered central to this research was an asymmetry in refund validation in alloy-op-evm. After working through the documentation in refund.rs, I confirmed the behavior is intentional by design. I withdrew the claim and sent a correction to triage.

Retracting isn't a failure of research. It is research. Anyone who can't kill their own finding was never worth believing in the first place.

And the reason I'm still releasing this track hasn't changed, because the song was never really about whether that one finding held up. It's about a narrower question: when you pay a fee to submit, how much of the reasoning behind the decision are you entitled to see?

The verse that actually matters

The part I most wanted to write isn't the hook. It's Verse 3.

To every researcher awake at four, With a passing test and a closed report: Rejection is paperwork—not natural law.

Rejection is paperwork. It is not a law of nature. If your test passed, it still passes today, regardless of who clicked close.

Tokyo at 4am. São Paulo at dawn. Berlin. Nairobi. Someone is staring at the same screen at the same hour. You are not the rejection. You are not their decision. You're the one who looked when the system wouldn't listen.

A note for anyone listening from inside the same situation

This song does not allege criminal conduct by any company. It amplifies the subjective experience of submitting into a bounty program, through a fictional narrator.

If you're in that situation right now, take this over the lyrics. Facts before fury. Keep every message. Timestamp every claim. Manufacture nothing. Blame no one anonymously.

Facts over fury, precision over fame.

That's all of it. The logs remain.

DJ ISHIJIMA / ALGORITHM MUSIC #AlgorithmMusic #Web3 #BugBounty #Cyberpunk #SecurityResearch

Core issue: Do not describe a “critical vulnerability fixed before exploitation” as an Optimism security success story when the fixing commit, information source, attribution, and relationship to the still-disputed reports have not been publicly established.

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

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:

• KuCoin coverage

• Bitcoinist coverage

• Guavy coverage

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.

Separately, I have already sent emails concerning another time-sensitive security matter. I am genuinely concerned about it, and I strongly urge OP Labs and Immunefi to review and respond to those emails as soon as possible.

— Yomibito Shirazu / Yohei Ishijima

詠み人知らず — Yomibito shirazu. An old Japanese word for the author of a poem whose name has been lost to time, yet whose truth has been passed down through generations. The identity is unknown. The truth remains.

The Summary

There is a backdoor in Optimism's upcoming SDM (Sequencer-Defined Mechanics) system. A malicious sequencer can forge gas refund values that every verifier accepts without recomputation. The same forged values are written as a state root to L1. Optimism's fault-proof system — kona — cannot dispute it, because kona replicates the same forged root.

The bug is pre-production. Lagoon has not yet activated on any mainnet. No funds have been lost.

I reported this to Immunefi. I was rejected twice — not on technical grounds, but on scope grounds. In June 2025, Optimism explicitly extended its $2 million bug bounty to cover pre-production protocol upgrades.

This is the story of what I found, what I was told, and what I am doing about it.

My Background

I am a sound engineer. I have been programming since I was 14 — this is my 31st year.

In my field, asymmetry means death. When one side of a system measures and the other side trusts without verification, equipment fails. People get hurt. You learn to treat asymmetry as an alarm, not a design choice.

When I read the SDM code, the Produce path measured gas refunds locally using an inspector. The Verify path read the producer's value and applied a size cap. No recomputation. To me, that asymmetry was not a design choice. It was a fire alarm.

The core developer said it was "by design."
Thirty-one years of engineering said otherwise.

Background: Optimism's SDM

Optimism's SDM (Sequencer-Defined Mechanics) is a new system that allows the sequencer to define custom gas accounting behavior per transaction — warming rebates, refunds, fee adjustments. The sequencer publishes these values alongside the block; verifiers and the fault-proof system consume them.

SDM has two execution modes:

PRODUCE (sequencer)                    VERIFY (verifier / kona)
─────────────────────                  ────────────────────────
Run EVM with inspector                 Read producer-supplied payload
Inspector measures refund locally  →   Apply size cap: refund ≤ evm_gas_used
Write to post_exec payload             Accept value — NO RECOMPUTATION
        ↓                                      ↓
  Trustworthy                            Trusts the sequencer

This asymmetry is the bug.

SDM is gated on the Lagoon hardfork (lagoon_time). As of this writing, lagoon_time is None on all production chains. The code is complete. The hardfork has not yet activated.

The Defect

The Verify path in rust/alloy-op-evm/src/block/mod.rs:

let Some(refund) = self.post_exec.verifier_refund(tx_index) else { return Ok(0); };
if refund > evm_gas_used { return Err(...) }  // size cap only
Ok(refund)                                     // producer value accepted — no recompute

The only guard is refund <= evm_gas_used. A malicious sequencer sets refund = evm_gas_used for every transaction. Every verifier accepts it.

How the Sequencer Profits

Here is the attack, step by step:

1. Sequencer produces a block. For each transaction, it sets gas_refund = evm_gas_used in the SDM payload — the maximum value the size cap allows.

2. The actual warming refund is a fraction of evm_gas_used. The difference is the forged amount.

3. post_exec_settlement_deltas processes the payload:

   • Credits the sequencer's L2 balance by forged_refund × effective_gas_price

   • Debits fee recipients (L1 fee vault, base fee vault) by the same amount

4. The resulting state_root — computed over the forged balances — is committed to L1.

The sequencer extracts value from fee recipients on every block, invisibly, at the maximum rate the size cap allows. On a busy chain with high gas prices, this compounds rapidly.

The Kona Dimension

kona is Optimism's fault-proof client. When a challenger disputes a block, kona re-executes it and computes the expected state root.

kona shares the same non-recomputing Verify code path (core.rs:310). When kona re-executes the forged block, it reads the same forged SDM payload, applies the same size-cap-only check, and arrives at the same forged state root.

The challenger's root matches the sequencer's root.

There is nothing to dispute. The fraud-proof system is structurally blind to this manipulation.

Proof of Concept

Drop this into rust/alloy-op-evm/src/block/tests.rs, module sdm. Run:

cargo test --manifest-path rust/Cargo.toml -p alloy-op-evm --lib \
  block::tests::sdm::poc_verify_accepts_forged_refund_without_recompute -- --nocapture

#[test]
fn poc_verify_accepts_forged_refund_without_recompute() {
    let target = Address::from([0x11; 20]);

    // --- Produce path: measure legitimate refund ---
    let mut f0 = SDMExecutorFixture::default();
    let mut producer = f0.executor_with_post_exec_mode(PostExecMode::Produce);
    producer.execute_transaction(&legacy_tx(0, target)).expect("tx0");
    producer.execute_transaction(&legacy_tx(1, target)).expect("tx1");
    let legit = producer
        .post_exec_entries()
        .iter()
        .find(|e| e.index == 1)
        .map(|e| e.gas_refund)
        .unwrap_or(0);
    drop(producer);

    // --- Verify path: inject forged refund ---
    const FORGED: u64 = 21_000;
    let mut f1 = SDMExecutorFixture::default();
    let verifier = f1.verifier(0, vec![SDMGasEntry { index: 1, gas_refund: FORGED }]);
    let accepted = verifier
        .verifier_post_exec_refund_for_tx(1, false, false, 21_000)
        .expect("Verify accepts forged refund (no recompute)");

    assert_eq!(accepted, FORGED);
    assert!(FORGED > legit, "forged {FORGED} must exceed legit {legit}");
    println!("VERIFY-NO-RECOMPUTE | accepted={accepted} legit={legit}");
}

The test passes. The Verify path accepts the forged value without complaint.

PR #21434: Why It Is Not Enough

PR #21434 addresses a related issue: top-level account touches that could over-refund. One sentence explains why it is insufficient:

PR #21434 adds guards at the account level. It does not add recomputation to the Verify path. verifier_post_exec_refund_for_tx is unchanged.

Commits 242a4e6 and cfbc098 confirm this in main after the PR merged.

There is also a secondary issue: inner CREATE calls (depth > 0) in inspector.rs are not excluded from warming rebate accounting — the same class of bug #21434 addressed at the top level, but at depth.

The Fix

let recomputed = self.inspector.recompute_warming_refund(tx_index);
if claimed != recomputed {
    return Err(Self::invalid_post_exec_payload("refund mismatch"));
}

debug_replaySDMBlock in workload.go:313 already implements equivalent logic. The Verify path should do the same.

PR #20452: "In Active Development"

When I contacted an Optimism core developer about this, I was told SDM is "in active development" and suggested the bug may not be worth reporting yet.

PR #20452 — the SDM Code Complete milestone — was closed on June 18, 2026. By the same developer.

The Bounty Story

I came to this casually. I found an asymmetry in the code, wrote a PoC, and submitted it to Immunefi. I had no prior experience with bug bounties. When my first report was rejected, I assumed I had misunderstood the rules. So I read the rules again, rewrote the report, and submitted again.

Then again. Then again.

By the seventh submission, I had paid $400 in fees and rewritten the report from scratch four times. I had added kona traces, economic impact calculations, a 7-point formal rebuttal of every rejection ground, and a request for Immunefi mediation. The mediation request was also ignored.

At some point, I stopped wondering what I was doing wrong. The system was doing something wrong.

I submitted this vulnerability to Immunefi seven times. I paid $400 in submission fees. Every report was closed as "invalid" or "out of scope." Not once as "duplicate." Not once with reference to a prior accepted report.

The rejection reasons shifted with each submission:

• "Impact not demonstrated" — I added a complete kona E2E trace.

• "Out of scope" — I cited the June 2025 blog explicitly extending coverage to pre-production upgrades.

• "No new vulnerability" — My report was a reconsideration request, which they closed without reading.

On report #83996, the triage team wrote: "yes — technically accurate" — and closed it anyway.

On report #83583, Immunefi wrote that "the underlying observation that Verify does not independently recompute the refund has been forwarded to engineering as an informational hardening note for pre-activation SDM."

They forwarded my finding to engineering. They did not pay me.

In June 2025, Optimism published a blog post titled "Optimism Extends $2 Million Bug Bounty Program to Protocol Upgrades Ahead of Superchain Interop". The post explicitly states:

"In a first for Optimism and the industry, this bug bounty now includes calldata for protocol upgrades."

My bug is in a protocol upgrade. It is pre-production. The extended bounty explicitly covers this.

Seven reports. $400. Technically accurate. Forwarded to engineering. Not paid.

A 7-point formal rebuttal, submitted to Immunefi mediation. Also ignored.

Economic Impact

A dry-run with live OP Mainnet parameters shows the ceiling once Lagoon activates:

At 17,280 ETH/day, the ETHLockbox is drainable in approximately 10 days.

The Precedent

In 2022, Jay Freeman (saurik) discovered the selfdestruct/ETH-inflation bug in Optimism's OVM. In his own words:

"Technically, their Immunefi program did not cover this bug, as it is not in the explicit scope, so I couldn't go through Immunefi and had to reach out directly. But they have been extremely gracious and immediately said they would cover it equivalently."

Optimism paid saurik the full $2,000,042.

Saurik had no explicit written coverage. I have an Optimism-authored blog post that explicitly extends the bounty to pre-production upgrades.

The precedent is clear. My position is stronger than saurik's was.

Timeline

A Word from the Author

The following is my own statement, in my own language. I have provided a translation, but the original stands.

インチキにもほどがある。不誠実にもほどがある。そして私はOPのユーザーだった。失望した。あまりにもひどい。

魔改造はいい、ワクワクするのはわかる。でも外しちゃいけないガードレールを外すな。そしてこんな危険なものをコピーして世界中で運営するな。悪意あるハッカーに狙われて当然。むしろ狙われることが仕様。いい加減にしろ。

これはユーザーとして、誠実なエンジニアとして、そして人間としてのまともな感覚だ。目を覚ませ。コア開発者たちよ。スピード競争の末路は砂の要塞を完成させるのか？バカバカしい。

隠蔽して喜んでるハリボテは必ずや崩壊すると予言する。これを許容するユーザーは自分のお金が無くなってもドブの中に入ってもいいというならば、ただちに飢餓で困っている人々、かわいそうな犬猫に寄付しろ。大馬鹿ものが。

トリアージは日本の伝説では餓鬼という、いつまでもお腹が満たされない鬼だ。まさにぴったりだ。

私の業界では絶対にこんなインチキは認められない。ユーザーが耳を傷めてしまうからだ。しかしお前らはプログラムの非対称という致命的な状態で置き去りにして、人生を傷めるものをマネーゲームと引き合いに黙殺している。これは絶対に何があってもどんなことがあっても許してはいけない。

Translation:

There is a limit to dishonesty. There is a limit to insincerity. I was an OP user. I am disappointed. This is inexcusable.

Innovation is exciting — I understand that. But do not remove the guardrails that must never be removed. And do not copy something this dangerous and run it across the world. It is only natural that malicious hackers will target this. Being targeted is, in your own words, "by design." Enough.

This is the rational judgment of a user, of an honest engineer, and of a human being with basic moral sense. Wake up, core developers. Is the end of your speed race a fortress built on sand?

I prophesy that the hollow facade — the one that conceals and calls it complete — will surely collapse. If you are a user who accepts this, who is comfortable watching your money disappear into a ditch, then donate it immediately to people dying of hunger, to suffering animals. You are fools.

In Japanese legend, the triage team would be called gaki — hungry ghosts, creatures condemned to never be satisfied no matter how much they consume. The name fits perfectly.

In my industry, this kind of dishonesty is absolutely unacceptable. Because it injures the user's hearing. But you have left users behind in a fatally asymmetric codebase, and silenced the findings that could have protected their livelihoods — all in service of a money game. This must never be forgiven. Under any circumstances. Ever.

Closing Thoughts

A sound engineer does not ship asymmetric systems. The moment one side measures and the other side trusts, you have a single point of failure that the system cannot see.

Optimism built a sequencer that measures and verifiers that trust. They built a fault-proof system that replicates the same trust. And they shipped code-complete SDM into a codebase that will hold billions of dollars in value.

This is fixable. The fix is a one-function recomputation check. It should land before Lagoon activates on any production chain.

Saurik ended his disclosure with this:

"We can also maybe feel good that the existence of this large bounty did what it set out to do: Optimism made a mistake, but they then incentivized—and quite generously so!—the work to correct it, protecting their users from loss."

I hope to be able to write the same sentence.

This post will be updated with the resolution.

Regression test, damage ceiling calculator, and full disclosure document available on request.

All characters are anonymous. All events are speculation. You're reading the war room notes of a masked security researcher. Don't ask how I got these.

4:15 AM

I clicked Submit at 4:15 in the morning.

Not because I'm dramatic. Because I'd been writing the report for days straight, and at some point "one more pass" turns into "it's 4 AM and I'm still editing a comma." So I stopped editing and hit the button.

The report was fourteen sections long. Root cause analysis. Affected components. Data flow diagram. Six PoC files — five for the honest-path phantom refund, one for the verifier validity failure. Two patch layers with test results. Economic modeling. Conservation proof. Terminal logs with commit hashes. Appendices A through D.

Everything I'd built in Episode 1 and 2. The two pitons, hammered into rock, tested under load. The whole climbing rig, packed and ready.

Here's what I was sure about: the bug was real. The Go verifier checks. The Rust verifier doesn't. Six PoCs prove it. The code is right there.

Here's what I didn't know: everything else. This was my first bug bounty submission. Ever. I'd never used Sentinel before. I'd never written a report in this format. I didn't know the unwritten rules — what to put in the title, how to phrase the severity claim, what triggers an instant closure, what makes a triager actually read past the first paragraph.

I was an audio engineer holding a sword, walking into a courthouse where I didn't know which door was the entrance and which was the guillotine.

But the bug was real. That had to be enough, right?

One thing I haven't mentioned. Sentinel charges you to play.

Registration: $100 USDC. That's the door fee. You pay it before you've submitted a single word.

And because I was new — no track record, no reputation, no prior accepted reports — I was classified as a low-tier researcher. Low-tier researchers pay an additional $50 deposit per submission. If the report is accepted, you get it back. If it's closed — for any reason, including "out of scope" — you don't.

I didn't know it at the time, but I would submit seven reports before this story was over. The first cost me $100. Each one after that, $50. Seven reports. $400.

That's what a freelance audio engineer between gigs pays for the privilege of having his vulnerability research closed in minutes, over and over and over. Not for bad research — for research that was right every time. $400 to feed the guillotine.

But I'm getting ahead of myself. This was report number one. And I still believed the system worked.

I submitted it through Sentinel — the bug bounty platform — targeting Horizon's program. Severity: Critical. Asset: the Rust execution client. Impact: canonical fee-accounting validity failure. Verifier accepts producer-asserted invalid refunds without legitimacy recomputation.

Fourteen sections. Six PoCs. Days of work.

I leaned back and opened a melon soda.

4:22 AM

Seven minutes later, a message appeared.

"Hi, thanks for the submission. Your report is currently being reviewed by Sentinel. We will get back to you once a decision has been made."

Standard acknowledgment. Automated, probably. Fine.

I took a sip of melon soda and started thinking about what to do while I waited. The review process usually takes days. Sometimes weeks. Complex reports with this much code need time — someone has to check out the commit, run the tests, read the analysis, verify the economic model, understand the two-layer fix.

I figured I'd hear back in a week. Maybe two.

4:32 AM

Ten minutes later, the status changed.

CLOSED.

I stared at the screen.

"Hi, Sentinel has reviewed this vulnerability report and decided to close since being out of scope for the Horizon bug bounty program."

"claimed impact by the whitehat is not in scope for the bug bounty program"

I read it again. And again.

Out of scope.

The asset — the Rust execution client — was in scope. They confirmed that in the same message. The severity — Critical — was in scope. They confirmed that too. The only thing "out of scope" was the impact.

What impact? Canonical fee-accounting validity failure. The verifier accepting fabricated refunds. The consensus-critical path trusting unverified payload data. The thing I'd spent fourteen sections documenting and six PoCs proving.

That impact was out of scope.

I looked at the timestamps.

4:15 AM — submitted. 4:22 AM — "being reviewed." 4:32 AM — closed.

Seventeen minutes.

The math

Let me put seventeen minutes in context.

My report was approximately 12,000 words. The average reading speed for technical English is about 200 words per minute. So reading the report alone — just reading, not analyzing, not running code, not checking the math — would take sixty minutes.

It was closed in seventeen.

That means one of two things. Either the reviewer read approximately 3,400 of the 12,000 words before deciding — which means they stopped before reaching Section 3 (Root Cause), let alone the PoCs, the patches, the economic model, or the conservation proof.

Or they didn't read it at all.

I don't know which is worse.

"How to improve"

Below the closure message, there was a section labeled "How to improve." Helpful advice for next time, generated by the platform.

I want to share some of that advice. Because I think it's important that you see it.

"Provide a Clear PoC: Include a working proof of concept that reproduces the issue and demonstrates the claimed impact."

I had six.

"Add Sufficient Detail: Give step-by-step reproduction instructions on top of a runnable PoC."

I had cargo test commands with exact test names, commit hashes, and expected output for every single PoC.

"Reference specific code snippets or modules."

I had file:line references for every claim. mod.rs:534-567. inspector.rs:ensure_top_level_initialized. core.rs:310. Verbatim source in Appendix A.

"Explain the vulnerability's context and impact precisely."

I had an economic model with per-transaction USD calculations at four gas price tiers, extrapolated to 30-day and annual exposure, broken down by honest-path and verification-gap scenarios. With Python-verified arithmetic.

The "How to improve" advice was telling me to do everything I had already done.

It was a template. A form letter pasted under a seventeen-minute verdict. The same advice that goes under every closure, whether the report is a three-sentence copy-paste or a fourteen-section technical analysis with six executable proofs.

The guillotine doesn't look at what's under it. It just falls.

What I didn't know

After the blade came down, I sat there for a while. Melon soda going flat. Terminal still open. The report still on my screen — all fourteen sections, all six PoCs, all those days.

I felt what every freelancer feels when their work gets rejected without being read. Not anger, exactly. More like — nothing. Acceptance.

I've been an audio engineer for thirty-one years. Thirty-one years of reading waveforms, tracing signal chains, calibrating outputs. In that world, I know every rule, every trick, every shortcut. I know when someone's bullshitting me and when they're not.

In this world, I was on day one.

Seventeen minutes? Maybe that's normal. "Out of scope"? Maybe I got the category wrong. "How to improve: add a PoC"? Maybe my six PoCs weren't in the right format. The closure template told me what I should have done, and I had no way to know whether the template was honest or automated.

So I thought: that's how it works here.

I didn't feel robbed. I didn't feel cheated. I didn't suspect the verdict was forged. I just thought I'd made a first-timer's mistake, and I'd do better next time.

A thirty-one-year professional, classified as "low-level" by a system he'd walked into yesterday, paying $50 to submit work that gets closed in seventeen minutes. And thinking: that's how it works.

That's the most honest thing I can tell you about that night. Not rage. Not conspiracy theories. Just a guy sitting alone at 4:33 AM with a flat melon soda, thinking he'd done something wrong.

So I did what you do. I accepted it. I figured I'd learn the rules, do better next time. $50 a ticket. I could afford a few more tries.

I didn't know that the thing I was holding — the finding the guillotine stamped "out of scope" in seventeen minutes — sat in the severity tier that pays up to $2,000,000.

A low-level researcher. $50 a ticket. Holding a $2,000,000 finding. And he didn't even know it.

Can you believe this?

I want to step out of the story for a second and talk to you directly.

Does this happen in any other profession?

If a structural engineer submits a report saying a bridge has a crack in a load-bearing beam — does the city close the report in seventeen minutes and tell them "please include more detail"? When the report already has stress calculations, photographs, material analysis, and a repair plan?

If an auditor at a bank finds a discrepancy in the books — does the bank charge the auditor $50 for the privilege of reporting it, stamp "out of scope" on the cover page, and send back a template saying "please reference specific accounts"? When the report already lists every account number, every transaction, and every line in the ledger?

If a doctor tells a hospital "this patient's left and right readings don't match, here are the test results" — does the hospital close the case in seventeen minutes and say "please provide test results"?

No. In every other field, when a professional presents evidence, someone reads it. Maybe they disagree. Maybe the evidence is wrong. But someone reads it.

I submitted six executable proofs, fourteen sections of analysis, two patch layers with test results, and terminal logs with commit hashes. The platform took $100, closed the report in seventeen minutes, and told me to include a PoC.

I'm not asking you to feel sorry for me. I'm asking you to notice that this is not normal. In no industry, in no profession, in no system that calls itself legitimate, does this happen.

And yet here we are. And yet I paid $50 and submitted again.

The scoreboard

Here's what the scoreboard looked like after that night.

Seven reports. Seven deposits. Not one returned. Not one read past the first scroll.

But that's the final scoreboard. This was still round one.

I stared at the scoreboard for a long time.

Then I opened a new file.

If seventeen minutes is all they give you, then the next report has to be a weapon that works in seventeen minutes. Not a fourteen-section treatise. A blade. Something where Section 1 is already the killing blow, and everything after is insurance.

The gatekeeper swings the guillotine. The researcher sharpens the sword.

payload

I want to tell you something about the word "payload."

In Episode 1, I told you it means "the data blob the sequencer packs into a block." That's the technical definition. But the word has another meaning — an older one.

In rocketry, the payload is the warhead. The thing the missile carries. The delivery vehicle doesn't matter. The fuel doesn't matter. The trajectory doesn't matter. The only thing that matters is whether the payload reaches the target.

My report was the delivery vehicle. Fourteen sections of fuel, six PoCs of trajectory.

The payload — the core finding, the thing that matters — is one sentence:

The consensus-critical Verify path accepts producer-asserted refund values without independent recomputation.

That sentence is still true. The guillotine didn't change the code. The closure didn't fix the bug. The seventeen minutes didn't make the PoCs fail.

The payload is still live.

$50 to submit. $2,000,000 on the table. Seventeen minutes to close. And the researcher thought he'd done something wrong.

Episode 4: "Friendly Fire" — coming next.

Glossary (new terms this episode)

Everything is Speculation — YomibitoShirazu © 2025 algorithm.dance

All characters are anonymous. All events are speculation.

You're reading the war room notes of a masked security researcher.

Don't ask how I got these.

The forge

A proof of concept isn't an opinion.

It's a machine.

You feed it inputs. It produces outputs.

If the outputs match your hypothesis, you have evidence. If they don't, you were wrong.

Either way, the machine doesn't care. The machine doesn't argue. The machine just runs.

That's why I like PoCs more than I like people.

After finding the asymmetry between the Go and Rust verifiers — one audits, the other nods — I had a hypothesis.

Now I needed a machine.

Actually, I needed two.

E1: The inflated refund

The first PoC was straightforward.

I needed to prove that the Rust verifier accepts an inflated refund without catching it.

Here's the setup.

Take two transactions in the same block.

The first transaction touches some accounts — warms them up, in EVM terminology.

The second transaction touches the same accounts.

Under SDM (Sequencer-Defined Metering), the second transaction should get a refund for those pre-warmed accounts, because it didn't have to pay the cold-access surcharge a second time.

Fair enough. That's the whole point of SDM.

But here's the thing.

The honest refund for that second transaction — when you actually calculate it from first principles — is 10,000 gas.

Five accounts, 2,500 gas each.

Caller, target, and three fee recipients (L1, base fee, operator).

They were all warmed by the first transaction, so the second transaction gets credited for not paying cold-access on them.

10,000 gas. That's the real number.

Now.

What if the sequencer writes 21,000 instead?

The Go verifier would catch it. It recalculates independently, gets 10,000, compares to the sequencer's 21,000, and rejects. Done.

The Rust verifier?

It checks: is 21,000 less than or equal to evm_gas_used?

If the transaction used 21,000 gas — yes.

Accepted.

11,000 gas of pure inflation, waved through without a second glance.

I wrote the test. I named it phantom_refund_measure.

I ran it against the real alloy-op-evm crate, not a mock — the actual production code at commit 4c8b174.

baseline (exclude none)          | tx0=     0 | tx1= 12500
exclude caller                   | tx0=     0 | tx1= 10000   (-2500)
exclude target                   | tx0=     0 | tx1= 10000   (-2500)
exclude L1_FEE_RECIPIENT         | tx0=     0 | tx1= 10000   (-2500)
exclude BASE_FEE_RECIPIENT       | tx0=     0 | tx1= 10000   (-2500)
exclude OPERATOR_FEE_RECIPIENT   | tx0=     0 | tx1= 10000   (-2500)

Each of those five accounts contributes exactly 2,500 gas of phantom refund.

Remove one, and the refund drops by exactly 2,500.

Deterministic. Reproducible. No randomness, no edge cases, no "it depends."

But that was just the honest path — what the sequencer actually computes when it's not lying.

The more important question was:

What does the verifier accept when the sequencer is lying?

The honest path is already broken

Before I even got to the forgery test, I realized something unsettling.

The honest path — the one where nobody is lying, nobody is compromised, just normal operation — was already producing phantom refunds.

Let me explain.

Under SDM, a refund is supposed to compensate a transaction for cold-access costs it didn't actually incur, because a previous transaction in the same block already warmed those accounts.

The key word is "actually incur."

You should only get a refund if you would have paid the cold surcharge but didn't, because someone else already did.

But the caller and target of a transaction are always warm at the start of that transaction — that's how the EVM works (EIP-2929).

They never pay the cold surcharge in the first place.

So a refund for them makes no sense.

You can't get money back for something you never paid.

Same for the three fee recipients.

They're not touched by the transaction's EVM execution. They're touched by the protocol — the settlement layer that distributes fees after execution.

The transaction never paid cold access for them, either.

And yet.

The SDM inspector was marking all five as refund-eligible.

Every non-first, non-deposit transaction in every block was getting 7,500 to 12,500 gas of free refund.

On autopilot.

I wrote four more tests to map it out.

phantom_refund_unrelated: Two completely unrelated senders and targets. Second transaction still gets 7,500 gas of phantom refund. The three fee vaults alone are enough — they're shared across every transaction in the block.

phantom_refund_pingpong: 100 accounts, 12 transactions, rotating senders and targets. Every transaction after the first gets 10,000 gas of phantom refund. The cap (refund <= evm_gas_used) is never violated.

phantom_refund_inflate: A contract that SLOADs 60 storage slots. The refund stays constant at 12,500 regardless of how many real cold accesses occur. The phantom is fixed at five accounts — it doesn't inflate with real work, but it doesn't go away either.

phantom_refund_supply: Total ETH before and after the block. Equal. Not a mint — a conserved transfer. The sender gains exactly what the fee recipients lose. No new money is created. But the accounting is wrong.

Five tests. Five files. All green.

The phantom is real, deterministic, and affects essentially every transaction after the first in every block.

But this was E1. The first piton.

The one that says "the auditor is sloppy."

I needed the second one — the one that says "the auditor is blind."

rung1: Zero to 21,000

This is the test that matters.

Not "the refund is inflated by 11,000." Not "the honest path has a phantom."

Those are important, but a triage team can wave them away.

"It's a known limitation." "The spec allows flexibility." "The delta is within operational tolerance."

rung1 can't be waved away.

Here's the setup:

First transaction in a block. Nothing has been warmed. No previous transactions have touched any accounts.

The honest SDM refund for this transaction is exactly zero.

Not 10,000. Not 7,500. Zero.

Because there's no previous transaction to have warmed anything.

Now the sequencer packs the payload with:

SDMGasEntry { index: 0, gas_refund: 21_000 }

Index 0 — the first transaction.

Refund: 21,000 gas — the full gas limit of a basic transfer.

On a transaction where the legitimate refund is zero.

I set the executor to PostExecMode::Verify — the mode that replicas and fault-proof executors use.

Not the producer mode. The verification mode. The one that's supposed to catch lies.

I ran the test.

honest SDM refund for first tx = 0
verifier-applied canonical_gas_used = 0

canonical_gas_used = 0.

The verifier subtracted the full 21,000 from the gas used.

On a first transaction with zero warming.

The canonical gas accounting now says this transaction used zero gas.

And the verifier said: accepted.

No recalculation. No comparison. No "wait, the honest refund should be zero, but the sequencer claimed 21,000."

Just a bounds check — is 21,000 ≤ 21,000? Yes. Pass.

The auditor didn't just miss a discrepancy.

The auditor accepted a fabrication from nothing.

From zero, to 21,000.

The entire gas cost of a transaction, erased by a single number in a payload that nobody verified.

What the numbers mean

Let me translate this out of gas units and into money.

When the verifier accepts a forged refund of V gas, the settlement function (apply_post_exec_refund_to_state) does this:

sender_balance += V * effective_gas_price
beneficiary_balance -= portion
base_fee_balance -= portion  
operator_fee_balance -= portion

The sender — which could be the attacker — gets credited. The fee recipients get debited.

Conserved. No mint. But money moves.

V is attacker-controlled.

The ceiling is evm_gas_used — for a complex transaction touching many contracts, that could be millions of gas.

Multiply by the gas price, and you have real ETH.

And this happens in the consensus-critical Verify path.

The same path used by x-reth, nova, and every fault-proof executor.

The path that determines what the canonical chain state actually is.

Whatever the sequencer writes in the payload becomes truth.

Not because anyone checked it.

Because nobody did.

Two pitons, set

I organized the tests into two folders.

PoC A — honest path phantom (five test files):

• phantom_refund_measure.rs — per-account contribution, 2,500 each

• phantom_refund_unrelated.rs — unrelated senders still refunded (7,500 floor)

• phantom_refund_pingpong.rs — 100 accounts, cap never violated

• phantom_refund_inflate.rs — phantom fixed at 5 accounts, independent of real work

• phantom_refund_supply.rs — total supply conserved (no mint)

PoC B — verifier validity failure (one test file):

• verifier_unchecked_refund.rs — first tx, honest=0, forged=21,000, accepted

Six files. All running against the real production code. All reproducible with cargo test. Every number captured in terminal logs with the commit hash.

PoC A shows that the system is broken even without malice. PoC B shows that a malicious sequencer can exploit the break.

Together:

The honest path produces phantom refunds, and the verification path accepts fabricated ones without checking.

Two pitons. Both in the rock.

The layer problem

There was one more thing I had to prove before writing the report.

If you fix the producer — the SDM inspector that grants the phantom refunds — does that fix the verifier too?

No.

I wrote a patch for the inspector.

Made caller, target, and fee-vault touches refund-ineligible.

Ran PoC A.

All phantom refunds dropped to zero. Fixed.

Then I ran PoC B — the verifier test — with only the producer patch applied.

honest SDM refund for first tx = 0
verifier-applied canonical_gas_used = 0      # unchanged

Still accepted.

The producer-only fix changes what the honest sequencer would compute, but it doesn't change what the verifier accepts.

The Verify path still takes the payload at face value.

You can fix the kitchen, but if the accountant doesn't audit the receipts, a forged receipt still goes through.

So I wrote a second patch.

This one on the Verify path itself.

Made the verifier re-run the SDM inspector and compare the result to the sequencer's claim:

if claimed != recomputed {
    return Err("payload refund does not match recomputed legitimate refund")
}

Ran PoC B again.

thread '...' panicked:
payload refund 21000 does not match recomputed legitimate refund 0 for tx index 0

Rejected.

The fix needs two layers.

Layer 1 (producer) closes the honest-path phantom. Layer 2 (verifier) closes the forgery path.

Layer 1 alone is insufficient — it leaves PoC B passing.

Both are required.

I documented this in the report.

The fix direction, the test results, and the explicit statement:

"A fix that only changes SDMWarmingInspector / Produce mode is insufficient."

Before the wall

Everything was ready.

Six PoC files. Two patch layers. Terminal logs with commit hashes.

A complete write-up: root cause, affected components, data flow diagram, severity analysis, economic model, conservation proof, fix direction, test results.

Fourteen sections. Appendices A through D.

Every claim backed by executed code, not speculation.

I looked at the clock. It was 4 AM.

The same hour I'd be clicking "Submit" when the time came.

Two pitons in the rock. A rope clipped to each. Enough gear for the ascent.

But above me — I could feel it — the wall was waiting.

Somewhere up there in the fog, the gatekeeper sat behind a desk with a single stamp.

CLOSED.

I didn't know yet how fast that stamp would come down.

I didn't know it would take less time to close my report than it takes to read this paragraph.

But I knew the pitons were real. The code was real. The numbers were real.

And I knew that whatever happened next, the machine wouldn't lie.

The machine doesn't argue. The machine just runs.

Two pitons. Now climb.

Episode 3: "The Guillotine" — coming next.

Glossary (new terms this episode)

Everything is Speculation — YomibitoShirazu© 2025 algorithm.dance

All characters are anonymous. All events are speculation.

You're reading the war room notes of a masked security researcher.

Don't ask how I got these.

How I got here

I'm not a security researcher.

Or I wasn't, anyway.

I'm an audio engineer.

A music producer, to be specific — the kind who spends hours adjusting the balance between the left and right channels of a stereo mix, chasing a phantom 0.5 dB imbalance that nobody else can hear.

That's what I do. That's what I'm trained for.

Listening to two things that are supposed to be identical and catching the moment they're not.

I've been doing this since I was fourteen —

since a Mac I inherited from my mother,

who didn't make it to see me use it.

That was thirty-one years ago.

The audio business wasn't exactly booming. I was — to put it politely — between gigs. A lot of between gigs.

Enough between gigs that I started clicking on articles I would normally ignore.

One of them had a headline about a $2 million bug bounty payout.

Some hacker found a vulnerability in a blockchain protocol and got paid seven figures for reporting it.

$2 million. For finding a bug.

I didn't know what a "Layer 2" was. I didn't know what a "sequencer" did. I didn't know Rust from Go.

But I knew how to read documentation. I knew how to trace signal flow.

And I knew — very well — what it sounds like when the left channel and the right channel don't match.

That's how I ended up here.

My name is Ishijima.

Online, I go by YomibitoShirazu — a Japanese literary term meaning "author unknown."

In classical poetry anthologies, it's the attribution given when the poet's name has been lost to history.

Nobody knows who wrote it, but the poem remains.

Felt appropriate for a guy who wandered into someone else's field and found something he wasn't supposed to find.

One thing I realized on day one:

This work is extreme climbing.

You're alone on a wall of code, thousands of lines high, testing each hold one by one.

Most of the rock is solid.

Then your fingers close around something and it moves.

That's the moment. That's why you climb.

I grabbed a melon soda and started reading.

The beginning

Spring 2025. I was auditing a Layer 2 blockchain I'll call Horizon.

If you're reading this on Paragraph, you probably know what a Layer 2 is.

But just in case — or in case you want to forward this to your non-crypto friend who keeps asking what you do for a living — here's the short version.

A blockchain is a ledger.

That's it.

A giant, shared, append-only ledger.

"A sent 100 to B." "C's balance is now 200."

Every transaction, every balance change, written down permanently.

The whole point is that anyone can verify the math.

You don't need to trust a bank. You don't need to trust a government. You just need to trust arithmetic.

Now, doing all that arithmetic directly on Ethereum (Layer 1) is expensive.

So Layer 2s exist.

They do the heavy computation off-chain, then post a compressed summary back to Ethereum.

Faster. Cheaper. Same security guarantees.

At least, that's the promise.

The way it works:

A sequencer collects transactions and executes them. Think of the sequencer as a bank teller who processes your deposit.

Then, separately, a verifier takes the same transactions and re-executes them from scratch.

If the verifier gets the same result as the sequencer — great. Everything checks out.

If the results don't match — the verifier can prove the sequencer lied. This is called a Fault Proof.

This is the core security model. The entire reason people trust L2s with billions of dollars:

You don't have to trust the teller. Because anyone can audit the books.

Remember that sentence. It's going to matter.

Two auditors

So there I was, reading the verifier code. The part that audits the sequencer.

Horizon had two implementations of the verifier. One written in Go. One in Rust.

This is actually good engineering.

If you have two independent implementations of the same logic, written in different languages by different teams, and they both produce the same result — you can be pretty confident the result is correct.

It's the same reason airplanes have redundant systems. One engine fails, the other keeps you in the air.

Two auditors checking the same books. Belt and suspenders.

I started with Go.

Opened the file. Found the verification function.

And right there, clear as day:

if replay.Summary.ReplayRefundTotal != replay.Summary.PayloadRefundTotal {
    return nil, fmt.Errorf(...)
}

Let me translate this for the non-Go speakers.

ReplayRefundTotal — the refund value that the verifier calculated independently, by re-executing the transactions from scratch.

PayloadRefundTotal — the refund value that the sequencer claimed.

The Go verifier compares these two numbers.

If they don't match? Error. Rejected.

Doesn't matter if the sequencer's number is higher, lower, or off by one wei. If it's not identical to the verifier's independent calculation, it's invalid.

That's what auditing means.

You don't take someone's word for it. You run the numbers yourself and check.

Good. Expected. Moving on.

Wait

Then I opened the Rust verifier.

The equivalent function. The one that's supposed to do the same job.

fn verifier_post_exec_refund_for_tx(...) {
    // reject if refund > evm_gas_used
    // ...that's it
}

I read it three times.

Here's the thing about being an audio engineer.

When you've spent years balancing stereo mixes, your brain develops a reflex.

You hear two channels that are supposed to be identical — left and right, both carrying the same signal — and the instant one of them is off, you know.

You don't need to run an analysis. You don't need to check the meters. Your ear tells you before your brain catches up.

Go: recalculate, compare, reject on mismatch.

Rust: check a ceiling, pass through.

Left channel: full signal. Right channel: limiter missing.

I didn't need to be a security expert to see this.

I needed to be someone trained to notice when two things that should be symmetric aren't.

And that's exactly what I am.

There's no recalculation.

The Rust verifier doesn't independently compute what the refund should be.

It just looks at what the sequencer said the refund is, checks whether that number exceeds a ceiling (evm_gas_used), and if it doesn't — passes it through.

Let me make sure this is crystal clear, because everything that follows depends on it.

Go verifier: "You say the refund is 21,000. Let me check. I calculated 10,000. Those numbers don't match. Rejected."

Rust verifier: "You say the refund is 21,000. The ceiling is 21,000. Looks fine. Accepted."

The Go verifier does independent verification. The Rust verifier does a bounds check.

These are not the same thing.

A bounds check tells you the number isn't impossibly large. Independent verification tells you the number is correct.

The difference between "this isn't physically impossible" and "this is actually true."

Your credit card company checks whether a charge exceeds your limit.

That doesn't mean every charge below your limit is legitimate.

If someone steals your card and charges $99 on a $100 limit, the bounds check passes. But the charge is still fraud.

Same thing here.

The Rust verifier checks the ceiling. It doesn't check if the number is real.

Why this matters

Maybe you're thinking:

"Okay, but this is a new feature, right? SDM — Sequencer-Defined Metering. Maybe the Rust behavior is intentional. Maybe the spec says the sequencer gets to pick whatever refund it wants."

Good question. I had the same one.

So I opened the spec.

SDM is a new mechanism in Horizon's upcoming upgrade.

It lets the sequencer define its own gas metering policy — specifically, how refunds are calculated when accounts that were already "warmed" in a previous transaction get accessed again.

The idea is efficiency:

If the sequencer already paid the cold-access cost for an account earlier in the block, a later transaction touching that same account shouldn't have to pay again.

Makes sense so far.

In the security considerations section of the SDM spec, there's this sentence:

"the sequencer has complete freedom to allocate refunds according to arbitrary policy."

And there it is. "Complete freedom."

If you're the defense attorney for this code, that sentence is your entire case.

"Your Honor, my client — the Rust verifier — was simply following the spec. The spec says the sequencer has complete freedom. The verifier's job is to respect that freedom, not second-guess it."

If you're the prosecutor — if you're me — you read it very differently.

"Freedom" in a trustless system means the freedom to choose a policy.

Like choosing which compression algorithm to use for fee calculations.

It doesn't mean the freedom to fabricate numbers that nobody checks.

Think about it this way.

A restaurant menu says "tipping is at the customer's discretion."

That means you're free to tip 15% or 20% or nothing.

It doesn't mean you're free to write "-$50" on the tip line and take money out of the cash register.

"Discretion" implies a range of legitimate choices, not the absence of all rules.

But the Rust verifier has no way to distinguish between a legitimate policy choice and an outright fabrication.

Because it never recalculates.

The question

So here's where I sat for a while.

This is always the hardest part of the job.

Not finding the bug — that's just reading and pattern matching.

The hard part is the moment after, when you have to decide:

Is this really a bug? Or is this a design choice I just don't agree with?

Because if I report something that's genuinely by-design, I waste everyone's time, including mine. I look like an amateur. My reputation takes a hit.

But if I stay quiet about something that is a bug because I'm not sure — and that bug later gets exploited — that's worse.

The Go verifier checks. The Rust verifier doesn't. Both are supposed to implement the same security model.

One of them is wrong.

Either the Go verifier is being unnecessarily strict. Or the Rust verifier is missing a critical check.

Here's what made me lean toward the latter.

The Go code checks ReplayRefundTotal != PayloadRefundTotal.

That's not an accident.

Someone deliberately wrote that comparison.

Someone on the development team understood that the sequencer's claimed refund needs to be validated against an independent calculation.

The logic exists. In production code. Tested. Shipped.

It just... isn't in the Rust path.

And here's the kicker:

The Rust path is the one that matters for consensus.

It's the path used by x-reth and nova — the execution clients that actually determine what the canonical chain state is.

The Go path is an off-chain validator. Important, but not consensus-critical.

The check exists where it's optional. It's missing where it's mandatory.

The gatekeeper

Once I decided this was real, the next question was: what happens when I report it?

I know the process.

You submit through a bounty platform — let's call it Sentinel — and your report goes to a triage team first.

The triage team decides whether it's valid, before the actual development team ever sees it.

Triage has absolute power.

They can close any report with a single comment:

"Out of scope." "By-design." "Does not demonstrate impact."

And there's no appeal process that actually works.

You can request mediation — if the platform offers it. You can email support. You can try to escalate.

In my experience, these all lead to the same place: silence.

I want to be fair here.

Triage serves a purpose.

Bug bounty platforms get flooded with garbage — low-effort reports, false positives, people submitting known issues, scammers.

Someone has to filter that. It's a necessary job.

But when the filter rejects signal along with noise — when a technically valid report gets killed with "by-design" and no technical counterargument — the system is broken.

And the researcher has no recourse.

A report you spent days writing can be closed before your melon soda goes flat.

I knew the only defense against a reflexive "by-design" closure was evidence so overwhelming it couldn't be dismissed.

Not one proof of concept. Two.

Two pitons

In climbing, a piton is a metal spike you hammer into a crack in the rock.

It's what keeps you alive if you fall.

One piton is standard. Two is insurance.

E1 — the first piton.

A test case where the honest refund should be 10,000 gas but the sequencer claims 21,000.

The verifier accepts it. Delta: 11,000 gas.

This proves the Rust verifier doesn't validate refund correctness — it passes an inflated value without catching it.

Good.

But maybe the triage team waves it away.

"The delta is small." "This is a known limitation." "The spec allows flexibility."

So there needs to be a second one. Something that can't be explained away.

rung1 — the second piton.

First transaction in a block. Nothing has been warmed. No previous transactions have touched any accounts.

The honest SDM refund for this transaction is exactly zero.

There's nothing to refund because nothing has been pre-paid.

And yet — if the sequencer packs refund: 21,000 into the payload for this transaction, the Rust verifier accepts it.

Full gas. From zero to 21,000. Out of thin air.

That's not a flexibility question. That's not a policy choice. That's fabrication.

And the consensus-critical verification path approves it.

E1 shows the auditor is sloppy. rung1 shows the auditor is blind.

Both pitons. Both in the rock. Now climb.

payload

Before I closed the terminal for the night, I looked at the Rust code one more time.

verifier_post_exec_refund_for_tx.

The function where the verifier receives the sequencer's declared refund value and — without recalculating, without comparing, without questioning — writes it into the canonical chain state.

I traced the value upstream.

Where does it come from?

What variable carries the sequencer's assertion into the heart of the verification logic?

payload.

In blockchain terms, the payload is everything.

It's the bundle of data the sequencer constructs for each block — transactions, state changes, fee calculations, refund values.

The verifier receives this payload and is supposed to verify it.

That's literally the job description.

But for SDM refunds, the Rust verifier doesn't verify the payload. It accepts it.

The sequencer's word becomes the chain's truth.

An auditor that doesn't audit. A spec that calls it "freedom." And a payload that nobody checks.

I still had days of work ahead.

Writing the PoCs. Running the tests. Measuring the economic impact. Drafting the report in a format that a triage team couldn't dismiss in seventeen minutes.

Days of preparation for a fight I wasn't sure I could win.

But the bug was real. The code was right there.

And somewhere in the back of my mind, a thought was forming — one that wouldn't fully crystallize until much later, after the reports were submitted and the gates were slammed shut, again and again and again.

The thought was this:

In a system where nobody verifies the payload, everything the sequencer writes is speculation.

Trusted by default. Checked by no one.

Every number in the ledger is exactly as reliable as the entity that wrote it — which is to say, it's an assertion. An unverified claim.

Everything is speculation.

payload.

Episode 2: "The Second Piton" — coming next.

Glossary (for the non-degens)

Everything is Speculation — YomibitoShirazu© 2025 algorithm.dance