- Get Started
- Stellar Attachment Convention
- Compliance Protocol
- Add Stellar To Your Exchange
- Hardware Requirements
- Issuing Assets
- Lumen Supply Metrics
- 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.
SetOptions(only when changing signers and the thresholds for each category).
When an operation is submitted as a part of a transaction to the network, the node to which the transaction is initially submitted checks the validity of each operation before attempting to include the entire transaction in a candidate transaction set. For more details on this process, see the lifecycle of a transaction.
The operation validity checks at this level of the protocol are intended to be fast and simple, leaving more intensive checks to be applied after fees have been consumed. The following conditions determine whether an operation is valid or not:
ManageBuyOfferin Stellar Protocol 11.
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.
Anush wants to send Bridget some XLM (Operation 1) in exchange for BTC (Operation 2).
The following transaction is constructed:
null(Inferred to be
Anush_accountfrom the transaction source account)
Anush_account(the operation inherits the source account from the transaction) to meet medium threshold for a
Bridget_accountto meet medium threshold for a
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 (typically
involving multi-sig), 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.
BaseAccount, with a weight that gives each individual key the ability to perform medium security transactions. The worker machines can then sign on behalf of the base account. For more on signing, please refer to our multisig documentation.
Machine_2) wants to submit a transaction to the network, it constructs the following transaction:
BaseAccountto meet medium threshold for a
Machine_2is a signer on
BaseAccountwhich meets medium threshold, the signature is valid and sufficient.
Machine_2to meet low threshold since
Machine_2is the source for the entire transaction. Without changing the thresholds for
Machine_2's key will already be able to perform up to high security operations, and will be valid and sufficient.
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 our transactions documentation that all transactions from a source account have their own specific sequence number. Using worker machines, each with their own separate account, allows an 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
A transaction is then constructed:
Anush_accountto meet the medium threshold for a
Bridget_accountto meet the medium threshold for a
Anush_tempto meet low threshold since
Anush_tempis the source for the entire transaction.
All of these requirements would be met by having
Bridget_account with the
current setup, but with the additional benefit that the sequence number consumed will be from
Anush_temp. This allows
Anush_account to continue to perform other operations while
Anush_account wants to recover the XLM balance from
Anush_temp used to fund the account, 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:
null(Inferred to be
Anush_tempfrom the transaction source account)
This will ultimately merge
Anush_temp's balance into