Etherlink belongs to the Tezos network architecture, even though its name and familiar Ethereum tools can suggest an Ethereum rollup. Its current design runs EVM and Michelson interfaces over one underlying chain. Both runtimes feed the same rollup kernel and settlement path. A contract calling another runtime within Etherlink therefore differs from moving an asset between Tezos layer 1 and the rollup. This distinction also separates Etherlink from the broader Tezos blockchain history: it is a particular execution environment with its own kernel, operating procedures and application community.

The developer entry points reveal the intended audience. Solidity developers can bring tools such as Foundry, Hardhat and Ethereum wallets; Michelson developers can use Tezos tooling such as Taquito and Temple. Familiar tooling lowers the cost of entry, but it does not erase differences between interfaces. An application still needs to select the correct endpoint, understand its account model and test cross-runtime behavior. Tezos programmers and Ethereum programmers are being invited into a shared execution space, not asked to pretend that their existing contracts have identical semantics.

The May 15, 2024 mainnet beta announcement presented Etherlink as a way to bring low latency and EVM compatibility to Tezos. MIDL.dev operated the initial sequencer, while the announcement emphasized baker governance over its replacement. Beta was explicitly a partner onboarding and readiness stage. Promised integrations were part of the intended launch path, rather than evidence that every named service already had production users. The early identity combined accessible Ethereum development with Tezos governance, a pairing that later community arguments repeatedly tested.

A January 22, 2025 engineering retrospective was unusually candid about the work behind that promise. Traffic from Degeneratives.art had overwhelmed the public endpoint infrastructure. The teams described added capacity, clearer node releases, snapshots, rate limits and better monitoring. They also acknowledged that previous deployment instructions made independent node operation unnecessarily difficult. Public RPC availability and blockchain settlement are different layers of service, but users encounter both through the same wallet.

The episode explains why an ecosystem needs independent infrastructure and operational documentation as well as a functioning consensus design.

Current operator documentation names Optimistic Labs as sequencer operator, working with Nomadic Labs and TriliTech. Other organizations can run Smart Rollup nodes, post commitments and challenge incorrect claims. Running an observer or challenger does not automatically confer the right to order the next block. Etherlink therefore distributes verification more broadly than ordinary sequencing. The operator list and bondholder records are more useful evidence of participation than a single decentralization label.

They let a reader ask separately who can inspect state, dispute it, publish transactions and replace the ordering service.

The architecture describes several stages of assurance. A quick sequencer confirmation indicates intended inclusion; a rollup block then reaches Tezos and enters the commitment process. Cementing a commitment follows the refutation period. These stages are not interchangeable promises of irreversible settlement. A payment interface may prefer speed, whereas a bridge or high-value settlement service may wait for stronger assurance.

The ordinary architecture also describes a delayed inbox as a way to bypass omitted transactions, but its generic timing must be read alongside the dated security changes discussed below.

Native Atomic Composability lets a contract call across EVM and Michelson runtimes through gateways within one Etherlink operation. Each runtime retains its own account and gas rules. Calls are coordinated so that failures roll back the affected cross-runtime execution according to the caller's semantics. Michelson propagates failure through its operation group; an EVM caller can deliberately catch a low-level failure. This is useful for applications combining existing contract ecosystems, but an author must still reason about error handling and reentrancy.

Atomic execution does not mean every application is economically safe.

The EVM gateway documentation makes the integration concrete. A Solidity caller supplies a Michelson destination, entrypoint and correctly encoded parameter bytes. Reading a Michelson view uses a different call pattern from changing its state. Address translation also has explicit lookup behavior, including cases where an account is not yet known to the kernel. These details matter to builders much more than a claim that every language can automatically interoperate.

Incorrect encoding, mistaken identity assumptions or mishandled call failures can break an application even when the network itself behaves as designed.

An Etherlink account belongs to one interface and receives an alias in the other when needed. The alias represents that account across runtimes; it is not evidence that a user controls a second unrelated private key. Current documentation describes automatic forwarding of tez received by aliases to their native account. It also specifies different tez precision: six decimal places in Michelson and eighteen in EVM representation, with truncation when an amount cannot be represented precisely. Wallets and indexers must account for these details when showing what a person actually owns.

Transaction costs are paid in tez. EVM execution fees vary with demand and are burned, while inclusion fees cover the cost of publishing transaction data to layer 1. Larger payloads can cost more even when their visible application action looks simple. There is no separate Etherlink token required for this fee mechanism, and this network account does not duplicate the XTZ coin edition. Burning execution fees is a protocol rule; any expectation that activity must raise XTZ's market price adds assumptions about demand, supply and competing uses that the fee rule alone cannot establish.

The native XTZ bridge locks and represents value through Tezos tickets and the rollup's inbox and outbox. A standard withdrawal waits for the relevant commitment to be cemented, approximately fifteen days in the documented process. Fast withdrawal changes who waits: a liquidity provider advances tez, keeps a fee and later receives the settled withdrawal. If no provider claims the request within the specified window, the ordinary settlement path remains. A quick payout is therefore a liquidity arrangement built around the slower proof process, not a disappearance of that process.

FA token bridging adds another representation boundary. Tezos assets are converted into tickets and associated with contracts on the EVM side; withdrawals ultimately require the appropriate outbox message to be executed on layer 1. An ERC-20 display in a wallet should therefore be traced back to its bridge and issuer. It does not acquire the identity of tez merely because both assets share a network. Understanding the representation is also necessary for interpreting bridge incidents: a defect in authorization or ticket handling can differ from a failure in the underlying token issuer.

Etherlink has distinct voting processes for regular kernel changes, urgent kernel changes and sequencer selection. Tezos bakers submit proposals and vote with their voting power. Proposal, promotion and cooldown phases make an upgrade more than a developer publishing new code. Fast governance has shorter windows and higher voting thresholds, reflecting a different balance between response time and deliberation. Nevertheless, formal approval alone does not show how many voters reproduced a build, reviewed an exploit or had enough time to participate.

Those questions become especially important when security details remain temporarily confidential.

In April 2026, Primate411 argued on Tezos Agora that sequencing centralization conflicted with the project's original governance identity. RichAyotte pointed to forced inclusion as a defense, while Primate411 replied that eventual inclusion was different from maintaining normal service during an outage. BowlOfTrees added the perspective of an operator who could run nearly every component except the sequencer. These were specific disagreements about participation and service continuity.

They should not be flattened into either universal community approval or a claim that no checks on sequencing exist.

The April 10, 2026 post-mortem on Etherlink 6.2 described four issues found through internal auditing, including malformed deposits, undercharged publication costs and transaction handling that could stall sequencing. The authors distinguished practical liveness risks from a theoretical FA ownership case they said did not occur in ordinary mainnet usage. That qualification matters: a vulnerability description is not proof that funds were stolen.

The report also connected several errors to the work of adding EIP-7702 support, illustrating how adopting familiar EVM features can introduce unfamiliar interactions with a rollup's fee and bridge machinery.

A September 21 disclosure described the later Ganesha fixes, including a cross-runtime accounting flaw that could have minted tez, and said none of the disclosed vulnerabilities had been exploited. Crucially, 7.1 temporarily extended forced-inclusion waiting from twelve hours to two weeks for three months so bakers had time to approve repairs before a malicious payload became mandatory. The authors described a hardcoded sunset. That dated notice overrides the shorter interval still shown in generic architecture text.

The safety measure materially changed the waiting period available to an ordinary censored user too.

The September 2026 request to vote on 7.2 acknowledged that bakers could not reproduce its kernel hash from public source before voting. skullzarmy objected to continuing this release process. Boulange defended withholding exploitable details, while EB113 suggested a community security council able to review confidential evidence. That proposed council was a participant's idea, not an established governing body. The disagreement concerned independent verification of urgent changes. The subsequent disclosure does not erase that tradeoff.

The upgrade history records real changes rather than an uninterrupted marketing narrative: Bifrost expanded token bridging, Calypso improved operation and storage, and Ganesha added the Michelson interface in August 2026. The first Ganesha proposal was withdrawn from its original path after further testing uncovered a flaw, and a patched kernel went through fast governance. Separating proposal dates from activation dates is essential when reading this history.

A published feature description can explain a design while still preceding the vote and running version that actually make it available to users.

Apple Farm became a recognizable part of Etherlink's culture through rewards for lending, trading and supplying liquidity. Tezos Commons' March 28, 2025 account described Season 1 as a three-million-dollar incentive program and invited users to participate across selected applications. This is evidence of how the campaign was presented to the community, rather than an independent measurement of lasting demand. Rewarded balances and transactions can be real while still depending on a subsidy.

A useful economic history therefore follows what participants continue doing after campaign terms and rewards change.

Huy Do, posting as HarryDo, proposed Wager as a binary-options application and requested support from the Tezos Ecosystem DAO. The thread records a treasury shortage, JASP offering personal funding, test feedback and later liquidity concerns. On September 23, 2026, the proposer was still asking how to obtain enough liquidity for a mainnet push. The record shows both initiative and friction: a working demonstration, enthusiastic replies and financial support do not by themselves prove a sustainable application or completed public launch.

It is a concrete builder story rather than a list of ecosystem logos.

A March 2024 discussion about a possible tokenized Etherlink fork exposed competing holder assumptions. greeneye44 argued that a separate governance token might attract developers, capital and users. buddykire preferred concentrating utility in XTZ and feared splitting attention and value. These are attributed economic beliefs, not evidence of a promised Etherlink airdrop or a reliable price relationship. Both sides were discussing how an ecosystem might grow. Their disagreement makes more sense when kept separate from the observable fee asset and the existing baker voting mechanism.

The current test environment is Shadownet, and the migration guide says the previous Ghostnet environment has been retired. Builders need the new chain identifier, endpoints, deployed contracts and indexer state rather than an old tutorial's assumptions. Operational freshness is part of understanding Etherlink: verify the running kernel, current security notices, bridge conditions and test network before applying a historical guide. Its value as an experiment lies in the interaction between two contract traditions and Tezos governance.

Whether that attracts durable applications remains a question to examine through actual deployments and continued use.