Aurafinance Legacy Reward Claims Without Stake Withdrawals

Did claiming rewards also withdraw the stake?

A standalone AuraBalRewardPool claim changed reward accounting without reducing the account’s recorded stake or returning its deposited liquidity tokens. The contract kept those amounts in separate records. Its claim method selected the destination of accrued rewards; its withdrawal method selected how much staking principal to return.

Claims with the stake unchanged

The standalone getReward(bool _lock) method refreshed the caller’s accrued reward and cleared the amount that it settled. It didn’t subtract from the caller’s staking balance.

Principal withdrawals with rewards retained

The withdraw(amount, false, lock) form updated reward accounting before reducing the stake. Because its claim flag was false, it left accrued rewards unclaimed. The final lock argument didn’t trigger a reward lock when the optional claim call was skipped.

Withdrawals with an included claim

The withdraw(amount, true, lock) form returned staking tokens and invoked the reward method within the same call. A combined exit therefore didn’t require separate withdrawal and claim transactions in this implementation. The chosen reward destination still governed settlement of the accrued reward.

Unlocked rewards and the claim deduction

The unlocked branch of AuraBalRewardPool reduced the reward payout, leaving the staking principal outside that deduction. The legacy AuraBalRewardPool implementation calculated an unlocked-claim deduction of 30% of the accrued reward, using integer arithmetic. Its expression was (reward * 3) / 10 in the reward token’s smallest units. Integer division rounded down, and the wallet received the gross reward minus that calculated deduction. The contract added the withheld amount to its pending-penalty counter.

This rate belonged to that pool’s unlocked-claim branch. It wasn’t a uniform fee across the protocol’s reward contracts.

Locking rewards beside the original stake

The lock-enabled AuraBalRewardPool claim routed the accrued reward into the configured AuraLocker while leaving the original pool stake unchanged.

The reward’s destination

The reward pool increased its allowance for AuraLocker and called the locker on behalf of the claimant. That branch passed the accrued reward into the lock method without applying the unlocked-claim deduction. The claimant didn’t receive that reward as a liquid wallet payout from this branch. Successful settlement depended on the selected locker accepting the incoming tokens and recording the lock.

The original pool balance

The pool’s staking balance and the newly locked reward belonged to separate positions. A reward lock didn’t itself withdraw the deposited liquidity tokens or reduce their recorded stake.

Accrued rewards after the distribution period

AuraBalRewardPool’s one-time reward distribution used a 14-day duration from initialization, and reward accrual stopped advancing at its recorded period finish. That duration described the distribution schedule, rather than a countdown starting with each depositor’s stake.

The accrual cutoff

The reward calculation used the earlier of the current timestamp and periodFinish . During the funded period, the account’s stake and the changing reward-per-token value determined its entitlement. Once that period ended, additional elapsed time didn’t create another scheduled reward allocation. A later claim settled the entitlement that the accounting retained.

Balances retained for settlement

The end of the distribution period didn’t itself clear the account’s accrued reward. A withdrawal without a claim also checkpointed rewards before decreasing the stake. The account could therefore retain an entitlement after principal returned. A retained entitlement still needed a successful settlement path, including the locker’s acceptance of any new reward lock.

Reward events and actual token receipts

AuraBalRewardPool’s RewardPaid event recorded the gross reward, including when the unlocked branch transferred a smaller amount. The event also recorded the selected lock flag. A gross event amount therefore couldn’t, by itself, describe the claimant’s liquid wallet receipt. The reward-token transfer identified the amount delivered through the unlocked branch. A lock-enabled claim instead credited a locker position, so its reward amount described tokens routed into that position.

The Withdrawn event concerned returned staking principal. Its amount belonged to the staking token, while the reward event concerned the reward token. Adding those quantities would mix separate assets and accounting purposes.

Locker rewards and locked AURA principal

AuraLocker maintained reward entitlements separately from locked principal, and its ordinary claim method processed the configured reward tokens. Vote locking concerned the AURA position; claiming a distributed reward didn’t itself release that position. The locker updated reward accounting, cleared each reward amount that it paid, and transferred that token to the designated account. Its claim routine didn’t reduce the recorded locked balance.

Open full-size image

Different methods used different meanings for their boolean argument. AuraBalRewardPool’s argument chose whether to lock its reward. AuraLocker’s reward-staking branch applied to one configured reward token and required the caller to be the reward owner. Neither argument meant that a claim automatically unlocked the original AURA principal. Principal release belonged to the lock-processing methods, whose conditions differed from reward settlement.

Withdrawal-only pools and remaining entitlements

The protocol’s sunset placed pools in withdrawal-only mode, with existing LP, vault, and locker positions remaining withdrawable. Historical claim methods explain the separate reward and principal balances, without creating a new deposit or reinvestment path. AURA treasury redemption and auraBAL backing redemption also concern different holdings from a pool’s pending rewards. Keeping an old staking balance in place didn’t restart AURA emissions.