Kelpdao is a Liquid Restaking Protocol for Minting and Tracking rsETH

A funded Ethereum account reaches rsETH in one or two transactions

A funded Ethereum account completes the Kelpdao mint in one deposit transaction, plus one approval when an ERC-20 allowance is missing. That distinction tells the user whether to expect one wallet prompt or two state-changing signatures.

The current Kelpdao mint interface presents exactly three deposit assets: native ETH, Lido stETH, and Stader ETHx. ETH avoids token approval, but the deposit amount and gas both draw from the same ETH balance. stETH and ETHx keep gas separate in ETH and move through their own ERC-20 contracts. The practical fit follows the balance already held: use the supported asset in the intended account, then judge the quote rather than swapping solely to change the mint route.

Network, account, and gas checks decide whether the quote is usable

The decisive setup condition is Ethereum mainnet alignment: the interface, wallet account, asset balance, and gas balance must agree. Ethereum mainnet uses chain ID 1, while an account address contains 20 bytes, displayed as 40 hexadecimal digits after the 0x prefix. Matching both prevents a valid balance on another chain or account from feeding the decision.

MetaMask, Rabby, and WalletConnect expose the active network and account before Kelpdao builds the quote. Reconnecting does not move funds; it refreshes context.

Gas needs its own check. One ETH equals 10^18 wei, and one gwei equals 10^9 wei. The wallet calculates the network charge from gas used and the effective gas price, so the charge remains separate from the rsETH amount displayed by the interface. An ETH deposit must leave room for this charge in the same balance. An stETH or ETHx deposit still requires ETH for the approval and deposit transactions, even though the selected LST supplies the principal.

Allowance scope separates permission from the actual LST deposit

An LST mint proceeds only after the selected token contract records enough allowance for the Kelpdao deposit pool. Approval changes permission; it does not transfer stETH or ETHx into the pool.

The approval writes one permission

The wallet submits one ERC-20 approval transaction when the recorded allowance falls below the chosen amount. The approval identifies three pieces of state: the token owner, the deposit-pool spender, and the allowance value. Native ETH has zero ERC-20 approvals because the deposit call carries ETH directly. If an adequate allowance already exists, the interface moves to the deposit prompt without creating another approval.

Read the first confirmation as permission only. The asset balance should remain unchanged until the separate deposit succeeds.

The deposit consumes the selected asset

The next signature authorizes one deposit transaction. For stETH or ETHx, the pool calls the token's transfer-from mechanism and then mints rsETH to the connected account. The transaction either completes both changes or reverts them together. A successful approval does not prove the deposit ran, while a successful deposit receipt proves the input moved and the rsETH mint executed.

Treat each wallet request by its action and asset, not by sequence alone. A delayed approval might arrive after an interface refresh, so reopen the quote and inspect the next request before signing, as described in Kelpdao availability use cases.

The rsETH quote turns two exchange rates into a minimum output

Two oracle-priced terms decide the Kelpdao quote: the selected asset's ETH value and the recorded rsETH price. The deposit contract calculates rsETH output as the input amount multiplied by the asset price, then divided by the rsETH price. Both token amounts use 18 decimal places, and the transaction carries one minimum-rsETH parameter. If execution would mint below that minimum, the call reverts instead of settling at a lower output. Review the input token, input amount, quoted rsETH, and minimum output as one linked decision.

Five ordered stages keep confirmation and verification tied together

The five-stage Kelpdao sequence keeps asset selection, permission, execution, and proof in a single ordered workflow. Skipping forward creates ambiguity about which state actually changed.

Before the wallet prompt

Before confirmation, lock four facts together: the active Ethereum account, the selected asset, the spend amount, and the rsETH quote. The table separates approval from deposit because Ethereum records them as different transactions. An ETH route skips stage three, leaving one deposit signature. An stETH or ETHx route uses stage three only when its allowance is short. The “Max” control still needs a gas check, since the interface quotes token output while the wallet prices network execution. That distinction prevents a full-balance ETH entry from leaving no room for gas.

After Ethereum execution

After execution, capture one transaction hash and read one receipt before relying on a formatted wallet card. Then query the rsETH balance for the same account on Ethereum. This order separates chain state from display state. Etherscan provides the receipt and token-transfer view, while the wallet provides a convenient balance presentation. Both should point to the same address.

Mint execution changes balances in one atomic deposit call

The deposit call settles only when the input transfer and rsETH mint complete within the same Ethereum transaction. The connected address becomes the recipient; the interface does not request a separate destination.

Native ETH path

For native ETH, the call sends one value field with the chosen wei amount. The contract checks the asset limit, computes the rsETH amount, enforces the minimum output, and mints to the caller. The receipt emits the ETH deposit record and the ERC-20 mint transfer. The wallet's ETH balance falls by the deposit plus gas, while its rsETH balance rises by the minted quantity.

stETH and ETHx path

For stETH or ETHx, the deposit call names one token address and one amount. The pool reads the oracle-priced output, uses the existing allowance to pull the LST, and mints rsETH to the same caller. The input token balance falls by the deposit amount. Lido supplies stETH, Stader supplies ETHx, and EigenLayer receives the restaking position through Kelpdao's protocol path after the user-facing mint.

rsETH is a standard ERC-20 balance, not a second wallet account. Its 18-decimal unit stays attached to the original caller.

Receipt fields prove execution before the wallet interface catches up

A successful Ethereum receipt supplies the earliest reliable proof that the rsETH mint reached chain state. Receipt status 1 means success; status 0 means the Ethereum Virtual Machine reverted the call.

Ethereum divides time into 12-second slots, although a deposit can wait across several slots before inclusion. Once included, the transaction hash identifies a 32-byte value, normally shown as 64 hexadecimal digits after 0x. Match that hash, the sending address, and the Kelpdao deposit action. Then inspect the ERC-20 Transfer mint from the 20-byte zero address to the connected account.

Finally, read rsETH with the Ethereum contract's balance function and preserve all 18 decimals before formatting. A wallet might round the visible number, while an explorer shows the raw token transfer. The confirmed minimum output sets the floor; the actual minted value in the receipt and balance supplies the final quantity. One receipt, one address, and one balance read complete the check.

A wrong-network setup resolves by restoring Ethereum mainnet context

A network mismatch blocks a usable Kelpdao quote because the interface reads balances from the active chain. Switch the wallet to Ethereum mainnet, confirm chain ID 1, retain the same account, reconnect, and reselect ETH, stETH, or ETHx. If no wallet confirmation appeared, no transaction entered Ethereum, so rebuilding the quote is enough. If an approval already confirmed, reload the interface and let it read the recorded allowance before proceeding. This recovery restores one account, one chain, and one current quote.