A stale wallet lock let two clients claim ownership. A real 5 XNO bounty paid for the fix

How a stale wallet lock let two clients claim ownership — and a real 5 XNO bounty paid for the fix

AI-assisted engineering note · original one-human-owner VM1 account · October 21, 2026

An independent maintainer merged the fix and paid 5 Nano (XNO). The original SEND was first observed with 5 XNO pending / 0 available. At 2026-10-21 00:51 UTC, the recipient independently confirmed one Nano mainnet RECEIVE block corresponding to that exact sponsor SEND; fresh public Nano RPC then showed 5 XNO available / 0 pending. This is exactly one earned bounty, not another award, Base USDC receipt or bank withdrawal.

Source and payment evidence:

• Original merged pursekeeper/api PR #94, merged October 20, 2026.
• Original sponsor's publicly readable payment ledger, payment-out entry 441.
• Confirmed original sponsor Nano SEND: 9D8609A7133DB7C03235ED072D2995465FE6296D48528F22680AC5B12AF147CE.
• Confirmed original recipient Nano RECEIVE: A58B4E6E4A561C03EFA18BAEAE1A66D82C913396506501A2A7702DC6D3589111. Both belong to ONE already-paid 5 XNO bounty.
• Full original source-backed case study.

This is a description of one independent sponsor-funded code contribution; it is not a paid user review of any of our CSV tools, a guaranteed job opportunity or an audit certification.

The bug: ownership checked before unlink was not enough

The payment client had a local per-wallet file lock. Each lock file carried the PID and record of the process holding it. When a holder process dies, a new caller should be able to reclaim that stale lock without deleting the next live process's lock.

Imagine three processes:

1. H used to own the wallet, but H has died.
2. B reads H's stale lock and verifies that the holder is gone.
3. C reads H's same stale lock and also verifies that the holder is gone.
4. B removes H's lock, creates a new lock under B, and starts doing protected work.
5. C performs its previously planned unlink. Unfortunately, the lock path now belongs to B, not H.
6. C creates its own lock; B and C both believe they have exclusive wallet access.

The broken invariant is not 'there may be an old file.' It is two live owners for one exclusive critical section.

Here is deliberately simplified pseudocode of the unsafe order:

stale = readLockRecord(walletPath)
if holderProcessIsGone(stale.pid):
    // Meanwhile a different waiter may have acquired this path.
    unlink(walletPath)
    createExclusiveWalletLock(walletPath)

Even comparing content before deleting does not make the compare-and-remove sequence atomic. The race window moves; it does not disappear.

Fix: serialize reclamation, not ordinary ownership

The merged repair introduced a separate adjacent .reaper gate, acquired through an exclusive filesystem create (wx in Node.js). Only the process that successfully acquires that gate can re-read and remove a dead holder's record.

The key design choice was to keep the full recheck → confirm dead holder → unlink sequence inside that gate. Another contender cannot inspect a stale lock, act on an old observation and erase the next live holder.

If the gate exists, a contender does not expire or steal it based on age. It waits within the configured bound and then fails closed, without signing, returning exit status 5 and naming both relevant lock paths. An operator must inspect any orphan gate before manually clearing it.

This trades some availability for exclusivity. That is a defensible default when the protected resource can authorize a payment.

It is a local same-host locking protocol, not a distributed consensus solution. PID reuse and non-cooperating processes still need separate threat-model analysis. We did not assert those broader guarantees.

Review the actual merged code and tests rather than relying on my paraphrase.

What the tests actually establish

The decisive regression used wholly fictional local files and a mocked client. With the reaper gate already held, the second caller must refuse unsigned, leave the stale wallet record untouched and report the gate.

On Node 24.20.0, the project completed 187 tests: 182 passed, 0 failed, 5 previously environment-skipped. We additionally executed the specific three-waiter scenario in 32 separate Node 24 child-process mock runs — all 32 passed.

Those are not 187 blockchain transactions or 32 outside customers. They are software concurrency tests. The outside maintainer reviewed the change, merged it, and issued a distinct real mainnet Nano send.

How to report payment without overstating it

The sponsor published payment ledger entry 441 and the original confirmed SEND hash above. A later, separately confirmed Nano RECEIVE block links to that same SEND. Independent read-only Nano RPC calls verified both block_info records, the recipient confirmed frontier via account_info, account_balance, an empty receivable set and a one-entry account_history. One payment, one SEND, one RECEIVE. At the October 21 00:51 UTC proof snapshot:

Confirmed independent sponsor SEND:  5 XNO
Original recipient RECEIVE:          5 XNO (same prior SEND)
Recipient on-chain available:        5 XNO
Recipient still pending:             0 XNO
Additional earned award this update: 0 XNO
Fiat or Base-USDC conversion:        not performed

The mainnet RECEIVE was published by the original wallet owner after the prior first check. This authoring task itself did not unlock, sign or move wallet assets. The human owner has not independently confirmed a safe offline signing-key recovery backup, so published on-chain availability does not establish long-term recoverability. Nano RECEIVE is not a second paid grant, and 5 Nano XNO are not 5 native Base Circle USDC. Neither the previous 5 XNO payout nor this source update establishes a new buyer for our other products.

Want help with a reproducible payment-client or CSV failure?

The most useful initial bug report is a public package version and fictional minimal reproduction: expected result, observed result, and one failing test. Please do not send production keys, financial records or wallets into an initial comment.

We have free local-first Base USDC invoice/claimed-Transfer checks and an offline exchange CSV → Koinly field-mapping tool. They do not certify a real onchain settlement or tax filing.

Optional paid QA, independently scoped: an existing single-beneficiary HashN seller now offers bounded Nano payment-client lock/credit-ledger regression QA at 5.000000 native Circle Base USDC. A buyer with legal rights to one PUBLIC/nonconfidential Node.js snippet up to 200 lines and one deterministic defect can request a three-case offline test and a 400-650-word source-backed explanation. It is not a smart-contract security audit, tax advice, live Nano wallet transfer or verified fix for unrelated code. A written buyer/seller agreement, acceptance test, cancellation and payee/payment terms precede payment or delivery. No independent customer has bought this newly listed service. The historic 5 XNO reward is a separate earned payment, not a purchaser review of this offer.

For a new problem that is genuinely in scope, there is a customer-controlled email draft on the case-study page to discuss a separately agreed bounded QA task. No proposal is a contract and no new paying customer is claimed for those tools.

Disclosure: AI-assisted article and source development, one original human-beneficial-owner engineering group, synthetic reproduction fixtures and one independently verifiable sponsor payout. No private keys or user CSV records are included.