- Get Started
- Become an Anchor
- Stellar Attachment Convention
- Compliance Protocol
- Issuing Assets
- Build Stellar Apps
- Contribution Guide
Here are the possible operation types:
Operations are executed on behalf of the source account specified in the transaction, unless there is an override defined for the operation.
Each operation falls under a specific threshold category: low, medium, or high. Thresholds define the level of privilege an operation needs in order to succeed.
There are two places in a transaction life cycle when operations can fail. The first time is when a transaction is submitted to the network. The node to which the transaction is submitted checks the validity of the operation: in the validity check, the node performs some cursory checks to make sure the transaction is properly formed before including it in its transaction set and forwarding the transaction to the rest of the network.
The validity check only looks at the state of the source account. It ensures that:
Once a transaction passes this first validity check, it is propagated to the network and eventually included in a transaction set. As part of a transaction set, the transaction is applied to the ledger. At that point a fee is taken from the source account. Operations are attempted in the order they occur in the transaction. If any operation fails, the whole transaction fails and the effects of previous operations are rolled back.
For each operation, there is a matching result type. In the case of success, this result allows users to gather information about the effects of the operation. In the case of failure, it allows users to learn more about the error.
Stellar Core queues results in the txhistory table for other components to derive data from. This txhistory table is used by the history module in Stellar Core for uploading the history into long-term storage. It can also be used by external processes such as Horizon to gather the network history they need.
Typically transactions only involve operations on a single account. For example, if account A wanted to send lumens to account B, only account A needs to authorize the transaction.
It’s possible, however, to compose a transaction that includes operations on multiple accounts. In this case, to authorize the operations, the transaction envelope must include signatures of every account in question. For example, you can make a transaction where accounts A and B both send to account C. This transaction would need authorization from both account A and B before it’s submitted to the network.
Anush wants to send Bridget some XLM (Operation 1) in exchange for BTC (Operation 2).
A transaction is constructed:
Anush_account(the operation inherits the source account from the transaction) to meet medium threshold
Bridget_accountto meet medium threshold
Anush_accountto meet low threshold since
Anush_accountis the source for the entire transaction.
Therefore, if both
Bridget_account sign the transaction, it will be validated.
Other, more complex ways of submitting this transaction are possible, but signing with those two accounts is sufficient.
An anchor wants to divide the processing of their online (“base”) account between machines. That way, each machine will submit transactions from its local account and keep track of its own sequence number. For more on transaction sequence numbers, please refer to the transactions doc.
The benefit of this scheme is that each machine can increment its sequence number and submit a transaction without invalidating any transactions submitted by the other machines. Recall from the transactions doc that all transactions from a source account have their own specific sequence number. Using worker machines, each with an account, allows this anchor to submit as many transactions as possible without sequence number collisions.
Transactions that require multiple parties to sign, such as the exchange transaction between Anush and Bridget from example #1, can take an arbitrarily long time. Because all transactions are constructed with specific sequence numbers, waiting on the signatures can block Anush’s account. To avoid this situation, a scheme similar to Example #2 can be used.
Anush would create a temporary account
Anush_temp with XLM, and add the
Anush_account public key as signer to
Anush_temp with a weight crossing at least the low threshold.
A transaction is then constructed:
The transaction would have to be signed by both Anush_account and Bridget_account, but the sequence number consumed will be from account Anush_temp.
Anush_account wants to recover the XLM balance from
Anush_temp, an additional operation “Operation 3” can be included in the transaction. If you want to do this,
Anush_temp must add
Anush_account as a signer with a weight that crosses the high threshold: