[karolko9]

Summary

Anyone who sees the payer's signed auth entry can submit it first in their own transaction. Then our
transaction fails with Error(Auth, ExistingValue), and /settle told the client "sign a new
payment", although the payment may have settled. This PR answers that case with its own code and no
such advice (task 0141, decisions 2–4).

 /verify, and /settle's re-check
   upstream answers simulation_failed
+    the payer's nonce entry exists on chain   -> invalid_exact_stellar_payload_nonce_consumed_elsewhere
     a trustline is missing                    -> …_trustline_missing
 /settle, after the claim
   the pool's simulation fails (SimulationError)
+    the payer's nonce entry exists on chain   -> settle_exact_stellar_nonce_consumed_elsewhere
-                                              -> settle_exact_stellar_simulation_failed + "sign a new payment"
   our transaction fails on chain (in /settle, the reconcile sweep, or the pool's resolved event)
+    Error(Auth, ExistingValue) in the token's frame -> settle_exact_stellar_nonce_consumed_elsewhere
+    no error event, and the payer's nonce entry exists -> settle_exact_stellar_nonce_consumed_elsewhere
-                                              -> settle_exact_stellar_transaction_failed + "sign a new payment"
 every final record with the new code
+  log settlement_nonce_consumed_elsewhere (with feeCharged), count settlement_nonce_consumed_elsewhere_total{window=settle}
 every /verify or re-check refusal with the new code
+  count settlement_nonce_consumed_elsewhere_total{window=verify}

A used nonce does not prove the payment: the payer can spend it on a second entry. So /settle never
answers success for a transaction it did not submit.

New unit: apps/facilitator/src/settlement/nonce-used.ts (both codes, the failure test, the nonce
read). The final reason for our failed transaction comes from one function, resultReason, in every
writer that ends a record (settle.ts and its answer after a failed record write, the reconcile
sweep, the pool's resolved event); it reads the nonce entry when the error doesn't tell, as an
RPC without diagnostic events gives none. The read has no timeout of its own: FallbackRpc's
per-URL timeout and failover apply.

Evidence

Both testnet cases from 2026-11-12, as getTransaction answered them, are a fixture
(test/fixtures/nonce-consumed-elsewhere.json):

Case	Our transaction	Before	After
the same entry landed one ledger earlier (bf6c8d21…)	233ea749… failed, 8,800 stroops	settle_exact_stellar_transaction_failed, "the auth entry may still land … sign a new payment"	settle_exact_stellar_nonce_consumed_elsewhere, no advice, logged with feeCharged
the payer signed a second entry under the same nonce (cc5538bd…)	09bc7098… failed, 8,800 stroops	same as above	same as above

Unchanged: the same error in a C-account payer's own frame stays …_transaction_failed (the
wallet's own nested auth); breaker attribution is unchanged. With an error event a used nonce feeds
no breaker; without one it still does, fixed in its own PR after this one (task 0141 decision 9).

• Before: test(lore-0141) commit e53b511d: the new tests fail (no nonce-used.ts).
• After: facilitator 1044 passed | 3 skipped, metrics-catalog 31 passed, infra 355 passed;
  format, lint, typecheck, build clean (see below).

Considered and rejected

• Answer success with the other transaction's hash — a buyer can race one entry through two
  facilitators to the same seller and be served twice; 0 front-runs in ~4,500 pubnet settlements.
• Reuse settle_exact_stellar_nonce_already_used — it means "another payload"; here the client may
  have paid, and clients act on the code, not the message.
• Cover only our failure on chain — the other transaction can also land before ours is sent; 3 of 7
  testnet cases failed in the simulation.
• Parse "Error(Auth, ExistingValue)" from the simulation's error text — the nonce entry on chain is
  the proof, and it also works after upstream, which drops the RPC's error.

Merge Danger

Door: two-way

Two new errorReason codes reach sellers. A seller that only checks success behaves as before.

Blast Radius: settlement

One more RPC read (getLedgerEntries) only after a failed simulation, or after our transaction
failed on chain without an error event that names a used nonce.

🤖 Generated with Claude Code