> For the complete documentation index, see [llms.txt](https://docs.kpk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kpk.io/funds/infrastructure/onchain-accounting/price-feeds/ezeth.md).

# ezETH

ezETH is Renzo's liquid restaked ETH token. No direct ezETH/USD Chainlink feed exists on mainnet, so this `ICustomPriceFeed` adapter derives the backing ratio from Renzo's protocol TVL and the ezETH supply, then converts to USD using the NAV's primary ETH/USD price. An independent [cross-rate](/funds/infrastructure/onchain-accounting/price-feeds/cross-rate.md) **monitor** feed (`ETH/USD × ezETH/ETH`) is registered as a [divergence monitor](/funds/infrastructure/onchain-accounting/price-feeds.md#primary-feed-and-divergence-monitors) — if its ezETH rate diverges from Renzo's on-chain rate beyond tolerance, ezETH is flagged `irregular` without moving its price.

{% hint style="info" %}
**ezETH has two monitors, and only one of them is a market feed.** One cross-rate monitor's rate leg is RedStone's multi-feed **`ezETH_FUNDAMENTAL`**. Against a fundamental primary that puts *both* sides of the comparison on fundamentals, so it catches a reporting fault between two independent computations of the same claim but **not** a market depeg — the thing the tolerance exists to detect.

The second cross-rate monitor carries a genuine **market** leg, which is what makes the tolerance meaningful. Because `divergenceBps` is taken against the **worst** single monitor rather than the median, the market monitor dominates instead of being diluted by the fundamental one sitting near 0 bps, so ezETH's 250 bps tolerance can fire.

The market feed is itself deprecated by RedStone, which is deliberate and bounded: a monitor can never price NAV, and monitors are heartbeat-gated, so a frozen feed **self-excludes** from the divergence check rather than contributing a stale rate — `monitorFeedCount` simply drops from 2 to 1, making the degradation observable. Its heartbeat is derived from that feed's own measured cadence rather than copied from the other monitor's. Should *both* monitors go unreadable, ezETH is reported in [`NAV.monitorsUnhealthyPriceAssets`](/funds/infrastructure/onchain-accounting/concepts/stale-prices-and-sequencer.md#when-no-monitor-answered-monitorsunhealthypriceassets), so the loss of the check is visible rather than presenting as a clean `irregular` flag.

Its pair identity is **not** assertable from the feed contract: RedStone Classic-Push feeds return the constant `"Redstone Price Feed"` from `description()`, carrying no pair information, so the [rate-feed guard](/funds/infrastructure/onchain-accounting/price-feeds.md#custom-price-feeds) declares this leg `$UNVERIFIABLE` with a written reason and holds it to the plausibility band and readability checks instead.
{% endhint %}

**Source:** [`ezETH_CustomPriceFeed.sol`](https://github.com/karpatkey/onchain-accounting/blob/main/src/prices/protocols/ezETH_CustomPriceFeed.sol)

{% hint style="info" %}
**Mainnet feed.** The L2 deployments use a different oracle composition — see [ezETH (L2)](/funds/infrastructure/onchain-accounting/price-feeds/ezeth-l2.md).
{% endhint %}

***

## Approach

`calculateTVLs().totalTVL ÷ totalSupply` (ezETH/ETH) × ETH/USD.

<figure><img src="/files/EJ2bjtIt9Wh49Q8In11K" alt="Left-to-right flowchart of the ezETH (Mainnet) price feed: rate and Chainlink inputs combine into a USD price, with a staleness gate."><figcaption><p>ezETH (Mainnet) price feed — how its oracle inputs compose into a USD price, with the staleness gate.</p></figcaption></figure>

{% hint style="info" %}
The ETH/USD term is sourced from the NAV's own selector — see [Base/USD from the NAV's own selector](/funds/infrastructure/onchain-accounting/price-feeds.md#base-usd-from-the-navs-own-selector).
{% endhint %}

***

## Price calculation

```
ezEthRate = totalTVL (18) × 1e18 / ezETH.totalSupply()      // ezETH/ETH, 18 dec
price     = ezEthRate (18) × (ETH/USD) (8) / 1e18           // USD, 8 dec
```

| Input         | Source                                                  | Description                                                       |
| ------------- | ------------------------------------------------------- | ----------------------------------------------------------------- |
| `totalTVL`    | `IRestakeManager.calculateTVLs()` (18 dec)              | Total ETH value restaked via Renzo (read defensively — see below) |
| `totalSupply` | `IERC20(ezETH).totalSupply()`                           | Circulating ezETH supply                                          |
| ETH/USD       | **NAV base** — `getPriceDataNoDivergence(WETH)` (8 dec) | the NAV's primary WETH/USD price                                  |

The rate is taken directly from Renzo protocol state rather than a market price. If `calculateTVLs()` cannot be read or `totalSupply()` is `0`, the feed is marked stale. Output decimals are inherited from the ETH/USD feed (8).

Only the **third** return value of `calculateTVLs()` — `totalTVL`, a plain `uint256` — is read; the two nested arrays it also returns are never decoded. That matters because `try`/`catch` does not intercept a return-data **decode** failure (the decode runs in the calling frame, after the call returns), and a nested `uint256[][]` is the most failure-prone shape to decode: a bad head offset or an absurd length would propagate past the `catch` and revert the feed instead of degrading to stale.

***

## Constructor

```solidity
constructor(
    address ezEth_,
    address restakeManager_,
    address nav_,
    address baseAsset_
)
```

| Parameter         | Description                                                                                |
| ----------------- | ------------------------------------------------------------------------------------------ |
| `ezEth_`          | ezETH token address (also the supported underlying)                                        |
| `restakeManager_` | Renzo RestakeManager (exposes `calculateTVLs()`)                                           |
| `nav_`            | NAVCalculator (proxy) — supplies the base asset's USD price via `getPriceDataNoDivergence` |
| `baseAsset_`      | the registered base asset whose USD price is read (WETH)                                   |

***

## Staleness

`getLatestPrice()` returns stale if `calculateTVLs()` reverts, if `totalSupply()` is `0`, or if the derived rate is `0`, or if the NAV reports the base asset (WETH) stale — all its feeds stale. The base leg's `updatedAt` comes from the NAV's selected WETH feed.

{% hint style="warning" %}
`calculateTVLs()` reads Renzo's internal oracles, whose freshness is **not** independently checked here — only the NAV's base-asset staleness is. If Renzo's oracles are stale the TVL figure may be stale undetected. This is an architectural constraint of Renzo on mainnet; the L2 adapter avoids it by reading `xRenzoDeposit.getRate()` directly.
{% endhint %}

***

## Chains

Deployed on **Ethereum**. For the rollup deployment, see [ezETH (L2)](/funds/infrastructure/onchain-accounting/price-feeds/ezeth-l2.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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kpk.io/funds/infrastructure/onchain-accounting/price-feeds/ezeth.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
