Kelp DAO is a Liquid Restaking Protocol for Minting and Exiting rsETH

Kelp DAO is the direct workflow for turning ETH, stETH, or ETHx into rsETH, checking the minted receipt in the same wallet, and later redeeming that position on Ethereum. A first position needs an EVM wallet, the correct network, enough ETH for gas, and an asset balance that clears the quote shown before signing. The exit decision comes later: Instant uses available liquidity for fast settlement, while Standard records a queued withdrawal that must mature before the receiving asset becomes claimable.

A token deposit normally needs two signatures, while native ETH reaches the mint in one transaction.

The Wrong Network Stops the First Attempt

The most common first-position failure is signing on the wrong network, because Kelp’s mint and Ethereum redemption paths aren’t interchangeable.

Kelp DAO exposes minting across supported networks, yet its direct redemption workflow returns to Ethereum. Before any signature, compare the dApp’s network label with the wallet’s network label. Ethereum mainnet uses chain ID 1, a durable identifier that wallets show independently of token balances. The withdrawal screen is Ethereum-only, so rsETH held elsewhere must reach Ethereum through a supported route before the holder chooses ETH, stETH, or ETHx as the output. Network switching changes the transaction state, so reread the asset, amount, and quote after every switch.

Wallet And Asset Prerequisites

A first rsETH position requires an EVM wallet, a supported deposit asset, the correct chain, and spare ETH for transaction gas.

The wallet must control the address that will receive rsETH and later submit withdrawal calls. MetaMask and Trust Wallet both provide EVM connections, while a hardware signer can sit behind a compatible wallet interface. Keep enough ETH outside the deposit amount for gas; Ethereum charges gas even when stETH or ETHx supplies the principal. Connecting exposes an address and network to the dApp, but it doesn’t authorize a token transfer or contract call.

Network State

The Kelp interface needs to show the intended chain before it builds a transaction. An Ethereum address occupies 20 bytes and normally displays as 40 hexadecimal characters after the 0x prefix. The same address format appears across EVM chains, which is why the characters alone don’t prove that the wallet selected chain ID 1. The chain identifier carries the decisive routing information.

Wallet State

The connected address needs the principal asset and an ETH balance for gas. Token balances, allowances, and native ETH are separate states, so one visible balance doesn’t establish the other two.

Native ETH Deposit

Native ETH enters through a payable deposit call. With adequate gas, that path needs 1 user transaction for the mint because no ERC-20 spending approval exists.

Token Deposit

stETH from Lido and ETHx from Stader follow ERC-20 allowance rules. Without an existing allowance, the first prompt approves the token and the second deposits it, producing 2 user transactions. An allowance that’s already large enough removes the first step from this particular mint, while a smaller allowance triggers another approval.

ETH, stETH, And ETHx Change the Signing Flow

ETH, stETH, and ETHx reach the same rsETH position through different wallet actions, so the asset choice changes the signing sequence.

In that setup, Kelp’s restaking guide lists 8 supported deposit chains and 3 input assets - ETH, stETH, and ETHx - while direct withdrawals settle only on Ethereum.

Native ETH keeps the first mint to a single contract call, provided the wallet holds the deposit value plus gas. stETH and ETHx preserve exposure to their respective liquid staking systems, and their token contracts require allowance before Kelp moves balances. Either route mints the same ERC-20 receipt, rsETH; the deposit asset affects input handling, not a promise to receive that identical asset on exit. Review the displayed exchange rate because Lido’s stETH and Stader’s ETHx don’t represent interchangeable units.

Reading the Mint Quote Before Signing

The mint quote defines how much rsETH the deposit receives, and its minimum-output field protects the user’s selected execution boundary.

Worked Example: In this hypothetical calculation, the changing inputs - a 2.4 ETH deposit and a displayed rate of 0.88 rsETH per ETH - are hypothetical. Multiplying 2.4 by 0.88 yields 2.112 rsETH. That 2.112 figure is the concrete expected output to compare with the interface’s minimum-received field before signing. The contract evaluates that minimum against the amount calculated during execution, not against an earlier preview. The wallet must also retain ETH for gas, because the full 2.4 ETH principal can’t consume the entire balance when the same account pays transaction costs.

The quote becomes part of the contract call rather than remaining an off-chain estimate. If execution would mint less than the specified minimum, the transaction reverts without creating the position.

Refresh the quote whenever the network, input asset, or deposit amount changes.

The Deposit Transaction And rsETH Mint

The deposit transaction transfers the selected asset into Kelp’s pool and mints rsETH to the same address in one atomic execution.

For native ETH, the call carries value and the minimum rsETH output. For stETH or ETHx, the pool pulls the approved token amount through ERC-20 transfer logic, calculates the mint from Kelp’s oracle inputs, and issues rsETH. The receipt token uses OpenZeppelin’s ERC-20 implementation with 18 decimal places, so 1 whole rsETH equals 10^18 base units. EigenLayer delegation happens behind the receipt position; the wallet’s observable outcome is an rsETH balance and a successful transaction receipt, not a separate validator account. A successful mint requires no later claim transaction.

Confirming the rsETH Position On-Chain

A confirmed rsETH position has three matching records: the wallet balance, the Kelp portfolio entry, and the Ethereum transaction receipt.

Start with the wallet balance. The rsETH token’s balanceOf value should rise for the connected address, and the Kelp portfolio should show the same position after indexing catches up. Then open the transaction in Etherscan and confirm a successful status, the expected sender, and interaction with the Kelp deposit pool. An Ethereum transaction hash is 32 bytes, normally rendered as 64 hexadecimal characters after 0x; it identifies the execution rather than the amount received.

The minted amount belongs in the token transfer event and the post-transaction balance. Wallet interfaces sometimes delay asset discovery, so a missing portfolio row doesn’t override an on-chain balance. Add rsETH to the wallet only with the canonical token address presented for the connected Kelp network, since identical symbols don’t establish contract identity.

How Do I Choose Instant or Standard Withdrawal?

Instant and Standard withdrawals serve different deadlines: one consumes ready liquidity, while the other creates a claimable request after a queue.

The published Instant route targets settlement in under 2 minutes at 0.2%, while Standard lists 15-21 days and a 0% protocol withdrawal fee.

Choose Instant when the displayed output is acceptable and the selected asset has available liquidity. Choose Standard when waiting fits the plan and avoiding the Instant deduction matters more than speed. Both modes consume rsETH and return one of 3 listed assets on Ethereum, but their state transitions differ. Instant settles through one withdrawal execution; Standard first creates an asset-specific request and exposes a separate claim after release.

Instant Exit Uses Available Liquidity

An Instant withdrawal burns rsETH and returns ETH, stETH, or ETHx only when the chosen asset has enough available liquidity (see also Kelp DAO walkthrough ).

The withdrawal manager computes the gross asset amount from the rsETH rate and selected asset rate, checks the unstaking vault’s inventory, burns rsETH, applies the displayed 0.2% deduction, and transfers the remainder. If the vault can’t cover that output, the transaction reverts atomically, including the earlier burn, because Ethereum rolls back the complete call. Switching from ETH to stETH or ETHx changes the inventory being checked, so one output route can execute while another remains unavailable. The wallet still needs ETH for the Instant transaction’s gas.

Standard Exit Creates a Queued Request

A Standard withdrawal transfers rsETH into the withdrawal manager, records an asset request, and waits for the queue to unlock it.

The withdrawal contract caps its configurable block delay at 16 days, represented as 115,200 blocks under its 12-second block conversion.

Standard begins with an ERC-20 transfer of rsETH into the withdrawal manager. The asset-specific queue records the rsETH amount, expected output, starting block, and a nonce that advances by 1. Each request ID is a 32-byte value derived from the asset address and nonce. When the queue unlocks, the contract sets the payout to the lower of the amount recorded at initiation and the amount produced by the later rate calculation. Requests remain ordered by asset and requesting address.

The interface’s 15-21-day estimate includes more than the programmable block delay because asset release and queue processing also affect readiness. A request remains pending until both its delay condition and asset allocation have cleared.

Claiming the Released Asset

A released Standard request still needs a completion transaction, which sends the selected asset back to the requesting wallet.

The completion call processes the oldest unlocked request for that asset and address, deletes the stored request, and transfers the recorded payout. This claim adds 1 wallet transaction after initiation; if rsETH approval was also needed, Standard involved 3 user transactions from approval through claim. Keep ETH for the final gas payment even when the requested output is stETH or ETHx. A successful completion removes the request from the wallet’s queue and increases the selected asset balance. Its transaction receipt provides the final execution record.

Edge Cases That Change a Clean Exit

Clean exits stop at predictable boundaries: network mismatch, insufficient gas, stale quotes, missing allowance, unavailable liquidity, or an unready queue.

Each boundary leaves a different on-chain state. A pending approval means the deposit or queued request hasn’t moved the token yet. An rsETH balance confirms that the minted position exists. A queued request means rsETH moved into the withdrawal manager, while an unlocked request means the asset awaits the completion call. Ethereum’s atomic execution prevents half a mint or half an Instant withdrawal from surviving a reverted transaction, although the wallet still pays gas for the computation performed.

Resume from the state that actually exists. Reconnect the same address, select chain ID 1 for direct withdrawal, retain ETH for gas, and inspect whether the interface shows rsETH, a pending request, or a claimable asset. The next valid action changes with that recorded state.