Does checking a Convexfinance staked balance require a wallet signature?

Reading a mainnet reward contract's balanceOf value does not require a wallet signature. The query uses the public account address and contract address. A read or simulation does not commit a transaction. Deposits, withdrawals, and claims are separate operations that change state, so a signature request should correspond to an intended operation rather than a simple balance inspection.

Who receives rewards if another address triggers the claim?

The mainnet BaseRewardPool claim with an account argument pays that specified beneficiary, even when someone else submits the transaction. The caller does not become the recipient merely by paying for execution. This explains why a reward payment can appear without an outgoing claim transaction from the beneficiary. Forwarding features in other implementations require separate interpretation.

Where is the stake recorded after a stakeFor transaction?

The mainnet BaseRewardPool records a stakeFor deposit under the beneficiary address supplied to the function. It takes the staking tokens from the caller and credits the beneficiary with the position. Checking only the sending address can therefore show no increase. The recipient argument matters because this operation transfers ownership of the staked position.

Will revoking token approval withdraw an existing stake?

Revoking an ERC-20 allowance does not withdraw an existing stake. An allowance governs a spender's permission to transfer wallet-held tokens; the reward contract maintains the staked position separately. A completed revocation may prevent a later deposit that requires that permission. It does not prove that any principal or reward tokens returned to the wallet.

Are already accrued rewards lost when withdrawing without claiming?

Mainnet BaseRewardPool preserves accrued base rewards when a withdrawal uses claim set to false. The contract updates reward accounting before reducing the stake, leaving the recorded entitlement available for a subsequent claim. Future accrual reflects the remaining stake. This behavior concerns that contract implementation and should not be generalized to every wrapper or locked position.

Can a successful claim transaction transfer no base reward?

A mainnet BaseRewardPool claim can succeed when the account has no base reward payable. Its payment branch runs only when the earned amount is greater than zero. Extra rewards may still be processed when enabled. Transaction success therefore establishes successful execution, while the emitted events and token transfers establish whether an actual payment occurred.

Convexfinance

Convexfinance staked balances and claimed reward verification

Convexfinance records pool stakes separately from claimable rewards, so a standalone pool reward claim should leave the staked balance unchanged. Verify the position in its matching reward contract, then reconcile the claim transaction with the recipient's token transfers. A falling reward estimate alone does not prove that the expected tokens reached the intended address.

2026.09.10 - updated

The useful starting record contains the account, network, pool contract, and balances before the transaction. Contract differences matter: mainnet Curve pool receipts, sidechain positions, cvxCRV staking, and vote locking do not share one universal balance or withdrawal method.

Account and pool identity determine the balance

A balance check answers the right question only when the account and reward contract belong to the same position.

The account credited with the stake

For a mainnet Curve LP position, the Booster's poolInfo entry identifies the underlying LP token, deposit token, and main reward contract. The crvRewards field identifies that reward contract. Its balanceOf(account) reports the amount staked for the specified account. Reading the LP token's wallet balance answers a different question: how many unstaked LP tokens that address holds.

The network and observation block

Record the network and block alongside each read. Comparing values from different blocks can introduce changes that occurred between observations. A transaction receipt identifies its execution block; a contract read at a selected block gives a reproducible balance. An unavailable historical read is an access limitation, not evidence that the position was empty.

Staked amounts and wallet receipts occupy different records

A mainnet deposit can leave a deposit token in the wallet or stake it immediately in the reward contract. The deposit's _stake argument controls that choice. A successful deposit transaction therefore does not, by itself, establish that the account has an earning stake. The receipt-token balance and reward-contract balance resolve that distinction without requiring another deposit.

A wallet-held receipt represents the underlying LP deposit. Once staked, the reward contract records the position. Keep those quantities separate when reconciling holdings; counting the deposited principal again as both a wallet asset and a staked asset overstates the position. The relevant ownership record must be established before authorizing a claim or withdrawal.

Standalone reward claims leave the principal in place

In the mainnet BaseRewardPool implementation, a standalone reward claim does not reduce the account's staked balance. The claim settles accrued rewards for the beneficiary. A combined withdrawal-and-claim transaction has different expected balance changes, so the transaction's actual method matters.

Check the successful receipt and stake against the staking account, and match reward transfers to the recipient selected by the executed method. An unchanged stake is expected after a standalone claim.

The amount shown before signing is a snapshot. Additional accrual before execution can change the payout. Later blocks can also show newly earned rewards after settlement, so a small nonzero claimable balance does not necessarily mean the previous claim failed. Compare the executed transfer with the transaction's reward events rather than demanding that a later dashboard display remain zero.

For token-by-token reconciliation, the closing wallet balance equals the opening balance plus incoming transfers minus outgoing transfers over the interval. Include unrelated transfers during that interval. Keep the network's transaction charge separate from reward-token quantities; a total portfolio valuation obscures these movements.

Reward token identity resolves missing-payment reports

The reward contract and transaction logs identify the assets paid, while a dashboard may combine several rewards into one display.

Base reward amounts

The mainnet reward contract's rewardToken() identifies its base reward token, and earned(account) reports the corresponding accrued amount. That amount is denominated in the token's units, not dollars. ERC-20 balances use integer units; apply the relevant token's decimals before comparing a raw contract result with a formatted wallet quantity.

Additional reward contracts

Extra rewards use linked contracts with their own accounting. Their balances are not additional deposits of principal. A base reward read therefore does not establish the complete payout across every incentive token. Mainnet CRV claims also invoke the Booster's CVX minting callback separately from linked extra rewards. Any CVX minted belongs in the reconciliation, but a CRV payment does not guarantee a positive CVX amount: minting depends on operator authorization and the supply-based minting rules. Identify the linked rewards and match each payment to its actual token contract.

Some extra-reward contracts expose a wrapper through rewardToken(). The wrapper's underlying token determines the asset ultimately transferred. An accounting wrapper address and a wallet payout token can therefore differ without indicating a missing payment.

Transaction arguments control staking and reward inclusion

The same pool supports actions with different outputs, and its Boolean arguments determine whether staking or additional claiming accompanies them. Before signing, check these arguments on the mainnet method being called.

Overview: Transaction arguments control staking and reward inclusion
Parameter	Accepted setting	Effect	Applicable operation
`_stake`	`true` or `false`	Stake the deposit immediately or retain its receipt token	Mainnet Booster deposit
`_claimExtras`	`true` or `false`	Include or skip linked extra rewards	Mainnet BaseRewardPool claim with arguments
`claim`	`true` or `false`	Include or skip reward claiming during withdrawal	Mainnet BaseRewardPool withdrawal

The no-argument mainnet getReward() includes extra rewards. Interpret a receipt using the method actually called, including any surrounding contract operations. These settings do not establish the behavior of every staking wrapper, cvxCRV contract, or vote-locking position.

Pending transactions and failed execution need different responses

A submitted transaction has not completed the claim until successful execution appears in a receipt. A missing receipt can mean the transaction remains pending or the queried node does not know it. Confirm the network and transaction identity before treating a blank result as failure.

A reverted transaction does not retain its attempted contract changes, although execution can consume gas. Refreshing the interface cannot reverse a confirmed transaction. Before retrying, resolve the reported failure and inspect whether another transaction already completed the intended action. A successful transaction that called a different method also needs investigation; its success status alone cannot establish the expected payout.

Pending transactions and failed execution need different responses: A submitted transaction has not completed the claim until successful execution appears in a receipt.; A missing receipt can mean the transaction remains pending or the queried node does not know it.; Confirm the network and transaction identity before treating a blank result as failure. — Diagram: Pending transactions and failed execution need different responses

View image file

Sidechain reward pools require their own interpretation

The sidechain ConvexRewardPool implementation represents the staked position as an ERC-20 token and accounts for harvested rewards differently from mainnet BaseRewardPool. Its earned(account) operation can perform state-changing work. Balance software must simulate that operation through an appropriate read call when requesting an estimate, rather than send a transaction merely to inspect rewards.

Some deployments support reward forwarding or a persistent reward redirect. The forwarding overload requires the staking account to submit the call. It selects a recipient for that call only; someone else can trigger a regular claim that pays the staking account unless a persistent redirect is configured. Where supported, that redirect also applies to regular claims. Reconcile transfers against the configured recipient and the deployed contract's capabilities. Redirect support is deployment-specific, so its availability cannot be inferred from the platform name alone.

Withdrawal completion depends on the returned token

Mainnet BaseRewardPool's withdrawAndUnwrap returns the underlying Curve LP token. Its plain withdraw returns the Convex deposit token instead. The sidechain ConvexRewardPool's plain withdrawal returns the Curve LP token, which makes copying the mainnet interpretation inappropriate.

A withdrawal record should reconcile the reduction in stake with the token received and any rewards claimed alongside it. A remaining deposit token still represents an LP deposit; an LP token still represents exposure to its underlying pool. Neither balance establishes that the pool's constituent assets have reached the wallet. Returning those assets requires the applicable liquidity-removal operation, beyond the staking withdrawal itself.

Details worth knowing about Convexfinance

Does checking a Convexfinance staked balance require a wallet signature?: Reading a mainnet reward contract's balanceOf value does not require a wallet signature. The query uses the public account address and contract address. A read or simulation does not commit a transaction. Deposits, withdrawals, and claims are separate operations that change state, so a signature request should correspond to an intended operation rather than a simple balance inspection.
Who receives rewards if another address triggers the claim?: The mainnet BaseRewardPool claim with an account argument pays that specified beneficiary, even when someone else submits the transaction. The caller does not become the recipient merely by paying for execution. This explains why a reward payment can appear without an outgoing claim transaction from the beneficiary. Forwarding features in other implementations require separate interpretation.
Where is the stake recorded after a stakeFor transaction?: The mainnet BaseRewardPool records a stakeFor deposit under the beneficiary address supplied to the function. It takes the staking tokens from the caller and credits the beneficiary with the position. Checking only the sending address can therefore show no increase. The recipient argument matters because this operation transfers ownership of the staked position.
Will revoking token approval withdraw an existing stake?: Revoking an ERC-20 allowance does not withdraw an existing stake. An allowance governs a spender's permission to transfer wallet-held tokens; the reward contract maintains the staked position separately. A completed revocation may prevent a later deposit that requires that permission. It does not prove that any principal or reward tokens returned to the wallet.
Are already accrued rewards lost when withdrawing without claiming?: Mainnet BaseRewardPool preserves accrued base rewards when a withdrawal uses claim set to false. The contract updates reward accounting before reducing the stake, leaving the recorded entitlement available for a subsequent claim. Future accrual reflects the remaining stake. This behavior concerns that contract implementation and should not be generalized to every wrapper or locked position.
Can a successful claim transaction transfer no base reward?: A mainnet BaseRewardPool claim can succeed when the account has no base reward payable. Its payment branch runs only when the earned amount is greater than zero. Extra rewards may still be processed when enabled. Transaction success therefore establishes successful execution, while the emitted events and token transfers establish whether an actual payment occurred.