Rebasing two-track share-accounting drift: measure the SIGN, not just existence

Date: 2026-06-10 Banked from: Cycle 206 - Paxos stablecoin ClaimableRewards (Cantina $1M) Class: rebasing-shares / multiplier accounting

The pattern

Rebasing reward systems often keep REDUNDANT accounting tracks: - per-wallet shares (wallet.shares) - a group/global aggregate (payoutGroup.shares, totalShares, etc.)

For gas, hot paths add "net change is zero" optimizations that update one track but SKIP the other (Paxos same-payout-group transfer: recomputes both wallets' shares, skips the group aggregate, comment literally says "net change is zero").

Under floor division in balance<->shares conversion, the skipped aggregate WILL drift from the true sum of the per-wallet track. Drift existence is near-certain. That alone is NOT a finding.

The finding/non-finding hinges on TWO things

1. SIGN of the drift. - sum(per-wallet) > aggregate -> the per-wallet track over-claims relative to the aggregate. If both tracks draw the same reward/claim source, the larger track can over-draw = DRAIN. This is the exploitable direction. - sum(per-wallet) <= aggregate (protocol-favorable) -> per-wallet claimers lose rounding dust; aggregate-based claims over-pay bounded dust from the protocol's own (usually monitored) funds. Safe rounding convention. WALK.

2. REACHABILITY of the dangerous sign by an UNTRUSTED caller, and whether the larger track funds an attacker-controllable withdrawal. If the aggregate-claim path (e.g. claimAll) is gated to trusted roles, even an over-paying aggregate is fenced.

Method that worked (and the trap it avoids)

Step 1: Replicate the EXACT skipped-update accounting in a pure Foundry harness using the real library functions (SharesLib.updateSharesWithRewardPreservation here). Step 2: Fuzz a SINGLE one-way operation for a positive excursion. -> Paxos showed netDelta = +1 dust here. LOOKS like a bug. STOP HERE = over-report. Step 3: CRITICAL - test SUSTAINED + adversarially-steered accumulation (thousands of ops). Does the positive excursion PERSIST/GROW, or wash out? -> Paxos: +1 single-step washed to max-excursion -1 and final -9937 over 6000 ops; 10k-run round-trip fuzz never produced net > 0. Drift is strictly protocol-favorable. Correct verdict: WALK CLEAN.

The trap: a naive auditor sees the +1 single-step excursion and files a "share inflation / claim-source drain" report. A rigorous one runs the accumulation test, sees the sign is protocol-favorable and the drain direction is unreachable, and downgrades honestly.

Reusable checklist for any rebasing/shares target

• [ ] Enumerate every accounting track (per-account, per-group, global).
• [ ] Find hot-path optimizations that update one track but not another ("net zero", "skip aggregation"). Those are the drift sources.
• [ ] Identify which track funds each WITHDRAWAL path (individual claim vs batch/claimAll).
• [ ] Replicate the skipped-update math in a pure harness.
• [ ] Fuzz single-step for positive (drain-direction) excursion.
• [ ] THEN accumulate thousands of steered ops; check if the dangerous sign persists.
• [ ] Check who can trigger the larger-track withdrawal (trusted role -> fenced).
• [ ] Only file if: dangerous sign reachable by untrusted caller AND larger track funds an attacker-controllable withdrawal.

Cross-references

• Honest-downgrade doctrine: VULNERABLE-looking-direct != EXPLOIT-VIABLE-via-cascade.
• "NOT-EXPLOITABLE-empirically" is a valid intermediate verdict (Cycle 87-92 banked rules).