Skip to content

Fix: stop offering reward withdrawals that move no tokens - #115

Merged
koenmtb1 merged 1 commit into
AztecProtocol:mainfrom
y3v63n:fix/warehouse-dust-threshold
Sep 15, 2026
Merged

koenmtb1 merged 1 commit into
AztecProtocol:mainfrom
y3v63n:fix/warehouse-dust-threshold

Conversation

@y3v63n

@y3v63n y3v63n commented Sep 14, 2026

Copy link
Copy Markdown
Contributor

What this fixes

A user with no rewards left can still see a claimable balance and a working "withdraw" button. They click it, pay gas, and nothing arrives in their wallet. Repeating it does not help.

This came from a support ticket. The user had already claimed their rewards months earlier. The dashboard still showed a pending withdrawal, so they kept trying.

Why it happens

Every split contract permanently keeps 1 wei of the reward token after it distributes. So a warehouse that has been fully withdrawn still reports a balance that is greater than zero — but far too small to be worth anything.

The claim cart already has a shared dust threshold (half a token) for exactly this situation. The warehouse checks did not use it. They tested only "greater than zero", so the 1 wei residue counted as a real reward.

The change

Four places now use the existing dust threshold instead of a bare "greater than zero" test:

  • the "Ready to withdraw" row in the claim-all summary, and the total it feeds
  • the withdrawal step queued by the claim-all modal
  • the enabled state of the per-delegation claim button, and the withdrawal it queues
  • the highlight on the warehouse figure in the delegation breakdown

What does not change

  • A distribute queued in the same batch still schedules its withdrawal, so newly distributed rewards behave exactly as before.
  • The delegation breakdown still shows the true on-chain warehouse balance. Only the highlight that made the residue look claimable is dropped.
  • The threshold value is unchanged; this reuses getRecoveryDustThreshold.

Testing

Type-check and lint pass.

Every split contract keeps 1 wei of the reward token after it distributes.
A user who has already withdrawn everything therefore still reads a
non-zero warehouse balance, and the dashboard treated that residue as a
claimable reward: the summary showed a "ready to withdraw" row, the claim
button stayed enabled, and the queued transaction spent gas to move an
amount too small to see.

The claim cart already has a shared dust threshold (half a token) for
exactly this case, but the warehouse checks used a bare "greater than
zero" test instead. Apply the same threshold to them.

A distribute queued in the same batch still schedules its withdrawal, so
freshly distributed rewards are unaffected. The delegation breakdown keeps
showing the true on-chain balance and only drops the highlight that made
the residue look claimable.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@y3v63n
y3v63n requested a review from a team as a code owner September 14, 2026 08:43
@koenmtb1
koenmtb1 merged commit 996d094 into AztecProtocol:main Sep 15, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants