# Claim cursor not advanced

Payout reads a last-updated marker but never advances it, so value is paid twice or skipped

_Area: DeFi accounting and math bugs. Seen in 3 disclosed reports; latest 2025-07-12. Updated 2026-10-24._

## How it works

A payout or accrual path reads a "last updated" marker (timestamp, epoch cursor, claim count) to decide how much is owed, but the marker is not advanced correctly. Either it is never written, written only on a special path, or written past the range that was actually paid. The next call recomputes against the same stale marker and pays again, or the marker jumps ahead and skips value the user was owed. The broken assumption: that the marker always equals the state the payout was computed from. The canonical cases are a marker never written [E2](https://bugbountylibrary.com/r/dhl%3A20250108-lpmine.md) and a marker refreshed only on one special path [E1](https://bugbountylibrary.com/r/sherlock%3A2025-07-mellow-flexible-vaults%3AH-4.md).

## Where it shows up

- A batch loop calling a per-item fee/interest accrual that shares one "last updated" timestamp, refreshed only on a special item [E1](https://bugbountylibrary.com/r/sherlock%3A2025-07-mellow-flexible-vaults%3AH-4.md)
- Reward math using a live balance (e.g. pair balance) plus a last-claim time that is not updated on claim [E2](https://bugbountylibrary.com/r/dhl%3A20250108-lpmine.md)
- A claim cursor advanced to the current epoch while emission computation is capped by a mutable end-epoch [E3](https://bugbountylibrary.com/r/c4%3A2024-11-mantra-dex%3AM-03.md)

## How to review

For every payout, find the marker it reads and the marker it writes, and check they describe the same interval. The invariant: after a successful claim/accrual, the marker must equal exactly the point up to which value was paid, and no more. Check ordering inside loops (is the shared timestamp refreshed per item or once?), and check whether any cap or end-epoch can later move past the cursor. Test repeated claims in the same block and claims after a parameter change.

## Variants seen

- Shared timestamp refreshed only on the base-asset report, so each prior report in a batch re-accrues fees [E1](https://bugbountylibrary.com/r/sherlock%3A2025-07-mellow-flexible-vaults%3AH-4.md)
- Last-claim time never updated, allowing repeated claims within a block [E2](https://bugbountylibrary.com/r/dhl%3A20250108-lpmine.md)
- Cursor advanced past a cap that can later be extended, stranding rewards [E3](https://bugbountylibrary.com/r/c4%3A2024-11-mantra-dex%3AM-03.md)

## Impact and severity

Excess shares minted to a fee recipient [E1](https://bugbountylibrary.com/r/sherlock%3A2025-07-mellow-flexible-vaults%3AH-4.md), repeated reward claims draining funds [E2](https://bugbountylibrary.com/r/dhl%3A20250108-lpmine.md), and permanently unclaimable rewards [E3](https://bugbountylibrary.com/r/c4%3A2024-11-mantra-dex%3AM-03.md). Severity rises when the path is repeatable in one block or when the skipped range can never be recovered.

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2025-07-mellow-flexible-vaults%3AH-4.md
- E2: https://bugbountylibrary.com/r/dhl%3A20250108-lpmine.md
- E3: https://bugbountylibrary.com/r/c4%3A2024-11-mantra-dex%3AM-03.md