Announcing Etherlink 7.0 (Ganesha): a new Etherlink kernel upgrade proposal

This is a joint post from Nomadic Labs, TriliTech, and Functori.

A new Etherlink kernel upgrade proposal, Etherlink 7.0 (Ganesha), has just been submitted to Etherlink’s Slow governance mechanism.

This is a major feature upgrade proposal, bringing the Michelson interface and Native Atomic Composability to Etherlink, and laying the groundwork for Tezos X:

  • The Michelson interface — Michelson smart contracts and the Tezos account system come to Etherlink as first-class citizens. tz1, tz2 and tz3 implicit accounts are supported, along with Michelson contracts, which are Ligo- and SmartPy-compatible.

  • Native Atomic Composability (NAC) — accounts from either interface can interact with applications across the whole of Etherlink, atomically. Tezos accounts can own Etherlink’s native EVM-based assets, and EVM accounts can reach Michelson contracts, in both directions. This is implemented through two gateways: an EVM precompile contract at 0xfF00000000000000000000000000000000000007, and a Michelson native contract at KT18oDJJKXMKhfE1bSuAPGp92pYcwVDiqsPw.

  • RPC compatibility — the Octez EVM node now exposes a subset of octez-node RPCs, so existing Tezos indexers, wallets and dApps can interact with Etherlink’s Michelson interface as though it were another Tezos network, without requiring rewrites.

  • EVM interface fixes — tez deposits targeting a smart contract, or an EOA with EIP-7702 delegation, now execute the associated script, matching standard EVM semantics; and reverts in precompile contracts now properly refund gas.

Together, the Michelson interface and Native Atomic Composability establish the infrastructure for Tezos X, a trustless execution environment enshrined in the Tezos protocol and secured by Tezos Layer 1, whose full rollout is planned for later in 2026. These features are already live on the Tezos X Previewnet — see Tezos X | Tezos X docs for the complete documentation, and the cross-interface counter demo at https://tzx-counter.vercel.app/.

:warning: Node operators: Etherlink 7.0 requires Octez EVM node version 0.64 or higher. Please upgrade your infrastructure before activation to avoid regressions.

Should the governance vote be successful, the upgrade will be triggered on Wednesday, 12 August 2026, and Etherlink 7.0 will activate on mainnet 24 hours later, on Thursday, 13 August 2026.

:folded_hands: Thank you for your continued support for Etherlink.

:date: CTA: Please upvote Etherlink 7.0

The kernel upgrade proposal (007a6ac98660fa68cab09abfb3a59be93ccf4a5d47aeb44a00ffb0a3babdba448a) has already been injected in the current proposal period.

Proposal period vote: slow governance period 40, spanning between L1 levels #14,328,289 (August 2 12:36 UTC) and #14,395,488 (August 7 04:36 UTC).

Promotion period vote: slow governance period 41, spanning between L1 levels #14,395,489 (August 7 04:36 UTC) and #14,462,688 (August 11 20:36 UTC).

:backhand_index_pointing_right: Remember that Etherlink slow governance periods last ~4 days and 16 hours, which means bakers have a comfortable window for each of the two votes. Note however that the Proposal period closes in the early morning of Friday, August 7 (~04:36 UTC).

For the proposal to move to the Promotion period, it must gather support from at least 1% of the total voting power. The Promotion period then requires a 5% quorum and a 75% “yea” supermajority.

Bakers can cast their votes in a few clicks with Etherlink’s governance explorer UI, or using TezGov. We provide further voting instructions to vote with Octez CLI below.

Don’t hesitate to reach out if you need our help to make sure you can cast your votes in time.

Annex: voting instructions

Bakers can cast their votes in a few clicks with Etherlink’s governance explorer UI, or using TezGov. It is also possible to vote using Octez CLI, with the following commands:

Proposal Period (slow governance period 40)

The Proposal period vote started at L1 level #14,328,289 (August 2 12:36 UTC) and will run until #14,395,488 (August 7 04:36 UTC).

You can upvote the Etherlink 7.0 kernel upgrade proposal using the following Octez CLI command:

octez-client call KT1AXRU3wLc87WNhLhVGrgqDGubLACUMUgPb from <baking_key or voting_key> \
  --entrypoint "upvote_proposal" \
  --arg "0x007a6ac98660fa68cab09abfb3a59be93ccf4a5d47aeb44a00ffb0a3babdba448a" \
  --burn-cap 0.11

Promotion Period (slow governance period 41)

If the Proposal period is successful, the Promotion period would span between L1 levels #14,395,489 (August 7 04:36 UTC) and #14,462,688 (August 11 20:36 UTC).

You can vote for the Etherlink 7.0 kernel upgrade proposal using the following Octez CLI command:

octez-client call KT1AXRU3wLc87WNhLhVGrgqDGubLACUMUgPb from <baking_key or voting_key> \
  --entrypoint "vote" --arg '"yea"' \
  --burn-cap 0.11

See this documentation entry for further instructions on how to participate in Etherlink’s governance, and don’t hesitate to reach out if you need our assistance to cast your votes.

Annex: reproducing the kernel root hash

Etherlink upgrades are identified by the root hash of the binary resulting from the compilation of the Etherlink kernel crate to WASM. The Etherlink 7.0 kernel root hash is 0x007a6ac98660fa68cab09abfb3a59be93ccf4a5d47aeb44a00ffb0a3babdba448a, built from commit 92258d046043a2ceed7a6400687a1bfa28893096 of the Octez repository.

This hash is fully reproducible: rather than trusting the proposers, anyone can rebuild the kernel from source and check that they obtain the same root hash as the one submitted on-chain. The build runs inside a Docker container to make it reproducible, so Docker is the only prerequisite.

git clone https://gitlab.com/tezos/tezos
cd tezos
git checkout 92258d046043a2ceed7a6400687a1bfa28893096
./etherlink/scripts/build-wasm.sh
cat etherlink/kernels-92258d046043a2ceed7a6400687a1bfa28893096/root_hash

The output should match the root hash of the proposal:

ROOT_HASH: 007a6ac98660fa68cab09abfb3a59be93ccf4a5d47aeb44a00ffb0a3babdba448a

Once you have checked the hash, you can safely ignore and delete the contents of the _evm_installer_preimages/ directory.

2 Likes