Skip to content

doc for fast 6.2 upgrade#426

Draft
NicNomadic wants to merge 2 commits intomainfrom
nic-fast-6.2
Draft

doc for fast 6.2 upgrade#426
NicNomadic wants to merge 2 commits intomainfrom
nic-fast-6.2

Conversation

@NicNomadic
Copy link
Copy Markdown
Collaborator

@NicNomadic NicNomadic commented Mar 24, 2026

This PR updates the documentation according to the 6.2 fast kernel upgrade that happenned on 24/3/2026 (see https://governance.etherlink.com/governance/fast)

NB: Text to be finalized after the activation of the new kernel.

@NicNomadic NicNomadic requested review from skenaja and sribst March 24, 2026 08:59
@NicNomadic NicNomadic self-assigned this Mar 24, 2026
@vercel
Copy link
Copy Markdown

vercel bot commented Mar 24, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
docs-etherlink Ready Ready Preview, Comment Mar 25, 2026 7:43am

Request Review

@NicNomadic NicNomadic marked this pull request as draft March 24, 2026 09:23
@NicNomadic NicNomadic removed request for skenaja and sribst March 24, 2026 09:23
@NicNomadic NicNomadic closed this Mar 24, 2026
@NicNomadic NicNomadic deleted the nic-fast-6.2 branch March 24, 2026 12:54
@NicNomadic
Copy link
Copy Markdown
Collaborator Author

I'll reopen it tomorrow.

@NicNomadic
Copy link
Copy Markdown
Collaborator Author

Reopen after activation of kernel 6.2 this morning

@NicNomadic
Copy link
Copy Markdown
Collaborator Author

(after recreating the branch)

@NicNomadic NicNomadic reopened this Mar 25, 2026
@NicNomadic NicNomadic requested review from skenaja and sribst March 25, 2026 07:46
## Etherlink 6.2

The Etherlink 6.2 upgrade went through the fast kernel governance process and fixed 4 vulnerabilities detected by an internal audit in 6.1:
- It disallows the deposit of FA tokens via the Tezos FA token bridge directly in an EOA account (including smart accounts), to avoid a vulnerability in the FA token bridge Etherlink precompile. Any ERC-20 proxy contract used as a destination must now be a smart contract (the only pattern described in the documentation).
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did I understand well that the solution in 6.2 was to just forbid EOA accounts as destinations?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By seeing the post-mortem analysis, I guess I was wrong. Now I think that in 6.2 it's still valid to send an FA token to an EOA, but the logic of the withdrawal has been fixed to avoid stealing the token, right?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not exactly correct:

It fixes a vulnerability in the FA token bridge where anyone could withdraw FA tickets owned by an EOA, because the proxy authorization was a no-op on addresses with no code. The fix requires msg.sender == ticketOwner when the ticket owner is a wallet (EOA or EIP-7702 smart account).

Suggested change
- It disallows the deposit of FA tokens via the Tezos FA token bridge directly in an EOA account (including smart accounts), to avoid a vulnerability in the FA token bridge Etherlink precompile. Any ERC-20 proxy contract used as a destination must now be a smart contract (the only pattern described in the documentation).
- Fix a vulnerability in the FA token bridge allowing unauthorized withdrawal of FA tickets from EOA or EIP-7702 accounts.

The Etherlink 6.2 upgrade went through the fast kernel governance process and fixed 4 vulnerabilities detected by an internal audit in 6.1:
- It disallows the deposit of FA tokens via the Tezos FA token bridge directly in an EOA account (including smart accounts), to avoid a vulnerability in the FA token bridge Etherlink precompile. Any ERC-20 proxy contract used as a destination must now be a smart contract (the only pattern described in the documentation).
- It fixes a flaw in how transaction fees are accounted, that could allow an attacker to build a DoS of the block production process with no cost to the attacker.
- It fixes a flaw in the Tezos XTZ bridge that could cause a kernel panic when providing an empty L2 destination address.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fix guards against "empty
deposit info" (the entire deposit structure), not specifically an "empty L2 destination address." The scope of the guard is broader than described.

## Etherlink 6.2

The Etherlink 6.2 upgrade went through the fast kernel governance process and fixed 4 vulnerabilities detected by an internal audit in 6.1:
- It disallows the deposit of FA tokens via the Tezos FA token bridge directly in an EOA account (including smart accounts), to avoid a vulnerability in the FA token bridge Etherlink precompile. Any ERC-20 proxy contract used as a destination must now be a smart contract (the only pattern described in the documentation).
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not exactly correct:

It fixes a vulnerability in the FA token bridge where anyone could withdraw FA tickets owned by an EOA, because the proxy authorization was a no-op on addresses with no code. The fix requires msg.sender == ticketOwner when the ticket owner is a wallet (EOA or EIP-7702 smart account).

Suggested change
- It disallows the deposit of FA tokens via the Tezos FA token bridge directly in an EOA account (including smart accounts), to avoid a vulnerability in the FA token bridge Etherlink precompile. Any ERC-20 proxy contract used as a destination must now be a smart contract (the only pattern described in the documentation).
- Fix a vulnerability in the FA token bridge allowing unauthorized withdrawal of FA tickets from EOA or EIP-7702 accounts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants