> For the complete documentation index, see [llms.txt](https://help.enterprise.ledger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.enterprise.ledger.com/help-center-v2/reference/networks/ethereum.md).

# Ethereum (ETH) and EVM networks

Ethereum and EVM networks on Ledger Enterprise: parent Accounts, linked Accounts, fees, replacing a pending transaction, staking, and contract operations.

This page covers Ethereum and the other EVM networks your Workspace has enabled. Which are available in your Workspace is configuration, not a fixed list.

Beside Ethereum, Ledger Enterprise supports these EVM networks:

* 0G (Zero Gravity)
* ADI
* Arbitrum
* Avalanche C-Chain
* Base
* Bitlayer
* BSC
* Ethereum Classic
* Flare
* HyperEVM
* Linea
* Monad
* Optimism
* Polygon
* Sei
* Shape
* Somnia
* Sonic
* Story

### Testnets

Ledger can also enable two Ethereum testnets for a Workspace:

* **Ethereum Hoodi.** The **Staking** tab is available, as on Ethereum.
* **Ethereum Sepolia.** There is no staking.

Testnet assets have no market value. See [**Testnets**](/help-center-v2/reference/networks.md#testnets).

## How Ethereum differs

Ethereum uses an **Account** model. A balance is a number recorded against an address, not a set of outputs. An address can also hold code, which is what a smart contract is.

Two consequences appear in this product:

* A token is a contract, not a native asset. Token balances therefore live in their own Accounts, and the parent Account pays their fees.
* The same address is valid on every EVM network, because they share the address format.

For the protocol itself, see the [Ethereum developer documentation](https://ethereum.org/en/developers/docs/).

## Token coverage

Ledger Enterprise supports **ETH and ERC-20 tokens** on Ethereum, and the native coin and ERC-20 tokens on each supported EVM network.

A token Account can exist only for a token in Ledger's asset catalog. See [**Networks and tokens in your Workspace**](/help-center-v2/reference/networks.md#networks-and-tokens-in-your-workspace).

## Parent Accounts pay the fees

An ERC-20 token Account attaches to a **parent** Account holding the network's native asset. The parent pays the network fees for every token Account beneath it.

A token Account can hold a large balance and still be unable to send. This happens when its parent has no native asset left to pay the fee. **If a token transfer fails for want of fees, fund the parent.**

> **Note:** Monitor the parent's native balance, not only your token balances. A parent running dry silently blocks every token Account beneath it.

## Linked Accounts

The same address can exist across several EVM networks at the same position in your key hierarchy. These **Linked Accounts** share an address but are separate Accounts with separate balances and separate governance, one per network.

Check which network an Account is on before sending. An address valid on several EVM networks accepts a transfer on any of them. A transfer sent on the wrong network cannot be recovered by switching network.

### What makes two Accounts linked

Two native EVM Accounts with the same **index** are Linked Accounts. The **Derivation path** on the **Account info** tab ends with the index.

**The interface never creates a Linked Account.** It gives each new EVM Account the lowest index that no EVM Account in the Workspace uses, on any EVM network. Pending creation Requests also hold their index. A new Account from the interface therefore has a new address and no Linked Accounts.

To create a Linked Account, create the Account through the API. Set the optional `index` field to the index of the existing Account. See the [API documentation](https://help.enterprise.ledger.com/api-documentation-v2).

The API refuses an index that is not available on that network, with the message `Index <index> is not available for currency <network>`. An index is not available when an Account on that network uses it, or a pending creation Request for that network holds it.

### The Linked accounts tab

Native EVM Accounts have a **Linked accounts** tab. It lists the Linked Accounts that you can see, with their number above the list. With none, it reads "No linked EVM accounts".

Each row shows the Account name, its asset, and its total balance in countervalue and in the asset. The row actions are:

* **Send**, for Operators;
* **Edit**, for Administrators;
* **Receive**, for everyone.

The **Overview** of the Account also has a **Linked EVM accounts** card, with up to five Linked Accounts. The card does not show when the Account has no Linked Accounts.

## Fees

EVM networks price fees per unit of computation, and the total depends on network demand and on how much work the transaction does. A token transfer costs more than a native transfer, and a contract interaction more again.

The form offers fee strategies from slower and cheaper through to faster, plus a custom option for full control. The figure shown is a **maximum**, not a prediction.

## If a transaction is stuck

An EVM transaction can stay unconfirmed when its fee is too low for current demand.

You do not have to wait. You can replace it with a new transaction that takes the same place in the Account's sequence. This is called **Replace by Nonce**. Use it to speed the transaction up, or to cancel it.

Find the send Request in **Requests**. While its transaction is broadcasting, the Creator of the Request sees two actions:

| Action       | What it does                                                              |
| ------------ | ------------------------------------------------------------------------- |
| **Speed-up** | Sends the same transaction again with a higher fee                        |
| **Cancel**   | Replaces the transaction with an empty one, so the original never happens |

**Speed-up** is the icon on the Request's row, with the tooltip "Speed-up transaction". **Cancel transaction** is in the row's menu. Both actions also show in the Request's details.

Only the Creator of the Request sees these actions. Replace by Nonce covers send transactions only. Contract interactions, contract deployments and staking transactions cannot be replaced.

Each action creates a **new Request**. It needs the same approvals and the same review as the original.

> **Important:** Cancel still costs a fee. You pay for the replacement transaction. Cancel stops the transfer, it does not refund the cost.

Only one of the two transactions can confirm. Until one does, either still can.

## Staking Ethereum

Ethereum staking works in whole **validators**. That makes it different from other networks, where you stake an amount.

The **Staking** tab appears on every ETH Account, with or without a Staking Rule. It also appears on Ethereum Hoodi Accounts. It does not appear on token Accounts or on the other EVM networks, Ethereum Sepolia included.

To act on the tab, you need a Staking Rule that lists you in its first step. Without one, the actions are disabled with "You don't have the permission to stake". Administrators see the tab read-only.

The positions table has these columns: **Validators**, **Type** (**Legacy** or **Pectra**), **Estimated rewards**, **Staking balance**, **Total balance**, and **Actions** for Operators.

### What you can do

| Action               | What it does                                                      |
| -------------------- | ----------------------------------------------------------------- |
| Start staking        | Creates one or more validators from your balance                  |
| Top-up position      | Adds to a Pectra validator you already run                        |
| Consolidate position | Merges two validators into one                                    |
| Upgrade to Pectra    | Converts a Legacy validator to the current type                   |
| Withdraw             | Exits stake from a Pectra validator and returns it to the Account |

**Ethereum calls the exit action Withdraw.** Sui and Hedera call it Unstake, and Tezos calls it Undelegate.

**Withdraw** and **Consolidate position** become available once a position has been active for 256 epochs, about 27 hours. Until then, the tooltip gives the date.

### Amounts and validator count

A validator holds between **32 ETH** and **2,048 ETH**.

**Start staking** is disabled while the available balance is below 32 ETH.

When you enter an amount, the form works out how many validators to create and shows a selector, **Validators in this batch**. You can change it. The interface allows **1 to 20 validators** in a single Request. The API allows up to 150.

Your amount is divided equally between the validators. Some providers accept stakes only in multiples of a fixed step, so the division might not come out exactly.

**The leftover stays in your Account.** It is not lost, and it is not staked. For example, take a provider that accepts multiples of 1 ETH. Staking 100 ETH across 3 validators stakes 33 ETH each, and 1 ETH stays in the Account. The form shows the leftover before you continue. You can spend it, or include it in a later stake.

You will see an error if the split leaves less than 32 ETH per validator, or more than 2,048 ETH. Adjust the amount or the validator count.

### Choosing a provider

Staking runs through a validator provider. Search for one by name and pick it. The list of providers comes from Ledger.

All validators in one Request go to the same provider.

> **Note:** If no providers are available, **Start staking** is disabled and explains why. This is usually temporary.

### Consolidate

Consolidating merges one position into another, so you run fewer validators. Rewards then compound inside the larger validator instead of being paid out separately.

Start from the position you want to move. It moves in full. You then pick the target position, searching by provider or validator address. A target must be an active Pectra position. The protocol allows **two positions at a time**.

Targets that would take the combined balance above 2,048 ETH are not offered.

### Upgrade to Pectra

Older validators are marked **Legacy**. They cannot be topped up, and the tab offers **Upgrade to Pectra** on them instead.

Upgrading converts the position to the current type. It covers the full 32 ETH, and **it cannot be reversed**.

Your provider does not change when you upgrade. It may show as **Unknown provider**, because that information is not published on the blockchain.

### Withdraw

Withdrawing returns staked ETH to your Account. **Withdraw** shows on Pectra positions only. To exit a Legacy position, upgrade it first.

Use **Max** to exit the validator completely. For a partial withdrawal, at least 32 ETH must remain in the validator. If you want to take more than that, you have to exit in full.

**Withdrawals are not instant.** How long they take depends on which kind you choose, and this difference is large enough to plan around.

<table><thead><tr><th width="143.34375">Kind</th><th>What happens</th><th>Typical wait</th></tr></thead><tbody><tr><td>Partial</td><td>The validator keeps running. Ethereum pays out the amount you enter on its regular sweep, as long as at least 32 ETH stays in the validator</td><td>Often hours, usually under a day</td></tr><tr><td>Full exit</td><td>The validator has to leave Ethereum's active set first, then wait a fixed period, then be paid out</td><td>Usually a little over a day</td></tr></tbody></table>

For a **full exit**, three things happen in order:

1. The validator queues to leave the active set. Ethereum limits how many validators can leave at a time.
2. A fixed waiting period of about 27 hours follows.
3. The balance is paid out on the next sweep.

> **Note:** Both kinds get slower when many people withdraw at once. A partial withdrawal can stretch to about a week in heavy conditions. A full exit queue is normally short, but it has reached several weeks during periods of mass unstaking. Do not plan a tight deadline around a withdrawal.

These timings are protocol behavior, not Ledger Enterprise settings. See the [Ethereum documentation on staking withdrawals](https://ethereum.org/en/staking/withdrawals/). The timings were checked on 7 October 2026.

### Risks

Ethereum slashes a validator that signs two different blocks for the same slot, or that signs contradictory attestations. A slashed validator loses part of its staked ETH, and the network removes it. The removal takes 36 days.

A validator that misses its duties is penalized by the amount it would have received for them.

These rules are protocol behavior, not Ledger Enterprise settings. See the [Ethereum documentation on rewards and penalties](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/). The rules were checked on 9 October 2026.

### Fees on staking operations

Consolidate, upgrade, and withdraw carry **two** fees:

* The **network fee**, as on any Ethereum transaction.
* A **protocol fee**, shown as an additional line, which pays for the operation on Ethereum's staking layer.

The protocol fee includes a safety margin, because the exact cost is not known until the transaction runs. **Anything overpaid is not refunded.** The figure you approve is the total of both.

> **Important:** Consolidating and upgrading change your validator set, not how much you have staked. Both need approval like any other Request, so plan them rather than treating them as housekeeping.

The shared mechanics, enabling staking Rules and reviewing on your device, are in [**Staking**](/help-center-v2/guides/staking.md).

## Contract operations

EVM networks support three operations beyond transfers:

<table><thead><tr><th width="198.46484375">Operation</th><th>What it does</th></tr></thead><tbody><tr><td>Contract interaction</td><td>Calls a function on a smart contract, for example depositing into a protocol</td></tr><tr><td>Message signing</td><td>Signs a message without moving funds, for example to prove control of an address</td></tr><tr><td>Contract deployment</td><td>Publishes a new smart contract</td></tr></tbody></table>

Each is **governed by its own Rule**, separate from your send Rules, and each is optional. An Account that can send cannot necessarily interact with contracts: a Master Administrator has to add the corresponding Rule.

Contract interaction Rules carry their own thresholds and their own Whitelists. See [**Whitelists**](/help-center-v2/administration/governance/whitelists.md).

To create a contract interaction or a contract deployment, see [**Contract operations**](/help-center-v2/guides/transactions/contract-operations.md).

### Supported standards

| Standard | Used for                                                                    |
| -------- | --------------------------------------------------------------------------- |
| EIP-191  | Signing a plain text message                                                |
| EIP-712  | Signing structured, typed data, which the device can display field by field |
| ERC-20   | Token transfers and balances                                                |

A contract interaction calls a function on any contract your Rule permits. There is no restricted list of contract standards for interactions.

To reach external applications, see [**Connect**](/help-center-v2/guides/connectivity-hub.md).

## Related

* [**Sending assets**](/help-center-v2/guides/transactions/sending-assets.md)
* [**Staking**](/help-center-v2/guides/staking.md)
* [**Whitelists**](/help-center-v2/administration/governance/whitelists.md)
* [**Networks**](/help-center-v2/reference/networks.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.enterprise.ledger.com/help-center-v2/reference/networks/ethereum.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
