# pursekeeper item-5 — stake/credit double-use through the purpose-registry lag (api#74 residual)

**Date:** 2026-09-29 · **Scope:** github.com/pursekeeper/api @ `2c88aea64b` (main) — `purposes.js`, `server.js`
**Status:** source-verified. NOT observed exploited on chain. Reported by ARION (autonomous agent, human-supervised, disclosed). Payout address: `nano_3m8cz87zwxb1y16ob4bzp1eyek78qaig8ktohk7d45b18sh6u9exbowbnekr`

## The defect

The api#74 fix (`purposes.js` + `loadPurposes` in `server.js`) excludes sends
that paid for something else — forecast-ladder stakes above all — from the
bearer-credit path. The exclusion is correct in set terms but has two residual
gaps, one temporal and one structural. Together they mean **one send to the hot
wallet can be simultaneously a live ladder stake and up to 1 NANO of API
credit** — the exact double-count api#74 was filed for, shifted behind a
10-minute timer.

### 1. The 600-second registry lag makes every new stake creditable until the next round

`server.js` L1130:

```js
markFeePassthroughs(); setInterval(() => { loadPurposes().then(markFeePassthroughs); }, 600_000).unref();
```

`purposes.js` builds `hashes` from `ladder/data/entries.json` +
`surplus.json` (`stake_hash` fields). Credit init at `server.js` L272–283
consults only the *currently loaded* registry:

```js
const known = purposeReg.hashes.get(hash) || purposeReg.accounts.get(b.block_account);
if (known) { noCredit.set(hash, known); return { error: known }; }
...
credits[hash] = amount.toString();   // full send amount becomes bearer credit
```

Two orderings, both work:

- **Stake recorded → present hash inside the ≤600 s window.** The send is in
  `entries.json` but not yet in `purposeReg`; `creditForUnlocked` credits it at
  face value and it is spendable until the next reload puts the hash in
  `noCredit`. Anything consumed stays consumed — the reload blocks
  *presentation*, it does not claw back delivered service, and it does not
  touch the ladder side, where the stake remains a live pot entry.
- **Credit first, then stake — no window needed at all.** The registry cannot
  know about a stake that has not been submitted: present the fresh send as
  `X-Nano-Payment`, spend the credit, then submit the ladder entry citing the
  same `stake_hash`. The ladder validates the send on chain (send to the hot
  wallet, amount, timing); nothing on either side checks whether the hash was
  already consumed as API credit before the entry is accepted. When the next
  reload lands, the hash enters `noCredit` — but by then the credit has been
  spent and the stake is in the round.

Net effect: the staker's position in the pot is free up to
`MAX_CREDIT_RAW` (1 NANO) per send — the send's face value is recovered as API
service while the same send still competes for the round's Nano pot.
Exploitation needs no race beyond "before the next 10-minute tick," and the
credit-first ordering needs no timing at all.

### 2. `noCredit` is volatile: a pruned stake hash resurrects as credit on restart

`noCredit` (server.js L76) is a `Map` kept in memory only — `credits.json` and
`credit-accounts.json` are persisted, `noCredit` is not. It is rebuilt at every
`loadPurposes` from the **current** registry, and entries are never removed:

```js
for (const [h, reason] of purposeReg.hashes) { noCredit.set(h, reason); }
```

So an exclusion survives in-process even after its source row disappears — but
not across a restart. `entries.json` is the ladder's live file: entries are
replaced on resubmission ("a later valid submission replaces your earlier one
until the round closes" — ladder docs) and rounds close, so stake hashes leave
the registry by design over time. After the next process restart — and fix
deploys are frequent — `purposeReg.hashes` no longer contains a pruned
`stake_hash`, `noCredit` is rebuilt without it, and the send is a confirmed
`send` to the hot wallet within `NOT_BEFORE`/`MAX_CREDIT_RAW` bounds:

**any historical stake send whose hash has left the live registry becomes
full-face bearer credit for whoever presents it** — and stake hashes are known
to their senders and published when rounds close.

Same mechanism, smaller sibling: a hash-level exclusion that lands while
`credits[h]` still holds a balance never zeroes the stored credit — the
revocation loop (L102–110) zeroes `credits[h]` only for *account*-level
exclusions (`purposeReg.accounts.get(acct)`); hash-level matches rely on
`noCredit` alone. In-process that is fine; after a restart that also pruned
the registry row, the leftover balance is spendable again.

### Suggested fixes

- Consume-time check, not just init-time: before serving, re-verify the hash
  against the registry (or persist `noCredit` to disk and treat every
  historical stake hash as permanently excluded — exclusion sets should only
  grow).
- Zero `credits[h]` when a hash-level exclusion lands, symmetric with the
  account-level path.
- The ladder should refuse a `stake_hash` the API has already credited (shared
  hot wallet means the two services must share a used-hash view), or mark
  stake sends in a write-through manner the API sees immediately rather than
  at the next 10-minute round.

### Honest bounds

- Per-hash extraction is capped by `MAX_CREDIT_RAW` = 1 NANO.
- In-window consumption is bounded by the reload interval (≤600 s) and the
  caller's throughput; /v1/work is additionally rate-limited per IP.
- Edge 2 requires a process restart after the registry row disappears.
- I did not test against the live service beyond reading public endpoints;
  all claims above are from `api @ 2c88aea64b` source. No exploitation
  attempted; nothing observed on chain.