When is account sequence number incremented?

Question

From Slack:

Is account sequence number incremented only by valid transactions? In my case, I am trying to create an account with a large starting balance and consequently get an underfunded error, which is fine. However, when I check the sequence number, it is still incremented. Am I missing something? Thanks!

Answer 1

At the lowest level of the protocol transactions are always processed, meaning they collect the fee and update the sequence number.

The layer above that, still done by validators, does the same checks done during consensus but actually removes the bad transactions that it will send out to consensus to reduce the chance of collecting fees for failed transactions.

The checks done by a validator are sanity checks and very simple:

• it checks if the parameters provided in the operations are valid (like no negative amounts, assets referenced are not garbage). Those checks are independent of the ledger state (so it doesn't need to walk the order book, etc).
• it also checks signatures and that the transaction source account can process the fee and has the proper sequence number.

The next layer above that (Horizon, Wallets, etc) can perform additional checks before signing transactions, for example, enforce some limits on payments (amount, rate per day, etc).

Reason for only doing those simple checks is two fold:

• it's very cheap (so very fast)
• it keeps the concern of tracking dependencies between transactions outside of the protocol layer (other than sequence number tracking). If more validations were done at that layer, it would require complex reordering of transactions when merging transaction sets, and that complexity increases the attack surface of the protocol.

With this explained - a payment can fail with an "underfunded" error because the payment amount is not part of sanity checks that validators perform. This responsibility falls onto the upper layers of the stack.

Answer 2

Accepted answer has great explanation how the process work, so let me add some practical examples to make it more concrete.

Doesn't bump sequence

• operations have obviously invalid parameters (negative amounts, invalid accountId, etc.)
• insufficient transaction fee
• source account has insufficient balance to cover transaction fee
• sequence number of source account is invalid
• missing, redundant or invalid signature(s)

Does bump sequence

It isn't any of above, then fee is deducted and the transaction proceeds to be validated against the state of ledger. But...

Beware of corner cases!

I personally have found few practically unreliable cases while creating complex smart contracts. The trick is, sometimes you just can't know whenever it will fall in the list above due uncontrollable external factors. Here are known cases for me:

• There are various scenarios that are based around the notion of "submitting several transactions during the same ledger". In a simplest example, lets say you submit two transactions, one after other, that depletes all extra lumens of account. Depending on your internet connection (which you don't have control over), or simply by trying it with lots of accounts in parallel, those transactions may or may not get into the same ledger.
  • If transactions get into different ledgers then sequence will be bumped only once, because first would execute but second would fail due fees.
  • If transactions get into the same ledger then sequence will be bumped twice, because both fees are taken first and none would execute due being underfunded.
• Theoretically anyone can send a lumen to a account just before you submit the transaction that should fail due insufficient balance to cover the fee. Given that it may even be during the same ledger I don't know how to safeguard against this, thus it denies to use publicly available pre-auth transactions based on transaction fee lock in smart contracts.
• Multi-party pre-signed transaction envelopes may become invalid if one party changes his signers afterwards. In example, if transaction of smart contract should legitimately fail due "underfunded" and bump, in such case it may fail due invalid signature and not bump.