Aura finance pool withdrawal balances and remaining positions
Aura finance entered wind-down with withdrawal-only pools, making remaining staked units and received tokens the relevant measures of a pool exit. A completed withdrawal should reduce the intended position and deliver the output specified by that operation. A zero dashboard value alone cannot establish either result, especially when the display combines token quantities with estimated prices.
The wind-down announcement separates pool withdrawals from token-holder redemptions. Tracking a pool exit therefore starts with its own balance and receiving account, without treating a redemption status elsewhere as evidence that the liquidity position has closed.
A completed pool withdrawal matches the reduction in staked units to the correct tokens received by the designated wallet.
Match the selected pool to the withdrawal record
Begin with the account that owns the stake and the exact pool contract holding it. Record the staked quantity before withdrawal, the intended output token and the receiving account. Those details establish what a completed operation should change. After execution, compare the reduction with the transaction's withdrawal amount and the corresponding token transfers. Keep quantities in their own units: a pool share, a receipt token and a currency valuation describe different things.
The pool's reward contract provides the account-level staked balance through
balanceOf(account). A wallet's ordinary token list does not necessarily describe that same position.
Read the balance fields in their own units
The useful distinction is between the remaining stake, the withdrawal output and any separate reward entitlement.
Position quantity
The remaining stake measures the position still recorded for an account in the selected reward pool. Compare it with the quantity that the withdrawal removed. A partial withdrawal legitimately leaves a positive balance. Full closure requires an exact zero for that position, rather than a display that rounds a small remainder down.
Received quantity
Token identity
Match the received token to the selected operation's output. The Booster maintains separate fields for a pool's underlying LP token, deposit token and reward contract. These relationships explain why similarly named balances can represent different parts of the same holding.
Account and observation time
Compare balances for the designated receiver around the withdrawal transaction. A later transfer can change its wallet balance again. Retaining the receipt preserves the original incoming amount even when the wallet subsequently holds fewer tokens.
Unstaking and receiving the underlying pool token
In BaseRewardPool, the two-argument withdrawal returns the staking token, while withdrawal with unwrapping routes the underlying LP token through the Booster. These operations leave different wallet holdings. Receiving a Balancer Pool Token, or BPT, also differs from receiving the individual assets represented by that pool token. The withdrawal method determines which balance should increase.
A remaining balance after a requested full withdrawal
Consider a hypothetical position with 13.7 pool shares and a request to withdraw the entire stake. Assume the selected reward pool uses BaseRewardPool4626, the owner calls redeem(shares, receiver, owner) to receive underlying pool tokens and the receiving wallet has no pre-existing underlying pool tokens. All amounts and observed display states in this example are hypothetical.
That implementation converts shares to underlying pool-token units at 1:1. The expected completed output is therefore 13.7 pool tokens, with zero shares remaining. This relationship concerns token quantities, not their monetary value.
Suppose the dashboard continues showing the original stake. Refreshing the balance for the same account and contract is a reversible check that requires no new withdrawal.
If the full withdrawal succeeds, the receipt records 13.7 shares redeemed and the refreshed stake reads zero. The receiving wallet shows 13.7 pool tokens. No additional principal withdrawal remains for this position.
If the owner instead submitted 9.4 shares despite intending a full withdrawal, a successful redemption removes 9.4 shares and leaves 4.3 shares. The subtraction, 13.7 minus 9.4, explains the remainder. After confirming that 4.3 shares remain, the owner can redeem those shares to the same receiver. Once that transaction succeeds, verify zero remaining shares and receipt of another 4.3 pool tokens, bringing the total received to 13.7. Repeating the original amount would exceed it. The conversion rule stayed constant; the amount executed changed.
Why does a balance remain after a successful transaction?
A successful transaction can remove only part of a stake or perform a different operation entirely. Its success status establishes execution, while its method and logs identify what occurred. Read those details before treating a positive balance as a failed exit. An approval or reward claim, for instance, does not establish that the principal left the pool.
An Ethereum transaction receipt includes an execution status and the logs generated by that transaction. A pending transaction has no completed receipt. Balance comparisons also need a consistent observation point: a read from before inclusion cannot show the withdrawal's completed effects.
A display refresh cannot repair an execution failure. It can resolve a stale view before another transaction introduces further changes.
Keep reward balances separate from withdrawn principal
A zero staked balance can coexist with accrued rewards that the withdrawal did not claim. BaseRewardPool tracks earned rewards separately and provides withdrawal methods with a claim option. An exit record should distinguish the principal returned from reward tokens received or left claimable. Adding unlike token quantities into one total obscures which obligation remains.
An old rewards estimate cannot establish an incoming transfer. For reconciliation, the useful amount is the reward actually paid by the completed claim, alongside any remaining entitlement. Keep this separate from the principal withdrawal even when one transaction performs both operations.
Close the pool record at the intended output
The principal withdrawal record is complete when the intended stake reduction matches delivery of the specified output. For a full exit, record the exact remaining stake as zero and identify any rewards still outstanding separately. Receiving BPT closes an Aura withdrawal into pool tokens; converting those tokens into constituent assets requires a different operation. The final holding should have an explicit identity, such as Balancer Pool Token.
Questions worth asking
Do I need to connect a wallet just to read a pool withdrawal balance?
Reading a public contract balance does not require signing a transaction. A read-only interface can query the reward contract using the owning account's address. Connecting a wallet may help an application select that address, but observation and authorization remain separate. Monitoring a position does not itself require permission to move tokens.
Why does totalSupply show a balance after my pool withdrawal?
The reward pool's totalSupply measures the aggregate staked supply rather than your individual position. Other accounts can retain stakes after yours reaches zero. Use balanceOf with the owning account to assess your remainder. A nonzero pool-wide total does not establish that your withdrawal left principal behind.
Which token should I track for an extra pool reward?
Track the underlying reward token that the claim actually transfers. Some Aura extra-reward contracts use a StashToken wrapper internally, with baseToken identifying the underlying token. That internal wrapper is not an ordinary wallet asset. Matching the transfer to the underlying token prevents an accounting wrapper from appearing as a missing payout.
Is the transaction recipient always the wallet receiving my withdrawal?
The transaction recipient can be the contract handling the withdrawal rather than the wallet receiving tokens. Identify the token recipient from the operation's receiver parameter, where applicable, and its transfer records. Treating the top-level transaction destination as the payout address can make a correctly delivered withdrawal look misdirected.