Retry policy for state-changing RPC calls (sendTransaction).
State-changing calls carry a double-submission risk: a request may time out
on the client after the network already accepted the transaction. We
therefore retry only once and rely on Soroban's hash-based deduplication —
resubmitting the same signed transaction is safe, but a retry must NEVER
rebuild the transaction with a fresh sequence number (that would double-spend).
Retry policy for state-changing RPC calls (
sendTransaction).State-changing calls carry a double-submission risk: a request may time out on the client after the network already accepted the transaction. We therefore retry only once and rely on Soroban's hash-based deduplication — resubmitting the same signed transaction is safe, but a retry must NEVER rebuild the transaction with a fresh sequence number (that would double-spend).