Skip to main content

​
1. Creation (Transaction Creator)

A user creates a transaction by setting the source account, sequence number, list of operations and their respective parameters, fee or fee-bump, and optionally a memo and/or preconditions.

​
1b. Transaction Simulation

Smart contract transactions undergo transaction simulation, where the transaction is run in a simulated environment to check for errors and ensure it can be executed successfully. Read more in the Transaction Simulation section.

​
2. Signing (Transaction Signers)

Once the transaction is complete, it becomes a transaction envelope containing the transaction itself and a list of signers. All the required signatures must be collected and added to the transaction envelope’s list of signers. Commonly, it’s just the signature of the account doing the transaction, but more complicated setups can require collecting signatures from multiple parties. Read more about signatures in the Signatures and Multisig section.

​
3. Submitting (Transaction Submitter)

After signing, the transaction can now be submitted to the Stellar network. If the transaction is invalid, it will be rejected immediately by Stellar Core, the account’s sequence number will not be incremented, and no fee will be consumed from the source account. Only one transaction (and one sequence number) for the same account can be consumed per ledger. Transactions are typically submitted using Stellar RPC, but you can also submit the transaction directly to an instance of Stellar Core.

​
4. Propagating (Validator)

Once Stellar Core has determined that a transaction is valid, it will propagate the transaction to all other servers to which it’s connected. This way, a valid transaction is flooded to the entire Stellar network.

​
5. Crafting a candidate transaction set (Validator)

When it’s time to close the ledger, each Stellar Core validator takes all valid transactions it is aware of since the last ledger close and collects them into a candidate transaction set. If it hears about any incoming transactions now, it puts them aside for the next ledger close. If the number of operations in the candidate transaction set is greater than the maximum number of operations per ledger, transactions will be prioritized by their fee for inclusion in the set.

​
6. Nominating a transaction set (Validator)

Once each validator has crafted a candidate transaction set, the set is nominated to the network.

​
7. Stellar Consensus Protocol (SCP) determines the final transaction set (Validator Network)

SCP resolves any differences between candidate transaction sets and ultimately determines a single transaction set to apply, the close time of the ledger, and any upgrades to the protocol that need to be applied network-wide at the apply time. If a transaction doesn’t make it into the transaction set, it is kept around in memory to be added to the next transaction set on a best-effort basis. If a transaction is kept in memory after a certain number of ledger closes, it will be banned for several additional ledgers. This means no attempt will be made to include it in a candidate transaction set additional ledgers during this time.

​
8. Transaction apply order is determined (Validator Network)

Once SCP agrees on a particular transaction set, the apply order is computed for the transaction set. This shuffles the set’s order to create uncertainty for competing transactions.

​
9. Fees are collected (Validator)

Fees are collected for all transactions simultaneously.

​
10. Application (Validator)

Each transaction is applied in the previously-determined order. For each transaction, the account’s sequence number is consumed (increased by 1), the transaction’s validity is rechecked, and each operation is applied in the order they occur in the transaction. Operations may fail at this stage due to errors that can occur outside of the transaction and operation validity checks. For example, an insufficient balance for a payment is not checked at submission and would fail at this time. The entire transaction will fail if any operation fails, and all previous operations will be rolled back.

​
11. Protocol Upgrades (Validator)

Finally, upgrades are run if an upgrade took place. This can include arbitrary logic to upgrade the ledger state for protocol upgrades, along with ledger header modifications, including the protocol version, base fee, maximum number of operations per ledger, etc. Once this has been completed, the life cycle begins anew.