How many of your next 1,000 agent payments will go out twice?

1. 1. One payment key, refused on repeat downstream

   missing

   Every retry of one payment carries the same key, and the facilitator or payment service refuses a key it has already settled. On-chain, the equivalent is re-broadcasting the same signed transaction (same nonce) instead of signing a new one.

2. 2. Tell "never submitted" apart from "submitted, response lost"

   missing

   Before any retry, look up whether the earlier attempt was submitted (transaction hash, mempool or facilitator status). If it was, wait for it instead of sending a new payment.

3. 3. Timeout longer than your slowest normal confirmation

   missing

   With your p50 and p95, a timeout of about 83 s lets 999 in 1,000 attempts confirm before the client gives up (yours is 30 s). This lowers duplicates but never removes them on its own.

• The symptom is "payments sometimes go out twice". The cause is a retry that cannot tell a slow payment from a failed one, with nothing downstream refusing the repeat.
• Without an idempotency key, a retry is not a repeat. It is a second, fully valid transfer of real value.
• The classic case: the retry fires before the first transaction confirms, and both land.
• A timeout after sending can't tell you whether the payment was never submitted or was submitted and the response was lost.
• An agent that sees an ambiguous failure keeps retrying, and every retry can pay again.

This is a forecast from your settings. To look for double pays that already went out, read your agent wallet's real payment history with the Agent Money Trace. It flags the same payee and amount paid twice within two minutes.