Tezlink and the Future of Tezos X

Tezlink has become a major point of discussion in the Tezos ecosystem, often mentioned in the context of Tezos X. It first appeared in the Tezos X proposed roadmap under the name “Michelson Rollup” before evolving into what we now call Tezlink (for now).

Since that first mention, a lot has changed, and it hasn’t always been easy to keep track of all the developments, so in this article, I want to break down Tezlink using the publicly available information I’ve gathered so far. I think that while it’s still evolving, the direction is already becoming clear.

What is Tezlink? #

Tezlink will be part of the canonical rollup that sits at the heart of Tezos X. Think of the canonical rollup as a very large noncustodial execution environment enshrined to the Tezos protocol, a modular and composable system designed to host different “views” (aka runtimes) of the same rollup, with the ability for those runtimes to interact synchronously with each other.

Arthur Breitman described it in Tezos X-plained Ep.8 with a neat analogy: imagine an object casting two shadows depending on the angle of light. From one angle, the shadow is Etherlink, the EVM-compatible view. From another, the shadow is Tezlink, the Tezos-native view. Both come from the same underlying object, but they offer different perspectives.

This means Tezlink isn’t an add-on to Etherlink or a side experimental project. It’s a native execution environment that will live inside the canonical rollup, side by side with Etherlink, giving builders who prefer Tezos-native tools like Michelson, SmartPy, or Ligo a home within the new scaling framework.

And it goes even further, these runtimes aren’t isolated. Tezlink and Etherlink will be able to interact with each other, for example, a contract written in Michelson on Tezlink will be able to call a contract running on Etherlink. That level of composability is critical because it means all the DeFi work and infrastructure being built on Etherlink can directly benefit Tezlink as well, creating one interconnected ecosystem instead of siloed environments.

So more importantly, it ensures developers won’t be forced to choose between building “natively” on the Layer 1 or having access to the performance, liquidity, and integrations that come with the rollup system.

That’s why Tezlink matters, because it removes that trade-off. It combines the low latency and scalability of the rollup architecture with the flexibility of Tezos-native development, while also tapping into everything that’s being built on other runtimes

How will Tezlink work? #

We said that Tezlink will live inside the canonical rollup**,** the centerpiece of Tezos X, which is modular by design, meaning it can host multiple runtimes under one roof. Etherlink is one of those runtimes, Tezlink will be another, and more will follow, such as Jstz. All of them will share the same secure foundation while offering different “views” and opportunities for developers and users.

You can picture it like a large room that everyone enters, that room is the canonical rollup. On the outside, there are multiple doors leading in. One door says Etherlink, another says Tezlink, another one will be Jstz and more will likely open in the future. No matter which door you walk through, you end up in the same room, sharing the same secure environment. The difference is in the tools you’ll be using to get there. Etherlink might take you in through MetaMask and other EVM-based tooling, while Tezlink will use Tezos-native wallets and frameworks. But once you’re inside, it’s all the same, you’re still using tez as the gas token, and you can interact with everything in the room regardless of which door you chose to enter.

Being part of the canonical rollup means Tezlink gains some important advantages. It scales with the Data Availability Layer, allowing for higher throughput while keeping costs efficient. It benefits from lower latency, making applications feel smoother and more responsive. And because it sits side by side with the other runtimes, Tezlink naturally connects to their liquidity and infrastructure, without forcing developers to step outside their preferred Tezos-native tools.

What about Layer 1? #

At the same time, Layer 1 remains the backbone. Early on, there was the idea of moving the entire L1 state into Tezlink. The thinking was that by keeping L1 focused only on consensus, staking, transfers, data availability, governance, and rollup adjudication, it could become much lighter and potentially allow for lower latency and faster finality.

But after discussions and feedback from the community, it seems far more likely that Tezlink will be introduced as an extension of the L1. Projects that want to expand to Tezlink for performance gains and other features will be able to do so, while others can remain only on L1 if they choose.

Regardless of how projects choose to deploy, Layer 1 will remain indispensable. It’s the anchor where governance takes place, where consensus is secured, and where rollups ultimately settle. In other words, even as Tezlink and other runtimes take on more of the execution load, L1 continues to provide the trust and stability that the whole system depends on.

Also, at this point, I feel it’s important to note that over time the practical distinction between L1 and L2 is expected to fade. The vision for Tezos X is that users won’t have to think about layers at all, they’ll just interact with Tezos, with security and performance built in. No switching, no trade-offs, just a seamless and unified experience.

So there you have it! Tezlink will be a very important piece of Tezos X, the part that lets Tezheads like me tap into everything being built inside the canonical rollup without needing to rely on MetaMask or other EVM tools I’m not used to. Instead, I’ll be able to interact with it all through Tezos-native wallets like Kukai and explorers like TzKT, sticking with the tools I already love.

It also opens a new chapter for builders who have made the Michelson VM their home. With Tezlink, they’ll be able to expand their projects or create entirely new ones with far greater performance and connectivity than before, all while staying true to the Tezos-native development experience, security, and decentralization.

That’s why I see Tezlink as a bridge between the past and future of Tezos, connecting what we’ve built with what comes next.

The direction is unmistakable: a modular, interconnected Tezos where different runtimes share the same foundation, and tez remains at the center of it all.