How Stellar sequence numbers work

Last updated: September 22, 2026

At a glance

What you see

Transactions from one account are rejected when two processes send at the same time, or after a transaction you thought failed actually went through. Building a new transaction with a sequence number you cached earlier stops working.

Why this happens

Stellar's documentation says "the sequence number must be one greater than the sequence number stored in the source account entry when the transaction is applied unless sequence number preconditions are set", and "after a transaction is executed, the account will always set its sequence number to the transaction's sequence number". The glossary defines it as "used to identify and verify the order of transactions with the source account". Two transactions built from the same stored value compete for the same next number, and a cached value is stale as soon as any transaction from the account executes.

What to do

1. Read the source account's current sequence number (the account's sequence field) right before building, and use sequence + 1.
2. Build and submit transactions for one source account from a single place, one at a time.
3. After a timeout, check whether the previous transaction executed before reusing its sequence number.
4. For parallel sending, use several source accounts rather than sharing one.

When this is not our problem

Sequence numbers are enforced by the Stellar network when a transaction is applied, whoever operates the Horizon server that relays it, Triport included.