This is a joint post from Nomadic Labs, TriliTech & Functori.
This post discloses the vulnerabilities that prompted the last three fast track governance votes: Etherlink 7.0, 7.1 and 7.2, along with a technical description of each issue and how it was addressed. None of the vulnerabilities discussed below were exploited. They were uncovered either through our continuous internal audit efforts or as bug-bounty reports filed to the Tezos Foundation program. We’d like to thank the external security researchers who help us keep Etherlink secure, as well as the bakers who rallied to support our security upgrade proposals.
Etherlink 7.0
In addition to the larger feature set it brought to Etherlink Mainnet, Etherlink 7.0 (Ganesha) contained a security fix addressing a denial-of-service vulnerability in the kernel. More specifically, it was possible for an attacker to craft a malicious payload prompting the kernel to perform an abnormally complex and time-unbounded computation to decode it.
While the decoding algorithm in question was notoriously computationally intensive, legitimate inputs are actually quite small. The fix simply consists of hardening the decoding primitive by checking for the input size ahead of attempting any decoding operation: a payload that is larger than 150 bytes has no chance to be valid anyway.
Etherlink 7.1
On August 27, 2026, we received a bug-bounty report describing a critical vulnerability that, if exploited, could allow an attacker to mint tez. That vulnerability combined two flaws in the Etherlink 7.0 kernel:
-
If a transaction performing a cross-runtime call targeting the Michelson runtime runs out of gas while crossing the runtime boundary, the error is misclassified as an internal error. The policy of Etherlink in that case is to abort and reject the execution of the full block, to protect the safety of its ledger. This flaw gave an attacker the ability to disrupt block production. Submitting the same malicious transaction again and again can prevent the sequencer from producing a valid block.
-
Additionally, Etherlink 7.0 introduced various mechanisms to be more resilient to fault-inducing transactions, including two ways to remove malicious transactions from the delayed inbox without having to wait for the 12h flush. One of these mechanisms was particularly misguided: it consisted in “downcasting” an error supposed to abort the execution of a block into an error claiming that a transaction is invalid when the latter comes from the delayed inbox.
The kernel implementation relies heavily on the assumption that the context of Etherlink is reverted to a safe checkpoint when a block is aborted. Combining these two flaws, an attacker could send to the delayed inbox a poisonous transaction running out of gas while crossing the Michelson runtime boundary. The execution of this transaction would leave the Michelson runtime ledger in an inconsistent state: notably, the tez sent to the Michelson runtime would be credited to the recipient’s balance without being debited from the sender balance.
Etherlink 7.1 consisted in a series of patches (1) addressing the bugs motivating its proposal, and (2) hardening the kernel against similar attacks.
-
Patch the OutOfGas misqualification bug.
-
Patch similar error misqualification issues we uncovered after receiving the bug-bounty (here, and here).
-
Stop “downcasting” a block-aborting error when raised by a transaction sent via the delayed inbox; instead, we remove such a transaction from the delayed inbox when it is the only transaction contained in a block.
-
Harden the kernel to detect inconsistencies in the Michelson runtime ledger, and reject the block accordingly.
Lastly, as a precautionary measure, Etherlink 7.1 bumped the delayed inbox timeout from 12 hours to two weeks for a duration of three months. The delayed inbox plays an important role in the Etherlink security model, namely to prevent censorship by the sequencer. This property does not change with the extended timeout, and it remains possible to demonstrate when a sequencer is actively censoring a transaction by looking at the delayed inbox and seeing an item stuck there for more than a few minutes at most (most items are injected by Optimistic Labs in less than 30s). A misbehaving sequencer remains subjected to the Tezos L1 bakers, and should be voted out without a second thought.
Unfortunately, the delayed inbox has also proven to be a powerful tool for turning liveness vulnerabilities of Etherlink into safety threats. Indeed, it is a delivery channel that lets an attacker force the chain to process its attack payload. Preventing a forced inclusion of a transaction breaking the consistency of the Etherlink ledger for 2 weeks gives everyone more time to react accordingly, namely to propose a kernel upgrade nullifying the threat.
This three-month sunset is hardcoded into the kernel itself. We have no intention of extending it further without the explicit consent of the Tezos L1 bakers, and the extension is only here temporarily to give us more leeway while we harden the kernel. We’ll be publishing a follow-up article outlining the work we’re undertaking to strengthen confidence in kernel security over the coming months.
Etherlink 7.2
Etherlink 7.2 was a hardening release that addressed a family of issues where execution costs in the kernel were not always aligned with the amount of work or memory allocation triggered by a transaction. Some of these issues were reported through the bug bounty program and others were found by continued internal auditing and testing. In particular, several paths in the Michelson runtime and EVM precompiles could force nodes to read durable-storage blobs, perform cryptographic operations, or allocate memory before sufficient gas had been charged.
The common theme is denial-of-service resistance: making sure that every operation whose cost can grow with user controlled input is either bounded, charged before execution, or rejected safely. This matters especially for Etherlink because the delayed inbox can force transactions to be included. A liveness issue can therefore become more dangerous if an attacker can repeatedly force the chain to process an underpriced payload.
In addition to this we also reintroduced a mitigation for bounding base58 decoding payloads. Due to an operational error this patch was omitted from the Etherlink 7.1 kernel. Below is a list of all issues addressed.
Michelson durable-storage read metering
-
Charge Michelson blob reads before reading them: Fixes a DoS vector where contract code or storage could be read into memory before gas was charged.
-
Charge view script and storage reads: Ensures VIEW execution pays for reading the viewed contract’s code and storage.
-
Charge entrypoint-lookup code reads: Ensures the Michelson CONTRACT instruction pays for reading the target contract’s code.
Michelson runtime gas and memory-accounting fixes
-
Make alloc_cost use u64: Avoids architecture-dependent or overflow-prone allocation-cost accounting.
-
Consume at least allocation cost: Floors several MIR gas costs by the memory they allocate.
-
Price AND int/nat on the nat it allocates: Fixes an underpriced case where negative integers could produce large allocated naturals.
-
Charge SELF and PAIR n for boxed values: Fixes underpriced value boxing that could otherwise let memory grow faster than gas.
-
Floor map/set update costs by copied-path allocation: Fixes underpriced updates on shared maps/sets where tree-path copying allocates memory.
EVM precompile hardening
-
Optimize and reprice crypto precompiles: Makes ecrecover faster and re-prices undercharged crypto precompiles, notably ecrecover and ecPairing.
-
Memoize repriced precompiles per EVM spec: Fixes a cache bug that could return precompile tables for the wrong EVM spec.
Delayed inbox and journal hardening
- De-duplicate delayed transaction events: Avoids emitting duplicate events for transactions already present in the delayed inbox.
Input validation
- Reject too-long Base58Check payloads: Adds an input-size bound before base58 decoding to avoid expensive decoding of impossible payloads.
Keeping Etherlink Secure
Our thanks go out to the security experts contributing via the Tezos Foundation bug bounty program. If you are a security researcher, we strongly encourage you to look into Etherlink and other Tezos ecosystem projects. Submitting findings through the bug bounty program remains vital for ensuring the ongoing secure evolution of Etherlink alongside Tezos X.
