KeeperHub / KeeperHub/keeperhub

feat(protocols): add Renzo liquid restaking (stake for ezETH, pause gate, reads)

Open
#2,392 4 comments 0 reactions 0 assignees View on GitHub
accepted confirmed
Dominant language
TypeScript
Stars
24
Forks
93
Avg merge
1d 4h
Merged PRs (30d)
253

Description

### Before filing

- [x] I searched open and closed issues for this proposal.
- [x] I checked the docs and the current behaviour on `staging`.
- [x] This is one change, not several.

### Reason: what you cannot do today

A workflow cannot stake ETH into Renzo for ezETH. It cannot read whether Renzo deposits are paused. It cannot read an ezETH balance or supply. Renzo is a large liquid restaking protocol, a sibling to the Lido, Rocket Pool, Frax Ether V2 integrations already in the registry, so a builder routing value through ezETH has no first-class action.

### Reason: what the workaround costs

The only path today is a raw `web3/write-contract` node with a hand-pasted RestakeManager address, the `depositETH` ABI fragment, the correct payable handling, with no labels, help text, decimals, no read/write typing. That is the same gap the existing staking integrations were added to close, plus the loss of the on-chain test coverage every registered protocol gets.

### Scope: what this touches, and what it does not

Adds one new protocol definition, `protocols/renzo.ts`, its minimal ABIs under `protocols/abis/`, a unit test, plus the regenerated `protocols/index.ts` and `lib/types/integration.ts` that `pnpm discover-plugins` produces. No existing protocol, node, route, schema, nor dependency changes.

Deliberately left alone, correct with these reverted:

- Mainnet only (chain 1). Minting settles on the beacon chain.
- Native-ETH deposit only (`depositETH`). The ERC20-collateral deposit variants are a separate surface.
- No withdrawal action. Renzo withdrawals are a queue, a distinct surface that can ship separately later.

### Plan: what you propose

Follow the existing `defineAbiProtocol` pattern (closest precedent: `protocols/frax-ether-v2.ts` and `protocols/rocket-pool.ts`). Two contracts:

- `restakeManager` `0x74a09653A083691711cF8215a6ab074BB4e99ef5`: `depositETH()` payable as the `stake` action, plus `paused()` as a read gate.
- `ezeth` `0xbf5495Efe5DB9ce00f80364C8B423567e58d2110`: reads `balanceOf` and `totalSupply`.

Both were verified against mainnet on 2026-09-10 over a public RPC before filing: ezETH reports name "Renzo Restaked ETH", symbol ezETH, about 41,324 ETH of supply; `RestakeManager.paused()` read false and `renzoOracle()` returned a live oracle address, confirming this is the active manager deployment.

Test data mirrors the staking siblings: `paused` expects `false` and `ez-total-supply` expects nonZero as chain invariants. `stake` carries a write-expectation oracle that re-reads the ezETH balance after the deposit so a mined-but-uncredited deposit fails the suite.

I have this built and green locally against `staging` (discover-plugins registers it, tsgo and biome clean, a 17-case unit test modeled on `protocol-frax-ether-v2.test.ts` passes). I will open the PR once this is accepted.

### Plan: alternatives considered

- Doing nothing: leaves a major LRT reachable only through raw nodes while its staking siblings are first-class.
- Exposing the ERC20-collateral `deposit(token, amount)` variants in the same change: rejected. They need an approval flow and token registry entries the native path does not. They can ship and be correct with the native path reverted, so by the one-change test they are separate.
- Adding the withdrawal queue here: rejected for the same one-change reason.

Contributor guide

Open the contributing guide

Research direction

Read protocols/frax-ether-v2.ts and protocols/rocket-pool.ts to follow the existing defineAbiProtocol pattern, then inspect the ABI conventions under protocols/abis/. Run the modeled unit test and pnpm discover-plugins first; done means the Renzo definition, ABI files, test, and regenerated protocols/index.ts and lib/types/integration.ts are present and the stated checks pass.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
blockchain
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.