Announcing Etherlink 7.1: a security upgrade proposal

Research and Development
1

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

A new Etherlink kernel upgrade proposal, Etherlink 7.1 has just been submitted to Etherlink’s Fast governance mechanism.

This is a security kernel upgrade proposal.

Should the governance vote be successful today, Etherlink 7.1 will activate on mainnet on Sunday, 30 August 2026.

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

:date: CTA: Please upvote Etherlink 7.1

The kernel upgrade proposal 7.1 has already been injected in the current proposal period.

Proposal period vote: fast governance period 636, spanning between L1 levels #14,693,089 (August 28, 04:51 CEST) and #14,697,888 (August 28, 12:51 CEST).
Promotion period vote: fast governance period 637, spanning between L1 levels #14,697,889 (August 28, 12:51 CEST) and #14,702,688 (August 28, 20:51 CEST).

:backhand_index_pointing_right: Remember that Etherlink fast governance periods last ~8 hours, which means bakers would need to vote up to two times within the next 12 hours to participate in both votes.

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 (fast governance period 636)

The Proposal period vote will start at L1 level levels #14,693,089 (August 28, 04:51 CEST) and will run until #14,697,888 (August 28, 12:51 CEST).

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

octez-client call KT19oUVQPnVLuUBYXrBVd46WJnNAMpqkKSwo from <MY_VOTER> \
  --entrypoint "upvote_proposal" \
  --arg "0x00db5a8b279b9915f7ffef420347b5d9667ac4e73a9c766b7ef71513f748f52c67

Promotion Period (fast governance period 637)

If the Proposal period is successful, the Promotion period would span between L1 levels #14,697,889 (August 28, 12:51 CEST) and #14,702,688 (August 28, 20:51 CEST).

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

octez-client call KT19oUVQPnVLuUBYXrBVd46WJnNAMpqkKSwo from <MY_VOTER> \
  --entrypoint "vote" --arg '"yea"'

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.

6 Likes
2

Can any of the three teams explain why there’s been so many security upgrades for Etherlink? Just looking at the history on Agora, this is not inspiring much confidence when confidence is already at an all time low. It is one after another emergency patch.

3

GM!

Exactly. Check out my reply on this thread:

` You also say `The proposal also includes additional security improvements developed while working on the fix.` - What guarantees that no other security improvements are required? `

Less than two weeks ago I bring up the case of other security fixes being required as this was being pushed. And now it is exactly what is happening.

Voting on a proposal that is not totally clear should always be a no go; Unfortunately majority of the world is still sheep just following and reacting to whatever shows up in front of them.

4

I have to take umbrage with the picture presented by you here. Trust me, we have 99 problems (see my other posts) but this unfortunate situation is not one of them.

First, please tell me how you propose security fixes can be disclosed ahead of time on a vulnerable chain.

“My house lock combination is 3857 and I can’t change the code for 3 days. Please don’t rob me while I work on it.”

You’ll say, “simple, let’s make sure we don’t put out venerable software.” That’s a neat concept but there is not a single piece of complex (or worse, complex and novel) software that has no security issues.

This isn’t a sheeple situation. There’s no need to flatland into this analogy.

Complaining about facts of life makes it harder to take other more low hanging fruit type of issues seriously and gives people an excuse to ignore our feedback wholesale.

2 Likes
5

Knock Knock! Good evening, is dinner ready?

Oh yea, in this situation your logic makes sense. My whole point is that if things were not being rushed this could probably be avoided - in the future it might be a more serious security problem that causes demage.

Things made slower there`s time for them to be tested and verified, specially by people outside the teams making the proposal. If fast track becomes a behaviour, as tezos develops and gets more teams working on it, it can be dangerous.

Delicious food - thank you!

6

Are any of the three core dev teams going to answer us or are they just going to stick their head in the sand and act like people aren’t asking these questions?