Kelp DAO is a Deposit Asset Selection and Minted rsETH Verification Interface
Kelp DAO is a liquid restaking interface that turns a supported ETH or liquid staking token deposit into minted rsETH. Select ETH, stETH, or ETHx on the connected network, review quoted rsETH, then confirm. Native ETH follows one deposit transaction; stETH and ETHx first need ERC-20 allowance unless sufficient approval already exists. Verification means matching the transaction receipt, events, and post-transaction rsETH balance.
The decision isn’t only which asset you own. It changes signature count, gas exposure, contract data, and the point at which a wallet balance should move. What follows stays on that pre-confirmation-to-verification path.
An Approval That Leaves the Wallet Balance Unchanged
The common setup failure is treating a completed ERC-20 approval as the deposit, even though approval moves no stETH or ETHx. It changes allowance state for one spender, and the interface must advance to a second signature.
With stETH from Lido or ETHx from Stader, the approval transaction authorizes the LRTDepositPool to call
transferFrom
up to the allowance. MetaMask or Rabby may label that action as a spending cap. A successful receipt proves only that the allowance changed. Your selected-token balance should remain unchanged, and rsETH should still be zero if you had none before. Return to the
Kelp DAO
interface, let it refresh the allowance, and submit the deposit action. If approval appears again, compare the connected account, network, selected asset, approved spender, and amount; one mismatch keeps the deposit unavailable.
Native ETH skips that allowance state, so its first state-changing prompt is the deposit itself.
A pending approval also occupies one account nonce. Opening a deposit prompt before approval lands leaves the later transaction waiting because Ethereum processes an account’s transactions in nonce order. If the approval receipt succeeded but the app hasn’t refreshed, reconnecting the wallet or reselecting the asset forces a new allowance read. Waiting for that first receipt preserves nonce order and is cleaner than replacing prompts blindly.
What Does the Deposit Cost Before rsETH Appears?
Kelp DAO’s deposit path adds no separate entry-fee transfer; the wallet pays network gas for each state-changing Ethereum transaction. The final gas charge equals gas used multiplied by the transaction’s effective gas price.
The detail is recorded in practice. Wallet connection requires zero on-chain transactions and therefore consumes no gas.
A native ETH deposit uses one state-changing call. An stETH or ETHx deposit with insufficient allowance uses two calls:
approve, then
depositAsset. A sufficient existing allowance reduces that route to one call. Ethereum’s fee unit is fixed: 1 gwei equals 1,000,000,000 wei, while 1 ETH equals 1,000,000,000,000,000,000 wei. Under EIP-1559, the effective gas price combines the block’s base fee and the included priority fee; the interface doesn’t set either number as a permanent Kelp rate.
Worked example: every changing input here is hypothetical - an approval using 50,000 gas, a deposit using 150,000 gas, and an effective gas price of 20 gwei. Together they use 200,000 gas. Multiplying 200,000 by 20 gwei gives 4,000,000 gwei, or 0.004 ETH. The network cost for the stated two-transaction case is 0.004 ETH.
That arithmetic isolates network cost; it doesn’t change the quoted rsETH. When allowance already covers the selected amount, remove the approval leg and compare one deposit charge with the two-transaction route.
Asset Selection Changes the Transaction Path
The asset selector determines whether Kelp DAO sends native value or calls an ERC-20 token contract before minting rsETH. The Ethereum route presents three deposit assets: ETH, stETH from Lido, and ETHx from Stader. ETH is the network coin and travels with
msg.value; the other two are ERC-20 tokens that use
approve
and
transferFrom. Keep enough ETH outside the selected token amount to pay gas. Choosing an existing liquid staking token preserves that token’s denomination through approval, while choosing native ETH follows the shorter single-call route.
What Should the Confirmation Screen Show?
The confirmation should show the connected chain, selected asset, spend amount, expected rsETH, minimum rsETH, and destination contract before signing. Those fields define the state change that the wallet will authorize.
When using Ethereum mainnet, chain ID 1 anchors the request. An EVM address is 20 bytes, normally rendered as 40 hexadecimal digits after
0x. Kelp’s mainnet LRTDepositPool address is
0x036676389e48133B63a802f8635AD39E752D375D. The ERC-20
depositAsset
call carries four arguments: asset address, deposit amount, minimum rsETH, and referral ID. The native
depositETH
call carries two calldata arguments - minimum rsETH and referral ID - while the ETH amount travels separately as
msg.value. An approval instead carries two operative values: spender and allowance.
The minimum-output field protects the displayed quote at execution. If the calculated mint falls below it, the contract reverts, leaving the deposited asset and rsETH unchanged. For native ETH, expect a value-bearing deposit call rather than an ERC-20 allowance call.
Minting and the On-Chain State Change
The deposit transaction transfers the chosen asset into the pool and mints calculated rsETH to the same calling address atomically. Kelp’s LRTDepositPool calculates deposit amount multiplied by asset price, then divided by the rsETH price.
Both price terms use 18-decimal fixed-point scaling, and the calculation returns an rsETH amount in token base units. The deposit’s amount logic checks three conditions before minting: a valid nonzero deposit above the configured minimum, room beneath the selected asset’s deposit limit, and output at or above the minimum rsETH amount. An ERC-20
AssetDeposit
event contains five fields: depositor, asset, deposit amount, rsETH mint amount, and referral ID. Native ETH uses an
ETHDeposit
event with four fields because it doesn’t need a token address. OpenZeppelin’s ERC-20 mint also emits a
Transfer
event from the zero address.
One Ethereum transaction is atomic, so a failed check rolls back the asset movement and mint together. Native ETH travels through
msg.value; stETH and ETHx use
transferFrom, which consumes the approved allowance before rsETH reaches the caller.
How Do You Verify the Minted rsETH Balance?
Verify minted rsETH by matching the successful receipt, Kelp deposit event, rsETH Transfer event, contract address, and wallet balance delta. Each item should point to the same account and transaction.
On Ethereum mainnet, the rsETH contract address is
0xA1290d69c65A6Fe4DF752f95823fae25cB99e5A7. An address contains 20 bytes and normally appears as 40 hexadecimal digits after
0x. A transaction hash holds 32 bytes and appears as 64 hexadecimal digits after
0x.
rsETH uses 18 decimal places, so 1 whole token equals 1,000,000,000,000,000,000 base units.
The receipt’s status value 1 means execution succeeded, while status 0 means the state change reverted. Match the contract address, not only the ticker shown by a wallet.
If MetaMask shows zero after success, add the known rsETH contract and refresh; importing only changes display metadata.
Etherscan’s token-transfer view should show the mint from the zero address, while
balanceOf
confirms the resulting account balance directly. Ethereum targets 12-second slots, groups 32 slots into one epoch, and reaches economic finality after two justified epochs under normal participation. The balance normally renders after block inclusion, before finality. A direct contract balance read provides stronger verification than a wallet’s token-list rendering.
Kelp DAO FAQ
Why does Kelp DAO show zero stETH on the selected network?
Kelp DAO reads the stETH balance for the connected account, connected chain, and supported token address. A wallet can hold stETH on Ethereum while the interface is connected elsewhere, or hold another bridged representation with a different contract address. Switch to the intended network, confirm the active account in MetaMask or Rabby, and reopen the asset selector so the interface refreshes its balance query.
Does a Safe smart account receive rsETH at its own address?
Yes, a Safe smart account that directly submits the supported deposit call receives rsETH at the Safe address because the mint goes to msg.sender. Its owner keys authorize the Safe transaction, but the individual signer addresses don’t become the rsETH recipients. Front-end connection support remains separate from contract behavior, so a Safe can also execute the verified LRTDepositPool call through its own transaction interface.
When does the minimum rsETH amount cancel the transaction?
The minimum rsETH amount cancels execution when Kelp’s calculated mint falls below the value encoded in the deposit call. The comparison happens before the asset transfer and mint, so Ethereum reverts the whole transaction atomically. Refreshing the quote produces a new minimum for a new submission; editing only the displayed estimate doesn’t alter the already signed calldata.
Should I send stETH directly to the Kelp LRTDepositPool contract?
No, a plain stETH transfer to the LRTDepositPool doesn’t call depositAsset and therefore doesn’t trigger the rsETH minting path, so use the supported deposit action that includes the asset address, amount, minimum rsETH, and referral field, then verify the resulting AssetDeposit and rsETH Transfer events in the same transaction receipt.