From 50925f5fa1f347de10d1209e87af71f25300d6b6 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 3 Aug 2026 10:52:11 +0200 Subject: [PATCH 01/54] import sidebar --- sidebars.js | 222 +++++++++++++++++++++++++++++++++++----------------- 1 file changed, 151 insertions(+), 71 deletions(-) diff --git a/sidebars.js b/sidebars.js index b1ab7f62..838bebbd 100644 --- a/sidebars.js +++ b/sidebars.js @@ -34,98 +34,155 @@ const sidebars = { }, { type: 'category', - label: 'Get started', - collapsed: false, + label: 'Overview', items: [ - 'index', - 'get-started/chatbot', - 'get-started/using-your-wallet', - 'get-started/sending-transactions', - 'get-started/network-information', - 'get-started/getting-testnet-tokens', - 'get-started/getting-mainnet-tokens', + 'overview/index', + 'overview/get-started', + 'overview/accounts-and-aliases', + 'overview/native-atomic-composability', + 'overview/blocks-and-blueprints', + 'overview/fee-structure', + 'overview/resources', + 'overview/chatbot', + 'overview/glossary', ], }, { type: 'category', - label: 'Tutorial', - collapsed: false, + label: 'EVM Interface', items: [ - 'tutorials/predictionMarket/index', - 'tutorials/predictionMarket/write-contract', - 'tutorials/predictionMarket/deploy-contract', - 'tutorials/predictionMarket/frontend', + 'evm/index', + { + type: 'category', + label: 'Getting started', + link: { + type: 'doc', + id: 'evm/getting-started', + }, + items: [ + 'evm/get-started/using-your-wallet', + 'evm/get-started/network-information', + 'evm/get-started/getting-testnet-tokens', + 'evm/get-started/getting-mainnet-tokens', + 'evm/get-started/sending-transactions', + ], + }, + 'evm/nac-usage', + { + type: 'category', + label: 'Bridging', + items: [ + 'evm/bridging/bridging', + 'evm/bridging/bridging-evm', + 'evm/bridging/bridging-tezos', + 'evm/bridging/bridging-fa', + 'evm/bridging/bridging-fa-how', + 'evm/bridging/bridging-fa-transactions', + ], + }, + { + type: 'category', + label: 'Developing', + items: [ + 'evm/developing/compatibility', + 'evm/developing/endpoint-support', + 'evm/developing/information', + 'evm/developing/fees', + 'evm/developing/estimating-fees', + 'evm/developing/transactions', + 'evm/developing/deploying-contracts', + 'evm/developing/verifying-contracts', + 'evm/developing/indexing-graph', + 'evm/developing/websockets', + 'evm/developing/tokens', + 'evm/developing/development-toolkits', + ], + }, + { + type: 'category', + label: 'Tools', + items: [ + 'evm/tools/exchanges', + 'evm/tools/onramps', + 'evm/tools/node-providers', + 'evm/tools/price-feeds', + 'evm/tools/vrf', + 'evm/tools/data-indexers', + 'evm/tools/cross-chain-comms', + 'evm/tools/game-development', + 'evm/tools/developer-experience', + 'evm/tools/institutions', + 'evm/tools/communication', + ], + }, ], }, { type: 'category', - label: 'Bridging', - collapsed: false, + label: 'Michelson Interface', items: [ - 'bridging/bridging', - 'bridging/bridging-evm', - 'bridging/bridging-tezos', - 'bridging/bridging-fa', - 'bridging/bridging-fa-how', - 'bridging/bridging-fa-transactions', + 'michelson/index', + { + type: 'category', + label: 'Getting started', + link: { + type: 'doc', + id: 'michelson/getting-started', + }, + items: [ + 'michelson/wallet-support', + 'michelson/network-information', + 'michelson/relayer', + ], + }, + 'michelson/nac-usage', + 'michelson/self-address', + 'michelson/bridging', + { + type: 'category', + label: 'Developing', + items: [ + 'michelson/developing/compatibility', + 'michelson/developing/accounts', + 'michelson/developing/tokens', + 'michelson/developing/smart-contracts', + 'michelson/tools/dapps', + 'michelson/developing/rpc-reference', + ], + }, + { + type: 'category', + label: 'Tools', + items: [ + 'michelson/tools/tezos-unity-sdk', + ], + }, ], }, { type: 'category', - label: 'Developing', - collapsed: false, + label: 'Testing', items: [ - 'building-on-etherlink/endpoint-support', - 'building-on-etherlink/sandbox', - 'building-on-etherlink/testnet', - 'building-on-etherlink/information', - 'building-on-etherlink/estimating-fees', - 'building-on-etherlink/transactions', - 'building-on-etherlink/deploying-contracts', - 'building-on-etherlink/verifying-contracts', - 'building-on-etherlink/indexing-graph', - 'building-on-etherlink/websockets', - 'building-on-etherlink/tokens', - 'building-on-etherlink/development-toolkits', + 'testing/sandbox', + 'testing/testnet', + 'testing/previewnet', ], }, { type: 'category', - label: 'Network', - collapsed: false, + label: 'Running the Network', items: [ 'network/architecture', - 'network/fees', 'network/operators', 'network/smart-rollup-nodes', 'network/evm-nodes', 'network/building-kernel', 'network/monitoring', - 'network/migrating-testnet', - ], - }, - { - type: 'category', - label: 'Tools', - collapsed: false, - items: [ - 'tools/exchanges', - 'tools/onramps', - 'tools/node-providers', - 'tools/price-feeds', - 'tools/vrf', - 'tools/data-indexers', - 'tools/cross-chain-comms', - 'tools/game-development', - 'tools/developer-experience', - 'tools/institutions', - 'tools/communication' ], }, { type: 'category', label: 'Governance', - collapsed: false, items: [ 'governance/overview', 'governance/quickstart', @@ -139,27 +196,50 @@ const sidebars = { }, { type: 'category', - label: 'Track progress', - collapsed: false, + label: 'Tutorials', + link: { + type: 'doc', + id: 'tutorials/index', + }, items: [ - 'progress/upgrades', - 'progress/changelogs', { - type: 'link', - href: 'https://gitlab.com/tezos/tezos/-/tree/master/etherlink', - label: 'Source code', + type: 'category', + label: 'Prediction market', + link: { + type: 'doc', + id: 'tutorials/predictionMarket/index', + }, + items: [ + 'tutorials/predictionMarket/write-contract', + 'tutorials/predictionMarket/deploy-contract', + 'tutorials/predictionMarket/frontend', + ], }, + 'tutorials/nac-counter', { - type: 'link', - href: 'https://gitlab.com/groups/tezos/-/issues/?sort=created\_date\&state=opened\&search=EVM%20\&first\_page\_size=20', - label: 'Pull requests', + type: 'category', + label: 'Advanced Examples', + link: { + type: 'doc', + id: 'examples/index', + }, + items: [ + 'examples/potluck-game', + ], }, ], }, + { + type: 'category', + label: 'Track Progress', + items: [ + 'progress/upgrades', + 'progress/changelogs', + ], + }, { type: 'category', label: 'Resources', - collapsed: false, items: [ 'resources/etherlink-further-reading', 'resources/scaling-on-tezos', From 80e01c69e0eadbb64f4b53bfb3c0fb913f1dc6b4 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 3 Aug 2026 10:52:29 +0200 Subject: [PATCH 02/54] import section Overview --- docs/overview/accounts-and-aliases.md | 61 +++++++++++++ docs/overview/blocks-and-blueprints.md | 35 +++++++ docs/overview/chatbot.md | 49 ++++++++++ docs/overview/fee-structure.md | 31 +++++++ docs/overview/get-started.md | 23 +++++ docs/overview/glossary.md | 47 ++++++++++ docs/overview/index.md | 96 ++++++++++++++++++++ docs/overview/native-atomic-composability.md | 49 ++++++++++ docs/overview/resources.md | 44 +++++++++ 9 files changed, 435 insertions(+) create mode 100644 docs/overview/accounts-and-aliases.md create mode 100644 docs/overview/blocks-and-blueprints.md create mode 100644 docs/overview/chatbot.md create mode 100644 docs/overview/fee-structure.md create mode 100644 docs/overview/get-started.md create mode 100644 docs/overview/glossary.md create mode 100644 docs/overview/index.md create mode 100644 docs/overview/native-atomic-composability.md create mode 100644 docs/overview/resources.md diff --git a/docs/overview/accounts-and-aliases.md b/docs/overview/accounts-and-aliases.md new file mode 100644 index 00000000..2053d4b9 --- /dev/null +++ b/docs/overview/accounts-and-aliases.md @@ -0,0 +1,61 @@ +--- +title: Accounts and Aliases +--- + +# Accounts and Aliases + +## Accounts + +Every account in Etherlink is **native to exactly one interface**: either the EVM interface or the Michelson interface. An interface fully owns its accounts: it defines their behaviour, manages their state, and controls how they interact with smart contracts. + +This means: +- An EVM account (native to the Etherlink EVM interface), beit an externally owned account or smart contract, behaves exactly as it would on any other EVM-compatible chain. +- A Tezos account (native to the Tezos Michelson interface) behaves exactly as it would on Tezos Layer 1. + +Each interface's tooling, wallets, and indexers work without modification because the underlying account semantics are unchanged. + +## Aliases + +Because accounts are interface-native, a Tezos account cannot directly hold an EVM balance, and vice versa. To bridge this gap, Etherlink introduces **aliases**: every native account is automatically assigned a corresponding address in each of the other interfaces. + +An alias is a regular address in the foreign interface — it can hold tokens, receive calls, and appear in blocks like any other account in that interface. +However, even though an alias can technically hold any kind of tokens, including ERC-20 tokens, FA2 tokens, and native tez tokens, the current implementation forwards the latter (any tez tokens it receives) to the corresponding native address in the other interface via the gateway, as described below. + +The mapping from a native address to its alias is deterministic and can be computed off-chain, as explained below. + +### EVM alias of a Tezos account + +When a Tezos account interacts with the EVM runtime for the first time, an EVM alias address is created for it. The alias is implemented using **EIP-7702 delegation**: a shared `AliasForwarder` contract is deployed at the alias address and stores the native Tezos address. Any tez received by the EVM alias is automatically forwarded back to the native Tezos account via the gateway. + +The EVM alias address is computed as the **first 20 bytes of the Keccak256 hash of the base58check-encoded Tezos address** (the human-readable string form, e.g. `tz1VSUr8wwNhLAzempoch5d6hLRiTh8Cjcjb`): + +``` +evm_alias = keccak256(utf8(tz_address_base58check))[0:20] +``` + +### Michelson alias of an EVM account + +When an EVM account interacts with the Michelson runtime for the first time, a Michelson alias is created as a **KT1 smart contract**. This contract automatically forwards any tez it receives back to the native EVM account via the gateway. + +The KT1 alias address is computed by applying **BLAKE2b with a 20-byte output** to the raw 20-byte binary of the EVM address, then encoding the result as a KT1 contract hash: + +``` +kt1_alias = KT1(blake2b_160(evm_address_bytes)) +``` + +Michelson's `SOURCE` instruction returns the null address (`tz1Ke2h7sDdakHJQh8WX4Z372du1KChsksyU`) for operations originating from cross-interface calls — not the actual alias address. This is because Michelson requires the source to be a user account. + +## Tez precision across interfaces + +The two interfaces use different precision for tez: + +| Interface | Unit | Decimals | Example | +|---|---|---|---| +| Michelson | mutez | 6 | 1 tez = 1,000,000 mutez | +| EVM | wei (of tez) | 18 | 1 tez = 10¹⁸ wei | + +When transferring tez between interfaces, amounts are scaled by a factor of **10¹²**. A transfer of `n` mutez from the Michelson interface corresponds to `n × 10¹²` wei in the EVM interface. Values that are not a multiple of 10¹² cannot be represented precisely in mutez and will be truncated. + +## Wallets and tooling + +A user who owns both a Tezos address and an EVM address effectively controls assets that may be spread across up to four addresses (the two native addresses and their respective aliases). Wallets and indexers that aggregate information from both interfaces can present a unified view of a user's balances. diff --git a/docs/overview/blocks-and-blueprints.md b/docs/overview/blocks-and-blueprints.md new file mode 100644 index 00000000..a32f03db --- /dev/null +++ b/docs/overview/blocks-and-blueprints.md @@ -0,0 +1,35 @@ +--- +title: Blocks and Blueprints +--- + +# Blocks and Blueprints + +## Blueprints + +The sequencer collects operations submitted to all interfaces, orders them in first-in-first-out order, and bundles them into **blueprints**. A blueprint is the sequencer's signed proposal for the next batch of operations. Blueprints are published to the Tezos Layer 1 rollup inbox to be applied by rollup nodes. + +## Etherlink blocks + +Applying a blueprint produces a **Etherlink block**. This block contains the combined effects of all operations from all interfaces processed in that batch. + +## Per-interface blocks + +From each Etherlink block, a **per-interface block** is derived at the same level for each interface. A per-interface block only exposes effects that are internal to that interface. + +For example: +- A transfer between two Tezos accounts appears only in the Michelson interface block, not in the EVM interface block. +- A cross-runtime call from an EVM contract to a Michelson contract appears in both blocks: the initiating EVM transaction appears in the EVM block, and the resulting Michelson operation appears in the Michelson block, with an event linking the two. + +Because per-interface blocks are derived from Etherlink blocks, a runtime that was introduced after genesis will have its first block at a level greater than zero. + +## Block format + +Each per-interface block follows the standard format expected by its ecosystem: + +- The **EVM interface** block is compatible with the Ethereum JSON-RPC specification. Cross-runtime calls that target the EVM interface are represented as transactions with internal calls, preserving compatibility with existing Ethereum explorers and indexers. +- The **Michelson interface** block follows Tezos operation receipt conventions. Cross-runtime calls targeting the Michelson interface appear as internal operations. + +## Block time + +The sequencer targets a block time of down to 500 ms under load, providing sub-second +confirmation times. \ No newline at end of file diff --git a/docs/overview/chatbot.md b/docs/overview/chatbot.md new file mode 100644 index 00000000..9829d0a2 --- /dev/null +++ b/docs/overview/chatbot.md @@ -0,0 +1,49 @@ +--- +title: Using the chatbot +--- + +:::note + +Note that the chatbot is being transferred from the old Ethelink site. This may take a couple of weeks. + +You may provide feedback on the chatbot using the thumb up/down in its box, or comments via the **Feedback** button at the bottom right of the page. + +::: + +The AI-powered chatbot on this website (and a few websites in the tezos.com domain) is a conversational agent answering questions in plain English, based on the documentation (see [documentation sources](#documentation-sources)). + +You can access the chatbot with the **Ask AI** button at the center right of the page. + +Here are a few instructions & caveats that may help you better understand what you can expect from the chatbot (and what not to). + +:::warning + +The answers of the chatbot may be wrong, so you should use them wisely. + +::: + +The chatbot is **optimized for searching documentation**: searching and corroborating existing pieces of information in the documentation and pointing to the relevant sources. +In this respect, it serves as a documentation search assistant, to locate relevant pages in a big information base, even if the questions may not use exactly the right terms and keywords. + +Note that this searching feature of the chatbot is complementary to the classic search engine that is still provided: +- Classic search is meant to show you **all** the pages that contain some precise keywords (modulo some spelling variations), which is helpful when you know what terms to search for. +- In comparison, the chatbot is **not** meant for exhaustive results, but is better in interpreting questions, finding related terms, and guiding you to pages with information that may be helpful. + +While the chatbot also attempts to answer more general questions about Tezos and the tools and processes in the ecosystem, **it may occasionally suggest incorrect commands or even explain notions that do not exist**. + +In particular, **the chatbot is NOT a coding assistant**. It is not recommended to ask it for code excerpts or examples. Use with caution any code suggested by it. + +As a rule of thumb, the chatbot is more reliable in questions of the form "**What is** X?" than "**How to** do Y" or "**Why is** Z"? +While it may provide useful and valuable information for the latter forms, interpret and use the answers with care. + +## Documentation sources + +The chatbot and AI-powered search currently use the following documentation sources: + +- The Etherlink documentation (https://docs.etherlink.com/) +- The Tezos documentation (https://docs.tezos.com/) +- The Octez & Protocol documentation (https://octez.tezos.com/) +- The LIGO documentation (https://ligo.tezos.com/) +- The SmartPy documentation (https://smartpy.tezos.com/) + +We may add later on other companion websites from the [Tezos documentation ecosystem](https://docs.tezos.com/overview/resources). diff --git a/docs/overview/fee-structure.md b/docs/overview/fee-structure.md new file mode 100644 index 00000000..c4a0a715 --- /dev/null +++ b/docs/overview/fee-structure.md @@ -0,0 +1,31 @@ +--- +title: Fee Structure +--- + +# Fee Structure + +Each transaction on Etherlink incurs three categories of fees. + +## Execution and storage fees + +Execution fees cover the computation cost of running a transaction. +Storage fees compensate for permanent on-chain storage allocation: + +Both interfaces use gas as the unit of execution: + +- In the **EVM interface**, gas covers both computation and storage allocation — `SSTORE` operations consume gas. The fee is `gas_consumed × base_fee_per_gas`. +- In the **Michelson interface**, gas covers computation, while storage allocation is charged separately as a burn at a fixed rate per byte allocated: `fee = gas_consumed × base_fee_per_gas + bytes_allocated × cost_per_byte`. + +`base_fee_per_gas` is determined by the Etherlink kernel at the start of each block and adjusts dynamically based on network load. + +Execution and storage fees are **burnt**. + +## Inclusion fees + +Inclusion fees cover the cost of publishing blueprints to Tezos Layer 1. All runtimes charge the same cost per byte for inclusion fees, based on transaction size. + +From the **Michelson interface**'s point of view, inclusion fees are **burnt**. At the Etherlink block level, the equivalent amount is credited to the **sequencer pool address on the EVM interface**, ensuring the sequencer is compensated regardless of which interface originated the transaction. + +## Minimal fee + +Each runtime may also apply a minimum fee per transaction, which is **burnt**. diff --git a/docs/overview/get-started.md b/docs/overview/get-started.md new file mode 100644 index 00000000..6317fb30 --- /dev/null +++ b/docs/overview/get-started.md @@ -0,0 +1,23 @@ +--- +title: Get Started +--- + +# Get Started with Etherlink + +Etherlink exposes two interfaces — the EVM Interface and the Michelson Interface — each targeting a different developer ecosystem. Choose the interface that matches your background and tooling: + +## EVM Interface + +For developers familiar with Ethereum, Solidity, and EVM tooling (MetaMask, ethers.js, Hardhat, Foundry): + +👉 [Getting Started with the EVM Interface](/evm/getting-started) + +## Michelson Interface + +For developers familiar with Tezos, Michelson/LIGO/SmartPy, and Tezos tooling (Temple wallet, Taquito): + +👉 [Getting Started with the Michelson Interface](/michelson/getting-started) + +--- + +Both interfaces share the same underlying blockchain, so contracts deployed on one interface can interact with contracts on the other via [native atomic composability](/overview/native-atomic-composability). diff --git a/docs/overview/glossary.md b/docs/overview/glossary.md new file mode 100644 index 00000000..e3647877 --- /dev/null +++ b/docs/overview/glossary.md @@ -0,0 +1,47 @@ +--- +title: Glossary +--- + +# Glossary + +This glossary defines the most essential terms used in Etherlink. +For a wider set of terms used in the Tezos ecosystem, see the [Glossary](https://docs.tezos.com/overview/glossary) in the Tezos documentation. +These glossaries are planned to be fused in the near term. + +**Account** — An entity that can hold state and/or execute operations within one interface. Every account has an address and exists natively in exactly one interface. + +**Account state** — The data associated with an account (balance, storage, nonce, etc.), maintained by its native interface. + +**Address** — An identifier for an account within a specific interface. + +**Alias** — An address in a foreign interface that represents a native account from another interface. Aliases are created automatically on first interaction and forward tez received back to the native account. + +**Blueprint** — A signed batch of operations produced by the sequencer, covering all interfaces, published to the Tezos Layer 1 rollup inbox. + +**EVM runtime** — The runtime that implements the EVM interface, processing Ethereum-compatible transactions and executing code using the EVM. Exposes an Ethereum JSON-RPC endpoint. + +**Externally owned account (EOA)** — An account controlled by a private key (as opposed to a smart contract). + +**Foreign interface** — From an account's perspective, any interface other than its native interface. + +**Gateway contract** — A special contract in each interface that acts as the single entry point for cross-interface calls. In the EVM interface, the gateway is a precompile; in the Michelson interface, it is an enshrined KT1 contract. + +**Michelson runtime** — The runtime that implements the Michelson interface, processing Tezos-compatible operations and executing code using the Michelson VM. Exposes a Tezos RPC endpoint. + +**NAC** — Short for _native atomic composability_. The feature of Etherlink that enables a smart contract in one interface to call a contract in another interface within a single atomic transaction. Individual operations across interfaces are referred to as _cross-interface calls_. + +**Native interface** — From an account's perspective, the interface where its account state and cryptographic material reside. + +**Revert isolation** — A cross-interface call failure handling strategy where the caller catches the failure and continues, preserving its own state changes. + +**Revert propagation** — A cross-interface call failure handling strategy where the caller also reverts after observing a callee failure. + +**Runtime** — An environment that executes code and maintains account state. Etherlink currently includes the EVM runtime and the Michelson runtime. + +**Sequencer** — The node responsible for ordering operations and producing blueprints. Elected by Tezos Layer 1 bakers. + +**Smart contract** — An account controlled by code rather than a private key. + +**Etherlink kernel** — The orchestration layer (smart rollup kernel) that contains and coordinates all runtimes. + +**Etherlink block** — A block produced by applying a blueprint, representing the combined effects of all runtimes at a given level. diff --git a/docs/overview/index.md b/docs/overview/index.md new file mode 100644 index 00000000..3ac58bfe --- /dev/null +++ b/docs/overview/index.md @@ -0,0 +1,96 @@ +--- +title: Etherlink # tx +slug: / +--- + +# Etherlink + +Etherlink is a fast, non-custodial execution layer enshrined in the Tezos protocol, which settles back to the Tezos consensus layer (Tezos Layer 1) for security. + +Since kernel upgrade 7, Etherlink exposes a **single blockchain** that is **addressable through two interfaces**: an **EVM interface** (available since early 2024 under the name "Etherlink") and a new **Michelson interface** (previously called Tezlink). +In that, kernel upgrade 7 constituted an important milestone in the Tezos X roadmap, securing the way to the near-term Tezos X launch. + +To enable the seamless integration of the two ecosystems in this single blockchain, Etherlink provides **Native Atomic Composability** (sometimes shortened as NAC): smart contracts in one interface can call contracts in the other within a single atomic transaction. From an economical perspective, the interface used to interact with the chain doesn't matter, it becomes only a technical detail. +Thanks to the atomic composition, Etherlink can be seen as **unified execution layer**, constituting a single economical space. + +Each interface is implemented by a dedicated runtime exposing a standard RPC endpoint. + +| Interface | Runtime | RPC standard | +|---|---|---| +| EVM | EVM runtime | Ethereum JSON-RPC | +| Michelson | Michelson runtime | Tezos RPC | + +The goal for each interface is to stay as compatible as possible with the original ecosystem it supports — Ethereum for the EVM interface, and Tezos Layer 1 for the Michelson interface. Where differences exist, they are documented in the respective interface sections. + +## Network architecture + +Etherlink is powered by a [Tezos Smart Rollup](https://docs.tezos.com/architecture/smart-rollups). The key components of the [Etherlink architecture](/network/architecture) are: + +- **Sequencer** — elected by Tezos Layer 1 bakers, the sequencer orders and batches operations from all interfaces into _blueprints_, which it publishes to the L1 rollup inbox. It targets a block time of around 500 ms, and offers pre-confirmations in about 50ms. +- **Rollup nodes** — apply blueprints (including operations from all interfaces) to produce Etherlink blocks and maintain the chain state. Each rollup node derives a per-interface block from each Etherlink block. +- **EVM nodes** — expose the two JSON-RPC APIs, backed respectively by the EVM runtime state and Michelson runtime state. +- **Tezos nodes** — expose the Tezos Layer 1 RPC API. + +Operations submitted via either interface to the corresponding runtime are collected by the sequencer, interleaved in first-in-first-out order, and included in the next blueprint. + +## DX/UX (Developer and User eXperience) + +Built upon the secure foundation of Tezos consensus layer, Etherlink delivers a fast, fair, and (nearly) free experience for users and developers. + +### It's fast + +Experience a developer-friendly environment that minimizes wait times. +Etherlink provides low latency with sub-second (< 500ms) confirmation times, delivered by the sequencer. + +And it's getting even faster with [Instant Confirmations](/evm/developing/transactions#getting-instant-confirmations), currently an experimental feature, that provide pre-confirmations within 50ms. + +Leveraging the Tezos 2-block finality guarantee and the high-speed execution of Smart Rollups, Etherlink ensures your transactions are confirmed quickly and securely. + + + + + + + + + + + + + + + + + + + + + + + + + + +
ChainConfirmation time (L2/execution layer)Settlement time (L1/consensus layer)
Etherlink~ 500 ms
(preconfirmation: 50 ms)		~ 6 seconds
Optimism Bedrock~ 2 seconds~ 2 minutes
Arbitrum One~ 300 ms~ 7 minutes
+ +For more information about confirmation times and finality, see [Transaction finality](/network/architecture#transaction-finality). + +### It's fair + +Etherlink' governance is integrated with the permissionless and robust fraud-proof system of the Tezos protocol, ensuring transparency and fairness in decision making. + +Stakeholders can propose and vote on protocol changes, including kernel updates, security patches, and changes to the sequencer operator. +To accurately reflect community consensus, all governance processes are equipped with robust safeguards. + +Out of the box, anyone can participate and run a node, post commitments about the current state of Etherlink, challenge other node operators' commitments, and contribute to network security. +With no administrative keys or centralized bridges, users retain complete control over their assets, which helps ensure a fair environment free from exploitation. + +### It's (nearly) free + +On Etherlink, an ERC-20 transaction costs $0.001 or less, making it nearly free to use. +These minimal fees enable cost-effective transactions necessary to foster innovation and development. + +Security is enhanced on Etherlink in part because it is built on Tezos Smart Rollups, which are enshrined on the platform, meaning they are implemented directly in the protocol of the consensus layer. + +Because Smart Rollups run in separate environments, they avoid the per-transaction gas fees of the consensus layer and incur only minimal costs when publishing their state to the consensus layer. +This unique architecture allows you to build and deploy applications without worrying about prohibitive transaction costs. diff --git a/docs/overview/native-atomic-composability.md b/docs/overview/native-atomic-composability.md new file mode 100644 index 00000000..d8a22d58 --- /dev/null +++ b/docs/overview/native-atomic-composability.md @@ -0,0 +1,49 @@ +--- +title: Native Atomic Composability +--- + +# Native Atomic Composability + +Etherlink supports **native atomic composability** (NAC): a smart contract in one interface can call a contract in the other interface within a single, atomic transaction. If any part of the call chain fails, all effects — across both interfaces — are reverted. + +## Gateways + +Each interface exposes a **gateway**: a special contract that serves as the single entry point for cross-interface calls. From a smart contract's perspective, a cross-interface call is just a call to a well-known local address — no special language features or compiler extensions are needed. + +- In the EVM interface, the gateway is a **precompile** callable at a fixed address like any other contract. +- In the Michelson interface, the gateway is an **enshrined contract** at a fixed KT1 address. + +Gateways are the only interface between runtimes. Everything else — account semantics, gas models, token standards — remains interface-specific. + +## How a cross-interface call works + +1. The calling contract sends a request to its interface's gateway, specifying a target contract address and a payload. +2. The gateway forwards the payload to the target runtime. +3. If this is the caller's first interaction with the target runtime, the target runtime creates an alias for the caller (see [Accounts and Aliases](./accounts-and-aliases.md)). +4. The target runtime executes an internal transaction using the caller's alias as the sender. +5. The result is returned to the gateway, which passes it back to the calling contract. + +The alias mechanism ensures that each interface only ever deals with its own native account types. No runtime needs to understand foreign address formats. + +## Atomicity + +Cross-interface calls are **atomic**: if the callee reverts, the revert is handled according to the calling semantics of the caller interface: + +- In the EVM interface, the caller can choose to also revert (propagating the failure) or catch the error and continue (isolating the failure): callers can catch failures using low-level `call` and inspect the return status. +- In the Michelson interface, failures are always propagated: there is no try/catch mechanism in Michelson, so a failure in an internal operation reverts the entire operation group. In particular, if a NAC fails, the entire Michelson execution context that contains it fails. + +If the Michelson runtime reverts (regardless if it was triggered by a NAC from EVM or not), all nested cross-interface calls it triggered are also rolled back, including any calls (or calls back) into the EVM interface. + +## Re-entrancy + +Cross-interface calls support re-entrancy. When interface A calls interface B, interface B may itself trigger a cross-interface call back into interface A. The alias mechanism preserves correct identity at every nesting level: the callback appears as a call from interface B's alias, not the original caller. + +## Resources + +Each runtime manages its own gas model. When a cross-interface call is made, the caller converts its remaining gas into an equivalent budget for the callee using a conversion coefficient derived from performance benchmarks. Unconsumed gas is converted back to the caller's model when the callee returns. + +See [Resources](./resources.md) for the conversion rules between the EVM and Michelson interfaces. + +## Observability + +Each cross-interface call emits an event from the gateway before execution, containing an identifier that can be used to correlate calls across the two runtimes. This allows indexers to reconstruct the full call graph from the per-interface blocks. diff --git a/docs/overview/resources.md b/docs/overview/resources.md new file mode 100644 index 00000000..8db7d18f --- /dev/null +++ b/docs/overview/resources.md @@ -0,0 +1,44 @@ +--- +title: Resources Management +--- + +# Resources Management + +Etherlink accounts for the following resources consumed by smart contracts, according to the [fee structure](./fee-structure.md): execution time, storage, and inclusion in L1 blocks. + +Inclusion fees are the same in all Etherlink interfaces, because they are related to the cost of publishing data to L1. + +For execution and storage resources, Etherlink preserves each interface's existing resource model. Cross-interface calls bridge these models at gateway boundaries using a **conversion coefficient** `c`, derived from performance benchmarks that measure the relative execution capacity of each interface. + +Note that the gas cost of the different instructions in the Michelson runtime may differ with regard to their cost in Tezos L1. + +## Gas conversion + +Both the EVM and Michelson runtimes use gas to measure execution time, but they operate at different magnitudes. The coefficient `c` converts between them: + +- To convert EVM gas to Michelson gas: multiply by `c` +- To convert Michelson gas to EVM gas: multiply by `1/c` + +The `base_fee_per_gas` of the Michelson interface is also defined relative to the EVM interface's base fee using this coefficient, ensuring costs are consistent across interfaces. + +## EVM interface calling the Michelson interface + +When an EVM contract calls the Michelson gateway: + +1. **Setting limits.** The EVM contract's remaining gas is converted to a Michelson gas limit using `c`. The Michelson storage limit is set to a generous upper bound (storage allocation in the Michelson interface is converted to gas when going back to the EVM interface). +2. **On failure.** The error is returned to the EVM caller, along with the remaining gas. The EVM caller can catch the failure and continue. +3. **On success.** The Michelson storage cost is expressed as additional EVM gas units: `g_storage = storage_cost / base_fee_per_gas`. The remaining EVM gas is converted from the remaining Michelson gas minus `g_storage`. If the resulting gas is negative, the call reverts with an out-of-gas error. + +In the end, storage allocation in the Michelson runtime is accounted as gas in the EVM runtime, which preserves its semantics. + +## Michelson interface calling the EVM interface + +When a Michelson contract calls the EVM gateway: + +1. **Setting limits.** The Michelson contract's remaining gas is converted to an EVM gas limit using `1/c`. +2. **On failure.** Michelson semantics apply: the entire operation group reverts, including any prior state changes. +3. **On success.** The remaining EVM gas (which includes storage allocation) is converted back to Michelson gas using `c`. Execution continues in the Michelson runtime. + +## Simulation + +Etherlink simulates transactions to estimate resource limits (storage and gas) for the top-level operation. Cross-interface calls may take different execution paths at runtime, so simulated limits may need a margin to account for variability. Simulation tools add extra gas automatically where possible. From cd85b24ea406ebc5a6554b079a0058d9f9a981f5 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 3 Aug 2026 11:30:40 +0200 Subject: [PATCH 03/54] import section Michelson --- docs/michelson/bridging.md | 9 +++ docs/michelson/developing/accounts.md | 18 +++++ docs/michelson/developing/compatibility.md | 83 ++++++++++++++++++++ docs/michelson/developing/rpc-reference.md | 17 ++++ docs/michelson/developing/smart-contracts.md | 10 +++ docs/michelson/developing/tokens.md | 10 +++ docs/michelson/getting-started.md | 30 +++++++ docs/michelson/index.md | 21 +++++ docs/michelson/nac-usage.md | 38 +++++++++ docs/michelson/network-information.md | 37 +++++++++ docs/michelson/relayer.md | 12 +++ docs/michelson/self-address.md | 17 ++++ docs/michelson/tools/dapps.md | 8 ++ docs/michelson/tools/tezos-unity-sdk.md | 9 +++ docs/michelson/wallet-support.md | 27 +++++++ 15 files changed, 346 insertions(+) create mode 100644 docs/michelson/bridging.md create mode 100644 docs/michelson/developing/accounts.md create mode 100644 docs/michelson/developing/compatibility.md create mode 100644 docs/michelson/developing/rpc-reference.md create mode 100644 docs/michelson/developing/smart-contracts.md create mode 100644 docs/michelson/developing/tokens.md create mode 100644 docs/michelson/getting-started.md create mode 100644 docs/michelson/index.md create mode 100644 docs/michelson/nac-usage.md create mode 100644 docs/michelson/network-information.md create mode 100644 docs/michelson/relayer.md create mode 100644 docs/michelson/self-address.md create mode 100644 docs/michelson/tools/dapps.md create mode 100644 docs/michelson/tools/tezos-unity-sdk.md create mode 100644 docs/michelson/wallet-support.md diff --git a/docs/michelson/bridging.md b/docs/michelson/bridging.md new file mode 100644 index 00000000..60e0cfb0 --- /dev/null +++ b/docs/michelson/bridging.md @@ -0,0 +1,9 @@ +--- +title: Bridging +--- + +# Bridging + +Documentation coming soon. + +In the meantime, you can [bridge tokens to the EVM interface](/evm/bridging/) and control them via [Native Atomic Calls](/michelson/nac-usage). diff --git a/docs/michelson/developing/accounts.md b/docs/michelson/developing/accounts.md new file mode 100644 index 00000000..fff06c87 --- /dev/null +++ b/docs/michelson/developing/accounts.md @@ -0,0 +1,18 @@ +--- +title: Accounts +--- + +# Accounts + +Among the [types of accounts](https://docs.tezos.com/architecture/accounts) desscribed in the Tezos L1 documentation, the following are available in the Michelson interface: + +| Address type | Status | +|---|---| +| `tz1` (ed25519) | ✅ Supported | +| `tz2` (secp256k1) | ✅ Supported | +| `tz3` (P-256) | ✅ Supported | +| `tz4` (BLS) | 🔄 In progress | +| `KT1` (smart contracts) | ✅ Supported | +| `sr1` (smart rollup) | ❌ Not supported | + +You can find more details on [Accounts](https://octez.tezos.com/docs/alpha/accounts.html) in the Octez documentation. diff --git a/docs/michelson/developing/compatibility.md b/docs/michelson/developing/compatibility.md new file mode 100644 index 00000000..0e6a77b8 --- /dev/null +++ b/docs/michelson/developing/compatibility.md @@ -0,0 +1,83 @@ +--- +title: Compatibility with Tezos L1 +--- + +# Compatibility with Tezos L1 + +The Michelson Interface is designed to behave as closely as possible to Tezos Layer 1. + +## Compatible features + +Most of the features, including the following ones work identically to Tezos Layer 1. Therefore, users may safely refer to the corresponding page in the [Tezos documentation](https://docs.tezos.com/) for all these aspects. + +## Known differences + +The rest of this page documents the known differences between the Michelson interface and Tezos Layer 1. + +### Type of Accounts + +Not all Tezos account types are supported on Etherlink, see [Accounts](/michelson/developing/accounts). + +### Fees + +#### Execution and storage fees are burnt + +On Tezos L1, transaction fees are credited to the baker who includes the operation. On Etherlink, **execution and storage fees are burnt** — there is no equivalent of a baker reward at the Michelson interface level. + +#### Inclusion fees are burnt (on the Michelson interface) + +Inclusion fees are burned from the Michelson interface's perspective. The sequencer is compensated through the EVM runtime's sequencer pool instead. This means fee balance updates in Michelson receipts do not credit any address. + +### Source Accounts + +#### SOURCE returns the null address for cross-interface calls + +When a transaction is initiated via a cross-interface call (i.e., from the EVM interface), the Michelson `SOURCE` instruction returns the null address `tz1Ke2h7sDdakHJQh8WX4Z372du1KChsksyU`, not the originating EVM alias. This is because Michelson requires the source to be a user account. + +#### Aliases cannot directly hold tez + +Michelson aliases (KT1 contracts created for EVM accounts) automatically forward any tez they receive to the originating EVM account via the gateway. You cannot send tez directly to an alias address and retain it there. + +One consequence of this is that `SENDER == SELF_ADDRESS` is not a safe test in Etherlink, see [Self-address test](../self-address). + +### Blocks + +#### First block level may be greater than zero + +If the Michelson runtime was introduced after the chain genesis, its first block will be at a level greater than zero. This differs from a fresh Tezos L1 deployment where the first block is at level 1. + +#### Cross-interface operations appear with null source + +As a consequence of the fact that "SOURCE returns the null address for cross-interface calls" (see above), operations triggered by cross-runtime calls appear in Michelson runtime blocks with `tz1Ke2h7sDdakHJQh8WX4Z372du1KChsksyU` as the source. Indexers can cross-reference with the EVM runtime block using the cross-runtime call identifier emitted by the gateway. + +### Voting power + +The Michelson instructions `VOTING_POWER` and `TOTAL_VOTING_POWER` diverge from L1 at runtime as follows (but typecheck is identical): + +- In Etherlink, they return a hardcoded 0 +- In L1, they return the real staking weights. + +The rationale is that Etherlink governance (covering the kernel and sequencer) is managed on Layer 1, by Tezos L1 bakers. There is no governance process directly on Etherlink, hence no voting power. + +### RPCs + +Some of the Tezos RPCs are handled differently on Etherlink with respect to Tezos L1, due to the different context (e.g. no delegation possible), or are not implemented yet. +Refer to [RPC reference](/michelson/developing/rpc-reference). + +### Unsupported features + +The following features do not apply in a layer 2 context and are intentionally excluded: + +- Baking, attestations, delegations, staking +- Smart Rollup operations +- Consensus and governance operations + +### Not yet implemented features + +The following features from Tezos layer 1 are not yet available in the Michelson Interface: + +- BLS addresses (`tz4`) +- Tickets +- Sapling +- Timelocks +- Global constants diff --git a/docs/michelson/developing/rpc-reference.md b/docs/michelson/developing/rpc-reference.md new file mode 100644 index 00000000..5d1c01eb --- /dev/null +++ b/docs/michelson/developing/rpc-reference.md @@ -0,0 +1,17 @@ +--- +title: RPC reference +--- + +# RPC reference + +### RPC reference + +EVM nodes provide the same RPCs as Tezos L1 nodes, on the Michelson endpoint (see [Michelson network information](/michelson/network-information)). + +Refer to the [RPC reference](https://octez.tezos.com/docs/active/rpc.html) in the Octez documentation (also available as [a set of OpenAPI descriptions](https://octez.tezos.com/docs/api/openapi.html)). + +:::warning + +Note however that some of these RPCs are handled differently on Etherlink, due to the different context (e.g. no delegation possible), or are not implemented yet. The complete list of the differences will be compiled here. + +::: diff --git a/docs/michelson/developing/smart-contracts.md b/docs/michelson/developing/smart-contracts.md new file mode 100644 index 00000000..c8fe6020 --- /dev/null +++ b/docs/michelson/developing/smart-contracts.md @@ -0,0 +1,10 @@ +--- +title: Smart contracts +--- + +# Smart contracts + +Smart contracts can be developed using the same languages as in Tezos L1 (e.g., SmartPy and LIGO). + +Refer to section [Smart contracts](https://docs.tezos.com/smart-contracts) in the Tezos documentation. + diff --git a/docs/michelson/developing/tokens.md b/docs/michelson/developing/tokens.md new file mode 100644 index 00000000..8276741b --- /dev/null +++ b/docs/michelson/developing/tokens.md @@ -0,0 +1,10 @@ +--- +title: Tokens +--- + +# Tokens + +Tokens defined and used in the Michelson interface generally adhere to different standards such as FA1.2, FA2, or FA2.1. + +Refer to section [Tokens](https://docs.tezos.com/architecture/tokens) in the Tezos documentation for instructions on developing you own tokens. + diff --git a/docs/michelson/getting-started.md b/docs/michelson/getting-started.md new file mode 100644 index 00000000..fbcac1d0 --- /dev/null +++ b/docs/michelson/getting-started.md @@ -0,0 +1,30 @@ +--- +title: Getting Started +--- + +# Getting Started with the Michelson Interface + +This guide walks through connecting a Tezos wallet, obtaining tez, and interacting with the Michelson Interface on the Etherlink testnet. + +## 1. Connect a wallet + +Use any Tezos-compatible wallet that supports custom RPC endpoints (see [Wallet Support](./wallet-support.md)). +For network parameters and connection instructions, see [Michelson network information](/michelson/network-information). + +## 2. Get tez + +For information on faucets and obtaining testnet tez, see [Michelson network information](/michelson/network-information). + +## 3. Interact with a smart contract + +Once your wallet is funded, you can interact with any Michelson smart contract deployed on Etherlink. The workflow is identical to Tezos Layer 1: + +- Use the Tezos RPC or a higher-level SDK such as **Taquito** to originate contracts and send transactions. +- Use LIGO, SmartPy, or any other Michelson-targeting language to write contracts. Deploy them the same way you would on Tezos L1. +- Block explorers such as TzKT display operations and contract state. + +## 4. Try native atomic composability + +To call an EVM contract from a Michelson contract, use the NAC gateway. See [NAC Usage](./nac-usage.md) for the gateway address and call conventions. + +For an example of how a Michelson contract can be used from the EVM interface, check the [Cross-interface counter tutorial](/tutorials/nac-counter). diff --git a/docs/michelson/index.md b/docs/michelson/index.md new file mode 100644 index 00000000..94db9ee8 --- /dev/null +++ b/docs/michelson/index.md @@ -0,0 +1,21 @@ +--- +title: Overview +--- + +# Michelson Interface + +The **Michelson Interface** is implemented by a Michelson runtime that behaves as closely as possible to Tezos Layer 1, allowing Tezos developers to deploy and run their existing smart contracts on Etherlink with minimal changes. + +The few differences with respect to Tezos Layer 1 are detailed at [Compatibility with Tezos L1](/michelson/developing/compatibility). + +## Key features + +The Michelson Interface exposes a **Tezos RPC** endpoint, meaning any Tezos-compatible toolchain — wallets, indexers, SDKs, CLIs — can interact with it without modification. + +It supports: +- User accounts (tz1, tz2, tz3 addresses) +- Smart contracts (KT1 addresses) written in Michelson or compiled from higher-level languages (SmartPy, LIGO, etc.) +- Standard Tezos operations: transfers, contract originations, delegation, etc. +- FA1.2 and FA2 token standards + +Cross-interface calls to and from EVM contracts are available via the [NAC gateway](./nac-usage.md). diff --git a/docs/michelson/nac-usage.md b/docs/michelson/nac-usage.md new file mode 100644 index 00000000..336e8694 --- /dev/null +++ b/docs/michelson/nac-usage.md @@ -0,0 +1,38 @@ +--- +title: NAC Usage +--- + +# NAC Usage: Michelson to EVM + +Cross-interface calls go through the gateway contract of the caller's interface. +This page describes how to initiate a cross-interface call from the Michelson interface. +For the opposite way, see [EVM to Michelson](/evm/nac-usage). + +The Michelson-to-EVM gateway is an enshrined contract deployed at: + +``` +KT18oDJJKXMKhfE1bSuAPGp92pYcwVDiqsPw +``` + +## `call_evm` + +Call an EVM contract by providing the same parameters as the EVM-to-Michelson gateway: the destination address, entrypoint selector, and ABI-encoded data. +Additionally, it accepts as an optional parameter a callback, which takes the form of a Michelson contract address. This accommodates the specifics of Michelson, in which contract calls do not return a value. + +## ERC-20 wrapper + +For calling ERC-20 token contracts specifically, a convenience contract is available at: + +``` +KT18oDJJKXMKhfE1bSuAPGp92pYcwVKvCChb +``` + +This contract provides `approve` and `transfer` methods with a Michelson-friendly interface. + +## Return value + +Return values from cross-interface calls are encoded in the callee's native format: + +The EVM return value (ABI-encoded bytes) is passed back to a **callback contract** specified via the `with_result` entrypoint of the gateway contract. The callback contract must implement handling for the raw bytes. + +On-chain libraries for encoding and decoding across runtimes are provided to simplify this. diff --git a/docs/michelson/network-information.md b/docs/michelson/network-information.md new file mode 100644 index 00000000..85b7df8b --- /dev/null +++ b/docs/michelson/network-information.md @@ -0,0 +1,37 @@ +--- +title: Network information +--- + +For current and historical status information for Etherlink, see https://status.etherlink.com. + +For using the networks via the EVM interface, see [EVM network information](/evm/get-started/network-information). + +## Etherlink Mainnet + +| Network parameter | Value | +|---|---| +| Network identifier | TODO | +| Endpoint | N/A ([run your own EVM node](/network/evm-nodes)) | +| Indexer | TODO | +| Faucet | TODO | +| Bridge | TODO | + +## Etherlink Shadownet Testnet + +| Network parameter | Value | +|---|---| +| Network identifier | TODO | +| Endpoint | N/A (must run your own EVM node) | +| Indexer | TODO | +| Faucet | TODO | +| Bridge | TODO | + +## Etherlink Previewnet Testnet + +See [Previewnet](/testing/previewnet) page. + +## Quick connectivity check: + +``` bash +curl -s /chains/main/chain_id +``` diff --git a/docs/michelson/relayer.md b/docs/michelson/relayer.md new file mode 100644 index 00000000..791171e6 --- /dev/null +++ b/docs/michelson/relayer.md @@ -0,0 +1,12 @@ +--- +title: Wallet Relayer +--- + +# Wallet Relayer + +The **Wallet Relayer** is an injectable TypeScript script that implements EIP-1193 and EIP-6963, enabling users of the Michelson Interface to interact with dApps running on the EVM Interface without an EVM account. + +A future version may enable (the other way around) users of the EVM Interface of Etherlink to use their EVM wallet for interacting with dApps running on the Michelson interface. + +Full documentation and integration instructions are available at the [Relayer website](https://tezosx-relayer-9c5cf1.gitlab.io) + diff --git a/docs/michelson/self-address.md b/docs/michelson/self-address.md new file mode 100644 index 00000000..70fa20a5 --- /dev/null +++ b/docs/michelson/self-address.md @@ -0,0 +1,17 @@ +--- +title: Self-address test +--- + +# `SENDER == SELF_ADDRESS` is externally inducible + +On Etherlink, an external party can make a contract observe its immediate caller as its own address on a bare value transfer. A Michelson contract can be made to see `SENDER == SELF_ADDRESS`, and an EVM contract can be made to see `msg.sender == address(this)`, without any cooperation from the target: by sending tez to the contract's EVM alias, or Michelson alias, respectively. + +This is a consequence of the alias forwarding design, not a contract bug. Any authorization that trusts caller-equals-self as an internal only signal must not be relied upon on Etherlink. + +## What this means for developers + +When developing smart contracts, keep in mind the following: + +- Do not use `SENDER == SELF_ADDRESS` in Michelson, or `msg.sender == address(this)` in Solidity, as a trusted internal only or authorization signal on the default entrypoint or the value receiving fallback. +- A contract correct on Tezos L1 that gates a privileged default entrypoint action on caller-equals-self is silently reachable by any external party on Etherlink. Move such gates to a named entrypoint or to an explicit authorization check on a recorded controller. +- The originator identity is unaffected: `SOURCE` in Michelson and `tx.origin` in Solidity still reflect the external party that initiated the transfer, so guards keyed on the originator remain meaningful. diff --git a/docs/michelson/tools/dapps.md b/docs/michelson/tools/dapps.md new file mode 100644 index 00000000..6f0f2211 --- /dev/null +++ b/docs/michelson/tools/dapps.md @@ -0,0 +1,8 @@ +--- +title: Dapps +--- + +# Dapps + +For developping distributed applications (dApps) on the Michelson interface, refer to section [Dapps](https://docs.tezos.com/dApps) in the Tezos documentation. + diff --git a/docs/michelson/tools/tezos-unity-sdk.md b/docs/michelson/tools/tezos-unity-sdk.md new file mode 100644 index 00000000..5353d78c --- /dev/null +++ b/docs/michelson/tools/tezos-unity-sdk.md @@ -0,0 +1,9 @@ +--- +title: Tezos Unity SDK +--- + +# Tezos Unity SDK + +For developing games and other Unity applications on top of Etherlink you can use the [Tezos Unity SDK](https://docs.tezos.com/unity) as described in the Tezos documentation. +Note that this kit can be used both with the Michelson interface and with the EVM interface on Etherlink. + diff --git a/docs/michelson/wallet-support.md b/docs/michelson/wallet-support.md new file mode 100644 index 00000000..f1a311fd --- /dev/null +++ b/docs/michelson/wallet-support.md @@ -0,0 +1,27 @@ +--- +title: Wallet Support +--- + +# Wallet Support + +Any Tezos-compatible wallet that supports custom RPC endpoints can be used with the Michelson Interface on Etherlink. + +## Compatible wallets + +| Wallet | Notes | +|---|---| +| **Temple** | Browser extension; supports custom networks | +| **Umami** | *Desktop* wallet; supports custom networks | + +## Connecting to Etherlink + +1. Open your wallet's network settings. +2. Add a custom network using the Etherlink Michelson RPC endpoint from the [previewnet repository](https://github.com/trilitech/tezos-x-previewnet). +3. Switch to the custom network. + +Your tz address and balance will be shown as usual. Transactions are signed and submitted the same way as on Tezos Layer 1. + +## Note on aliases + +Your tz address has a corresponding alias address on the EVM Interface. +Tez received by that alias is forwarded automatically to your Michelson Interface balance, see [accounts and aliases](/overview/accounts-and-aliases). From 104d033ecc3277673975c2266305d621d49819cf Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 3 Aug 2026 12:09:32 +0200 Subject: [PATCH 04/54] create section EVM --- docs/{ => evm}/bridging/bridging-evm.mdx | 68 +++++------ docs/{ => evm}/bridging/bridging-fa-how.md | 0 .../bridging/bridging-fa-transactions.md | 30 ++--- docs/{ => evm}/bridging/bridging-fa.md | 32 +++--- docs/{ => evm}/bridging/bridging-tezos.md | 62 ++++------ docs/{ => evm}/bridging/bridging.mdx | 16 +-- docs/evm/developing/compatibility.md | 27 +++++ .../developing}/deploying-contracts.md | 22 ++-- .../developing}/development-toolkits.md | 14 +-- .../developing}/endpoint-support.md | 30 ++--- .../developing}/estimating-fees.md | 12 +- docs/evm/developing/fees.md | 98 ++++++++++++++++ .../developing}/indexing-graph.mdx | 38 +++--- .../developing}/information.md | 18 +-- .../developing}/tokens.mdx | 32 +++--- .../developing}/transactions.md | 48 ++++---- .../developing}/verifying-contracts.mdx | 2 +- .../developing}/websockets.md | 26 ++--- .../get-started/getting-mainnet-tokens.md | 0 .../get-started/getting-testnet-tokens.mdx | 0 .../get-started/network-information.mdx | 108 +++++++++--------- .../get-started/sending-transactions.md | 41 ++++--- .../get-started/using-your-wallet.mdx | 12 +- docs/evm/getting-started.md | 35 ++++++ docs/evm/index.md | 16 +++ docs/evm/nac-usage.md | 66 +++++++++++ docs/{ => evm}/tools/communication.md | 2 +- docs/{ => evm}/tools/cross-chain-comms.md | 2 +- docs/{ => evm}/tools/data-indexers.md | 20 ++-- docs/{ => evm}/tools/developer-experience.md | 6 +- docs/{ => evm}/tools/exchanges.md | 4 +- docs/{ => evm}/tools/game-development.md | 10 +- docs/{ => evm}/tools/institutions.md | 1 - docs/{ => evm}/tools/node-providers.md | 4 +- docs/{ => evm}/tools/onramps.md | 0 docs/{ => evm}/tools/price-feeds.md | 26 ++--- docs/{ => evm}/tools/vrf.md | 8 +- docs/get-started/chatbot.md | 47 -------- docs/overview/chatbot.md | 16 ++- .../sandbox.md | 0 .../testnet.mdx | 0 41 files changed, 591 insertions(+), 408 deletions(-) rename docs/{ => evm}/bridging/bridging-evm.mdx (80%) rename docs/{ => evm}/bridging/bridging-fa-how.md (100%) rename docs/{ => evm}/bridging/bridging-fa-transactions.md (75%) rename docs/{ => evm}/bridging/bridging-fa.md (57%) rename docs/{ => evm}/bridging/bridging-tezos.md (65%) rename docs/{ => evm}/bridging/bridging.mdx (68%) create mode 100644 docs/evm/developing/compatibility.md rename docs/{building-on-etherlink => evm/developing}/deploying-contracts.md (75%) rename docs/{building-on-etherlink => evm/developing}/development-toolkits.md (84%) rename docs/{building-on-etherlink => evm/developing}/endpoint-support.md (87%) rename docs/{building-on-etherlink => evm/developing}/estimating-fees.md (71%) create mode 100644 docs/evm/developing/fees.md rename docs/{building-on-etherlink => evm/developing}/indexing-graph.mdx (66%) rename docs/{building-on-etherlink => evm/developing}/information.md (81%) rename docs/{building-on-etherlink => evm/developing}/tokens.mdx (82%) rename docs/{building-on-etherlink => evm/developing}/transactions.md (92%) rename docs/{building-on-etherlink => evm/developing}/verifying-contracts.mdx (93%) rename docs/{building-on-etherlink => evm/developing}/websockets.md (90%) rename docs/{ => evm}/get-started/getting-mainnet-tokens.md (100%) rename docs/{ => evm}/get-started/getting-testnet-tokens.mdx (100%) rename docs/{ => evm}/get-started/network-information.mdx (76%) rename docs/{ => evm}/get-started/sending-transactions.md (68%) rename docs/{ => evm}/get-started/using-your-wallet.mdx (63%) create mode 100644 docs/evm/getting-started.md create mode 100644 docs/evm/index.md create mode 100644 docs/evm/nac-usage.md rename docs/{ => evm}/tools/communication.md (82%) rename docs/{ => evm}/tools/cross-chain-comms.md (90%) rename docs/{ => evm}/tools/data-indexers.md (58%) rename docs/{ => evm}/tools/developer-experience.md (83%) rename docs/{ => evm}/tools/exchanges.md (76%) rename docs/{ => evm}/tools/game-development.md (71%) rename docs/{ => evm}/tools/institutions.md (99%) rename docs/{ => evm}/tools/node-providers.md (86%) rename docs/{ => evm}/tools/onramps.md (100%) rename docs/{ => evm}/tools/price-feeds.md (90%) rename docs/{ => evm}/tools/vrf.md (63%) delete mode 100644 docs/get-started/chatbot.md rename docs/{building-on-etherlink => testing}/sandbox.md (100%) rename docs/{building-on-etherlink => testing}/testnet.mdx (100%) diff --git a/docs/bridging/bridging-evm.mdx b/docs/evm/bridging/bridging-evm.mdx similarity index 80% rename from docs/bridging/bridging-evm.mdx rename to docs/evm/bridging/bridging-evm.mdx index 506896c3..423c144e 100644 --- a/docs/bridging/bridging-evm.mdx +++ b/docs/evm/bridging/bridging-evm.mdx @@ -1,5 +1,5 @@ --- -title: Bridging tokens between Etherlink and other EVM networks +title: Bridging tokens between Etherlink EVM and other EVM networks # tevm sidebar_label: Bridging to EVM networks --- @@ -8,9 +8,9 @@ import Video from '@site/src/components/Video'; import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -[The Etherlink EVM bridge](https://bridge.etherlink.com/evm) is a web application that allows you to transfer wrapped tokens between Etherlink and several other EVM-compatible blockchain networks. +[The Etherlink EVM{/* TEVM */} bridge](https://bridge.etherlink.com/evm) is a web application that allows you to transfer wrapped tokens between Etherlink EVM{/* TEVM */} and several other EVM-compatible blockchain networks. -The EVM bridge supports connections from Etherlink to these networks: +The EVM bridge supports connections from Etherlink EVM{/* TEVM */} to these networks: - Ethereum - Avalanche C-Chain @@ -29,29 +29,27 @@ It allows users to transfer several wrapped tokens, including: - WBNB - SHIB -For the Etherlink addresses of these tokens, see [Token addresses](#token-addresses). +For the Etherlink EVM{/* TEVM */} addresses of these tokens, see [Token addresses](#token-addresses). -Etherlink's LayerZero bridge infrastructure also supports a number of tokens that meet their [Omnichain Fungible Token (OFT)](https://docs.layerzero.network/v2/developers/evm/oft/quickstart) standard. -The token addresses for OFTs that can be transferred between Etherlink and other networks (including WXTZ) can be retrieved from the [LayerZero API](https://docs.layerzero.network/v2/tools/api/oft), or are listed [here](#token-addresses). +Etherlink EVM{/* TEVM */}'s LayerZero bridge infrastructure also supports a number of tokens that meet their [Omnichain Fungible Token (OFT)](https://docs.layerzero.network/v2/developers/evm/oft/quickstart) standard. +The token addresses for OFTs that can be transferred between Etherlink EVM{/* TEVM */} and other networks (including WXTZ) can be retrieved from the [LayerZero API](https://docs.layerzero.network/v2/tools/api/oft), or are listed [here](#token-addresses). ## Bridge security The bridge uses the decentralized smart contracts of [LayerZero](https://layerzero.network/) that are deployed on the supported EVM networks without the intervention of a third party. -It also relies on the Etherlink node and sequencer operators that secure Etherlink itself; these operators are listed in [Network operators](/network/operators). +It also relies on the EVM node{/* TXN */} and sequencer operators that secure Etherlink{/* TX */} itself; these operators are listed in [Network operators](/network/operators). ## Using the EVM bridge -For a video walkthrough of the bridge, see this video: - -