Transactions are commands that modify the ledger state. Among other things, Transactions are used to send payments, enter orders into the decentralized exchange , change settings on accounts, and authorize another account to hold your currency. If you think of the ledger as a database, then transactions are SQL commands.
Each transaction has the following attributes:
This is the account that originates the transaction. The transaction must be signed by this account, and the transaction fee must be paid by this account. The sequence number of this transaction is based off this account.
Each transaction sets a fee that is paid by the source account. If this fee is below the network minimum the transaction will fail. The more operations in the transaction, the greater the required fee.
Each transaction has a sequence number. Transactions follow a strict ordering rule when it comes to processing of transactions per account. For the transaction to be valid, the sequence number must be 1 greater than the sequence number stored in the source account entry when the transaction is applied. As the transaction is applied, the source account’s stored sequence number is incremented by 1 before applying operations. If the sequence number on the account is 4, then the incoming transaction should have a sequence number of 5. After the transaction is applied, the sequence number on the account is bumped to 5.
Note that if several transactions with the same source account make it into the same transaction set, they are ordered and applied according to sequence number. For example, if 3 transactions are submitted and the account is at sequence number 5, the transactions must have sequence numbers 6, 7, and 8.
Transactions contain an arbitrary list of operations inside them. Typically there is just one operation, but it’s possible to have multiple (up to 100). Operations are executed in order as one ACID transaction, meaning that either all operations are applied or none are. If any operation fails, the whole transaction fails. If operations are on accounts other than the source account, then they require signatures of the accounts in question.
Up to 20 signatures can be attached to a transaction. See Multi-sig for more information. A transaction is considered invalid if it includes signatures that aren’t needed to authorize the transaction—superfluous signatures aren’t allowed. Signatures are required to authorize operations and to authorize changes to the source account (fee and sequence number).
optional The memo contains optional extra information. It is the responsibility of the client to interpret this value. Memos can be one of the following types:
optional The UNIX timestamp (in seconds), determined by ledger time, of a lower and upper bound of when this transaction will be valid. If a transaction is submitted too early or too late, it will fail to make it into the transaction set. maxTime equal 0 means that it’s not set.
Between ledger closings, all the nodes in the network are collecting transactions. When it is time to close the next ledger, the nodes collect these transactions into a transaction set. FBA is run by the network to reach agreement on which transaction set to apply to the last ledger.
Transaction can fail with one of the errors in a table below. Error reference for operations can be found in List of operations doc.
|FAILED||-1||One of the operations failed (check List of operations for errors).|
|TOO_EARLY||-2||Ledger closeTime before minTime value in the transaction.|
|TOO_LATE||-3||Ledger closeTime after maxTime value in the transaction.|
|MISSING_OPERATION||-4||No operation was specified.|
|BAD_SEQ||-5||Sequence number does not match source account.|
|BAD_AUTH||-6||Too few valid signatures / wrong network.|
|INSUFFICIENT_BALANCE||-7||Fee would bring account below minimum reserve.|
|NO_ACCOUNT||-8||Source account not found.|
|INSUFFICIENT_FEE||-9||fee is too small.|
|BAD_AUTH_EXTRA||-10||Unused signatures attached to transaction.|
|INTERNAL_ERROR||-11||An unknown error occurred.|
*Powered by HashCash