Mantle staked positions reveal their progress through receipts, balances and redemption records

Receipts, balances and request records answer different questions

The receipt proves execution, the balance proves custody and the request record locates a redemption within its lifecycle.

Use each record for the job it can settle. A stake receipt shows whether Ethereum accepted or rejected the transaction, while the mETH transfer shows the receiving address and amount. An unstake receipt should identify a request and show mETH moving from the requester into the request manager. That movement is expected: the tokens remain locked for the request and don’t represent ETH already returned. Later, the request record supplies the recorded ETH amount, finalization state and filled amount. No single wallet screen proves all of those stages.

The prerequisite check begins with address and network

The address-network pair must match before any status label becomes useful. Direct protocol staking and redemption occur on Ethereum L1, so an mETH balance shown on Mantle doesn’t satisfy an Ethereum balance check. For a stake, the address needs the intended ETH amount plus ETH for gas. For an unstake request, it needs mETH, ETH for gas and authorization through an existing allowance or a supported permit. The quoted minimum output must also remain compatible with the contract’s conversion when the transaction executes.

View image file

Stop if the transaction belongs to another address or network. Changing the wallet’s display network can’t move assets, and submitting the same operation from a second address creates a separate position rather than repairing the first one.

How can I tell whether staking actually finished?

A stake is complete when its Ethereum transaction succeeded and the same address received the mETH amount recorded by the stake event. The transaction status comes first because a wallet can show a submitted operation before a block includes it. Once included, the receipt should contain the stake event and the token movement produced by the mint. The address’s ETH change also includes gas, so subtracting two wallet snapshots is less reliable than reading the event amounts.

If the receipt succeeded but the token list looks empty, inspect the mETH transfer destination and query that address on Ethereum. Wallet software may hide an ERC-20 token until it has been added to the asset list. Match the token contract from the transaction log rather than trusting a symbol search, since an unrelated token can reuse the same symbol.

A failed receipt means the stake didn’t mint mETH, although Ethereum still charged gas for execution. Read the revert or wallet error before trying again. Common causes include an amount below the live minimum, a minimum mETH output that the conversion no longer satisfies, a protocol pause or a transaction that would exceed a configured supply limit.

Pending, failed and replaced transactions need different responses

A pending transaction needs nonce and fee diagnosis, a failed transaction needs input diagnosis and a replaced transaction needs the replacement hash. Don’t submit a fresh stake merely because the first one remains pending; both can confirm if they use different nonces. A speed-up or cancellation normally replaces the same nonce, while a wallet may mark the original as dropped. Follow the final hash through confirmation before checking balances. After a failure, correct the reported cause and retry only that operation.

An unstake request has two readiness tests

An unstake request becomes actionable only after it is finalized and the queue has enough allocated ETH to cover it. The protocol exposes both a finalization flag and a filled amount for the request ID. Time alone can’t prove readiness because finalization follows an oracle record while funding follows liquidity allocated to the first-in-first-out queue.

An unstake request must pass the contract’s configurable block-based finalization check before it can be claimed. The delay isn’t a promised completion time. Available liquidity may fill requests sooner than a validator exit would, while low available liquidity or Ethereum’s validator queue can extend the wait. A displayed estimate shouldn’t replace the request’s live state.

The creation receipt supplies the most durable starting evidence. It identifies the requester, locked mETH, recorded ETH amount, cumulative ETH requested and request ID. Save the ID because it binds later status checks and the claim to this specific request. A lower wallet mETH balance after creation is normal; the request manager holds those tokens until claim or an authorized emergency cancellation.

The filled amount can rise before the request becomes claimable. It shows how much allocation has reached that request’s position in the queue, but the claim path still checks finalization and sufficient cumulative funding. A partially filled display therefore shows progress rather than permission to withdraw part of the recorded amount.

If a front end loses the row, return to the request ID and creation transaction. A blank interface can reflect an indexing or connection problem. It doesn’t establish that the request failed, completed or vanished from the contract. The later claim or cancellation event identifies the actual exit.

Fix only the condition that failed

The useful fix is the smallest change that makes the rejected operation valid. If the wallet lacks ETH for gas, fund the same requester address rather than moving the mETH position. If authorization is missing, add the required allowance or use the supported permit path, then submit the unstake request. An approval receipt alone doesn’t create that request.

When a minimum-output check fails, refresh the conversion and decide whether the new minimum still protects the intended exchange. Don’t set the minimum to zero just to get the transaction through; decide how much output you’re willing to accept. A protocol pause needs no repeated submissions because another transaction can’t bypass the paused contract state. Wait until the operation becomes available, then rebuild the transaction against the live parameters.

A pending operation calls for a nonce-preserving replacement only when the wallet supports it and the original hasn’t confirmed. Once an unstake request succeeds, don’t send another request for the missing wallet balance. The mETH has already moved into the manager, and the valid next action is monitoring the request ID until a claim becomes possible.

Claim reconciliation proves that the exit closed

A claim closes the protocol redemption only when its transaction succeeds and the expected transfer reaches the recorded requester. Claiming a ready request burns its locked mETH and transfers the recorded ETH amount to the requester. The requester must submit the claim from the recorded address and have enough ETH there to pay gas.

Reconcile the event amounts instead of expecting the wallet’s ETH balance to rise by a neat figure. The claim adds the recorded ETH, while the same transaction subtracts gas. Other transfers in the block range can change the balance too. The request’s claim event, the ETH value transfer and the successful receipt together identify closure without relying on a rounded portfolio display.

If a claim simulation or mined transaction fails, reread the two readiness fields before changing anything. A finalized request may still lack full funding. The contract can also reject a different caller, an already claimed ID or a claim submitted while requests and claims are paused. Each condition points to a different response; none is fixed by creating another unstake request.

The final check uses recorded ETH, not a live mETH balance

The final comparison is between the contract’s expected state and its recorded state. A successful stake ends with a mint to the staker. A successful unstake request ends with locked mETH and an open request, which is progress rather than closure. A successful claim ends with the claim event, burned locked mETH and ETH sent to the requester. These checks prove on-chain completion, but they can’t make a queue advance faster or correct an action that used a different address or network.