Lido fi staking starts with ETH input checks and ends with stETH receipt confirmation

From ETH input to a confirmed stETH balance

The normal path begins with a connected Ethereum account that holds enough ETH for both the stake and network gas. Enter the intended amount, inspect the quoted result and open the wallet prompt. Nothing has moved at this stage, so rejecting the prompt leaves the wallet unchanged.

The wallet signature is the commitment boundary. It authorizes a transaction carrying the chosen ETH value to the staking contract. Once broadcast, the transaction can remain pending, succeed or revert. Only a successful receipt establishes that the staking call changed the on-chain state.

After confirmation, compare the stETH balance with its value before the transaction. The new balance should reflect the minted position, subject to the share-based rounding used by stETH. A wallet interface may need a refresh or a verified token import before it displays that balance.

If the wallet shows the wrong network, account, ETH amount or destination, reject the request and rebuild it. When a submitted transaction fails, inspect its receipt before trying again. Sending another stake without identifying the first transaction's state can create an unintended duplicate if the original remains pending.

Inputs that belong in the preflight

A useful preflight ties every visible input to the state that will exist after confirmation. The staking amount alone is not enough. The sender, network and transaction target determine where the ETH leaves and where the resulting stETH appears.

• The wallet must be connected to Ethereum mainnet for the direct staking transaction.
• The selected account must be the account intended to receive stETH.
• The ETH input must exclude enough ETH to pay the network gas charge.
• The transaction value must match the amount shown on the commitment screen.
• The destination and requested action must match the expected staking call.

Wallet state

The connected account supplies both the staked value and the gas payment. Switching accounts after entering an amount can invalidate the estimate or expose a different balance. Recheck the active address whenever the wallet reconnects or the page resumes from an earlier session.

Spendable ETH

Gas is charged in addition to the ETH sent for staking. Selecting the wallet's entire displayed balance can therefore fail before broadcast or leave the transaction unable to meet its fee requirement. The live gas estimate belongs beside the stake amount during review.

Receiving account

Direct submission mints stETH to the transaction sender. The receiving account is not a separate field in the ordinary direct route, so the active wallet address determines ownership of the minted tokens.

Protocol state

New submissions are subject to the protocol's current staking configuration. The available amount can change because the staking limit refills over time, becomes exhausted or is set to zero while staking is paused. A previously prepared amount is not proof that the same amount remains acceptable when the transaction is finally sent.

What changes when the wallet signs?

Signing authorizes the exact transaction displayed by the wallet, including its sender, destination, ETH value and fee settings. Connecting a wallet or typing an amount does not move funds. After broadcast, the transaction has a hash and enters Ethereum's pending state. A wallet may support replacement or cancellation while it is pending, but neither action is certain to win inclusion. A confirmed transaction cannot be edited.

View full-size image

Reading the commitment screen

The commitment screen should show the ETH value separately from the estimated network fee. Adding the stake amount to the estimated fee shows the current projected balance requirement more clearly than the stake field alone. The fee estimate can change before inclusion, and the wallet's maximum fee is a ceiling rather than a promise that the entire amount will be spent.

Check the sending account and Ethereum network again inside the wallet. Browser content can be stale, while the wallet prompt represents the transaction that will actually be signed. A mismatch between the page and wallet is a reason to reject the request.

Direct staking spends native ETH through a payable contract call. It does not require an ERC-20 approval for the ETH input. The wallet should therefore present a transaction carrying ETH, not an unrelated token allowance. Other routes may add their own steps, so their prompts should not be treated as evidence for the direct path.

The displayed stETH estimate describes the expected token result, not transaction completion. Reject any prompt whose amount, target or action differs from the prepared stake. Reopening the transaction with corrected inputs is safer than signing first and trying to interpret the discrepancy afterward.

Receipt status before token display

The Ethereum receipt answers whether the staking call succeeded, while the token balance answers what the account now holds. These checks complement each other. An interface success message does not replace the on-chain status.

Successful, pending and reverted states

The confirmed transaction and its successful receipt identify the sender, destination, ETH value, gas used and block that included it. A successful direct ETH submission mints stETH to the sending address. A pending transaction has not yet established that result. A reverted transaction records the failed execution and its gas use but does not apply the intended stake or mint.

Token-side evidence

Read the stETH balance for the same address that sent the transaction. Comparing balances immediately before and after confirmation isolates the mint from later balance changes. If the wallet hides the asset, a reliable Ethereum account view can still expose the token balance without requiring another transaction.

Balance changes and share rounding

The protocol accounts for stETH through shares. A direct ETH deposit mints stETH on a 1:1 accounting basis, but conversion between shares and the displayed token balance uses integer arithmetic. A tiny wei-level difference can therefore appear without showing that the whole stake failed.

Measure the receipt against the change in balance rather than expecting a second incoming transfer. The mint belongs to the successful staking transaction. Later rebases change the displayed stETH balance without creating an ordinary transfer for each holder.

Wallets can cache token data, omit unfamiliar assets or round the visible number to a few decimal places. Refresh the account and inspect more precision before assuming tokens are missing. Never use a similarly named token as a substitute for the verified stETH asset.

Recovering when stETH does not appear

Start with the transaction hash when the expected stETH balance is absent. A successful receipt narrows the issue to account selection, token recognition or stale display data. Refresh the wallet, select the original sender and inspect that address's verified stETH balance.

A pending transaction needs resolution before another stake is created. Check whether it remains in the pending pool, was replaced by another transaction using the same nonce or was never broadcast. A local wallet notification does not prove network inclusion.

A reverted transaction did not produce stETH. The receipt records the failure, while transaction details or an available execution trace may identify an out-of-gas execution or a rejected contract call. Direct submissions can also fail when new staking is paused or the current staking limit is exhausted. Recheck the live inputs and availability before preparing a fresh transaction.

If a successful transaction came from a different wallet account, the stETH belongs to that sending address. Changing the currently displayed account will not move it. Restore access to the original sender and confirm its balance instead of submitting more ETH from the replacement account.

Separating receipt from later rewards

The initial stETH receipt and later staking balance updates are different events. Confirmation should be visible as a successful staking transaction and an immediate token balance change. Waiting for a later accounting update is not necessary to prove that the stake completed.

stETH is rebasing, so its displayed balance normally changes when the protocol processes an accounting report. Those updates depend on the report process and may be delayed when a report is not finalized. They do not appear as daily incoming wallet transactions. A wallet that tracks transfers alone can therefore miss the balance change until it refreshes its token data.

Records that preserve the confirmation trail

Keep the transaction hash, sending address, confirmed status, block, submitted ETH value, gas used and stETH balance change together. This record separates the principal sent to the staking contract from the network cost and gives a later wallet reconciliation a fixed starting point.

The sender's transaction history and nonce can show whether a pending attempt was replaced, while a failed receipt records the gas consumed by the call. On Ethereum, a successful transaction hash and the post-transaction stETH balance form the clearest durable pair.