List of Operations

This is the canonical list of Lantah operations, which lists every Lantah operation along with parameters, error codes, and links to relevant documentation for key SDKs.

For a description of how operations work in Lantah, see Operations.

For the protocol specification, see Lantah-transaction.x.

​​​

Create Account

JavaScript | Java | Go

Creates and funds a new account with the specified starting balance.

Threshold: Medium

Result: CreateAccountResult

Parameters:

Possible Errors:

Payment

JavaScript | Java | Go

Sends an amount in a specific asset to a destination account.

Threshold: Medium

Result: PaymentResult

Parameters:

Possible errors:

Path Payment Strict Send

JavaScript | Java | Go

A path payment sends an amount of a specific asset to a destination account through a path of offers. Since the asset sent (e.g., 500 Grams) can be different from the asset received (e.g, 1 BTC), path payments allow for the simultaneous transfer and conversion of currencies.

A Path Payment Strict Send allows a user to specify the amount of the asset to send. The amount received will vary based on offers in the order books. If you would like to instead specify the amount received, use the Path Payment Strict Receive operation.

A few things to note:

  • path payments don’t allow intermediate offers to be from the source account as this would yield a worse exchange rate. You’ll need to either split the path payment into two smaller path payments, or ensure that the source account’s offers are not at the top of the order book.

  • balances are settled at the very end of the operation

    • this is especially important when (Destination, Destination Asset) == (Source, Send Asset) as this provides a functionality equivalent to getting a no interest loan for the duration of the operation.

  • Destination min is a protective measure: it allows you to specify a lower bound for an acceptable conversion. If offers in the order books are not favorable enough for the operation to deliver that amount, the operation will fail.

The network automatically considers both the orderbook and any liquidity pools when trying to find paths to exchange one asset for another. For example, if a user wants their recipient to get 1000 Zs from your As, they may consume an order to get Ws for their As, then exchange against the W-Z liquidity pool for the second hop of the payment.

Threshold: Medium

Result: PathPaymentStrictSendResult

Parameters:

Possible errors:

Path Payment Strict Receive

JavaScript | Java | Go

A path payment sends an amount of a specific asset to a destination account through a path of offers. Since the asset sent (e.g., 500 Grams) can be different from the asset received (e.g, 1 BTC), path payments allow for the simultaneous transfer and conversion of currencies.

A Path Payment Strict Receive allows a user to specify the amount of the asset received. The amount sent varies based on offers in the order books. If you would like to instead specify the amount sent, use the Path Payment Strict Send operation.

A few things to note:

  • path payment doesn’t allow intermediate offers to be from the source account as this would yield a worse exchange rate. You’ll need to either split the path payment into two smaller path payments, or ensure that the source account’s offers are not at the top of the order book.

  • balances are settled at the very end of the operation

    • this is especially important when (Destination, Destination Asset) == (Source, Send Asset) as this provides a functionality equivalent to getting a no interest loan for the duration of the operation.
  • Send max is a protective measure: it allows you to specify an upper bound for an acceptable conversion. If offers in the order books are not favorable enough for the operation to succeed for less than Send max, the operation will fail.

 

As of protocol 18, the network automatically considers both the orderbook and any liquidity pools when trying to find paths to exchange one asset for another. For example, if a user wants their recipient to get 1000 Zs from your As, they may consume an order to get Ws for their As, then exchange against the W-Z liquidity pool for the second hop of the payment.

Threshold: Medium

Result: PathPaymentStrictReceiveResult

Parameters:

Possible errors:

Manage Buy Offer

JavaScript | Java | Go

Creates, updates, or deletes an offer to buy one asset for another, otherwise known as a “bid” order on a traditional orderbook.

If you want to create a new offer, set Offer ID to 0.

If you want to update an existing offer, set Offer ID to existing offer ID.

If you want to delete an existing offer, set Offer ID to existing offer ID and set Amount to 0.

Threshold: Medium

Result: ManageBuyOfferResult

Parameters:

Possible errors:

Manage Sell Offer

JavaScript | Java | Go

Creates, updates, or deletes an offer to sell one asset for another, otherwise known as an “ask” order or “offer” on a traditional orderbook.

If you want to create a new offer, set Offer ID to 0.

If you want to update an existing offer, set Offer ID to existing offer ID.

If you want to delete an existing offer, set Offer ID to existing offer ID and set Amount to 0.

 

Threshold: Medium

Result: ManageSellOfferResult

Parameters:

Possible errors:

Create Passive Sell Offer

JavaScript | Java | Go

Creates an offer to sell one asset for another, otherwise known as a “ask” order or “offer” on a traditional orderbook, without taking a reverse offer of equal price.

A passive sell offer is an offer that does not act on and take a reverse offer of equal price. Instead, they only take offers of lesser price. For example, if an offer exists to buy 5 BTC for 30 XLM, and you make a passive offer to buy 30 XLM for 5 BTC, your passive offer does not take the first offer. Passive offers in Lantah are always expressed as “ask” or “offer” orders in a traditional orderbook.

Note that regular offers made later than your passive offer can act on and take your passive offer, even if the regular offer is of the same price as your passive offer.

Passive offers allow market makers to have zero spread. If you want to trade EUR for USD at 1:1 price and USD for EUR also at 1:1, you can create two passive offers so the two offers don’t immediately act on each other.

Once the passive offer is created, you can manage it like any other offer using the manage sell offer operation.

Threshold: Medium

Result: ManageSellOfferResult

Possible errors:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Set Options

JavaScript | Java | Go

Sets options for an account, such as setting the inflation destination or adding an additional signer on an account.

Allows you to set multiple options on an account in a single operation, such as changing an operation threshold and setting the flags on an account at the same time.

For more information on the options related to signing, see our docs on multi-sig.

When updating signers or other thresholds, the threshold of this operation is High.

Threshold: Medium or High

Result: SetOptionsResult

Parameters:

Possible errors:

Change Trust

JavaScript | Java | Go

Creates, updates, or deletes a trustline. For more on trustlines, please refer to the assets documentation.

To delete an existing trustline, set Line to the asset of the trustline, and Limit to 0.

The Line parameter is an instance of a ChangeTrustAsset. If you are modifying a trustline to a regular asset (i.e. one in a Code:Issuer format), this is equivalent to the Asset type. If you are modifying a trustline to a pool share, however, this is composed of the liquidity pool reserve assets and the pool fee. You can refer to the liquidity pool glossary entry and the examples therein for details.

Threshold: Medium

Result: ChangeTrustResult

Parameters:

Possible errors:

Allow Trust

JavaScript | Java | Go

This operation is deprecated as of Stellar's Protocol 17. Prefer SetTrustLineFlags instead.

Updates the authorized flag of an existing trustline.

This can only be called by the issuer of a trustline’s asset, and only when AUTHORIZATION REQUIRED has been set on the issuer’s account.

There are two different kinds of asset authorization: complete authorization, which allows an account to transact with an asset (by making payments, creating offers, etc.) and limited authorization, which allows an account to maintain and reduce current offers, but not to perform other operations with the asset.

The issuer can only change a flag from complete to limited authorization or clear the authorized flag if the issuer has the AUTH_REVOCABLE_FLAG set. Otherwise, the issuer can only set the authorized flag. For more on what toggling between authorization states allows an issuer to do, see the Control Access to an Asset doc.

If the issuer clears the authorized flag, all offers owned by the trustor that are either selling type or buying type will be deleted.

Threshold: Low

Result: AllowTrustResult

Parameters:

Possible errors:

Account Merge

JavaScript | Java | Go

Transfers the native balance (the amount of XLM an account holds) to another account and removes the source account from the ledger.

Threshold: High

Result: AccountMergeResult

Parameters:






Possible errors:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Manage Data

JavaScript | Java | Go

Sets, modifies, or deletes a data entry (name/value pair) that is attached to a particular account.

An account can have a large amount of data entries attached to it (subject to sub-entry limits for an account). Each data entry increases the minimum balance (via the base reserve) needed to be held by the account.

Data entries can be used for storing application-specific data on the Lantah Network. They are not used by the core Lantah Protocol.

Threshold: Medium

Result: ManageDataResult

Parameters:

 

 




Possible errors:
 

Bump Sequence

JavaScript | Java | Go

Bumps forward the sequence number of the source account to the given sequence number.

This operation invalidates any transactions with a smaller sequence number, and is often utilized in complex contracting scenarios.

If the specified bumpTo sequence number is greater than the source account’s sequence number, the account’s sequence number is updated with that value, otherwise it’s not modified.

Threshold: Low

Result: BumpSequenceResult

Parameters:

Possible Errors:

Create Claimable Balance

Creates a ClaimableBalanceEntry. See Claimable Balance for more information on parameters and usage.

 

Threshold: Medium

Result: CreateClaimableBalanceResult

Parameters:

Possible errors:

Claim Claimable Balance

Claims a ClaimableBalanceEntry and adds the amount of asset on the entry to the source account.

Threshold: Low

Result: ClaimClaimableBalanceResult
 

Parameters:







Possible errors:

Begin Sponsoring Future Reserves

Establishes the is-sponsoring-future-reserves-for relationship between the source account and sponsoredID. See Sponsored Reserves for more information.

There must be a corresponding end sponsoring future reserves operation in the same transaction to end the is-sponsoring-future-reserves-for relationship. The transaction will fail with txBAD_SPONSORSHIP otherwise.

 

Threshold: Medium

Result: BeginSponsoringFutureReservesResult

Parameters:





Possible errors:



 

End Sponsoring Future Reserves

Terminates the current is-sponsoring-future-reserves-for relationship in which the source account is sponsored.

Threshold: Medium

Result: EndSponsoringFutureReservesResult

Possible errors:



 

Revoke Sponsorship

The logic of this operation depends on the state of the source account.

If the source account is not sponsored or is sponsored by the owner of the specified entry or sub-entry, then attempt to revoke the sponsorship. If the source account is sponsored, the next step depends on whether the entry is sponsored or not. If it is sponsored, attempt to transfer the sponsorship to the sponsor of the source account. If the entry is not sponsored, then establish the sponsorship.

 

Threshold: Medium

Result: RevokeSponsorshipResult

This operation is a union with two possible types -

Or

Possible errors:

Set Trustline Flags

JavaScript | Java | Go

Allows an issuing account to configure various authorization and trustline flags for all trustlines to an asset. This supersedes the deprecated AllowTrust, but the documentation there still applies.

The Asset parameter is of the TrustLineAsset type. If you are modifying a trustline to a regular asset (i.e. one in a Code:Issuer format), this is equivalent to the Asset type. If you are modifying a trustline to a pool share, however, this is composed of the liquidity pool’s unique ID. You can refer to the liquidity pool glossary entry and the examples therein for details.

Threshold: Low

Result: SetTrustLineFlagsResult

Parameters:
 

 

 

 

 

 

 

 

 

 

 

 

 

Note that passing 0 to either SetFlags or ClearFlags will be a no-op (nothing will be set or cleared).

Possible errors:
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

Clawback

JavaScript | Java | Go

Reduces (burns) an amount in a specific asset from an account.

Threshold: Medium

Result: ClawbackResult

Parameters:

Possible errors:

Clawback Claimable Balance

Claws back an unclaimed ClaimableBalanceEntry, burning the pending amount of the asset.

 

Threshold: Medium

Result: ClaimClaimableBalanceResult

Parameters:

Refer to the ClaimableBalanceID or the Claimable Balance glossary entries for more information on acquiring a claimable balance ID.

Possible errors:

Liquidity Pool Deposit

Deposits assets into a liquidity pool.

Depositing increases the reserves of a liquidity pool in exchange for pool shares.

Parameters to this operation depend on the ordering of assets in the liquidity pool: “A” refers to the first asset in the liquidity pool, and “B” refers to the second asset in the liquidity pool. Refer to the liquidity pool glossary entry for information about how to determine the fixed ordering of assets. SDKs often have helpers (like Asset.compare) to determine the right order.

If the pool is empty, then this operation deposits maxAmountA of A and maxAmountB of B into the pool. If the pool is not empty, then this operation deposits at most maxAmountA of A and maxAmountB of B into the pool. The actual amounts deposited are determined using the current reserves of the pool. You can use these parameters to control a percentage of slippage; refer to the example for details.

 

Threshold: Medium

Result: LiquidityPoolDepositResult

Parameters:

Possible errors:

Liquidity Pool Withdraw

Withdraw assets from a liquidity pool.

Withdrawing reduces the number of pool shares in exchange for reserves from a liquidity pool.

Refer to the discussion on asset ordering in Liquidity Pool Deposit, above, for details on the “A” and “B” parameters.

The minAmountA and minAmountB parameters can be used to control a percentage of slippage from the “spot price” on the pool; refer to the example for details.

Threshold: Medium

Result: LiquidityPoolWithdrawResult

Parameters:

Possible errors:

Welcome

   Introduction

   Lantah Software Stack

   Operations List

Tutorials

   Create an Account

   Send/Receive

   Follow Received Payments

   Handling Errors

   Securing Web Projects

Run a Node
   Overview

   Prerequisites

   Installing

   Configuring

   Publishing Archives

   Running

   Monitoring

   Commands

   Upgrading

   Tier 1 Organizations

Run an API Server

   Overview

   Prerequisites

   Installing

   Configuring

   Remote Captive Core

   Running

   Ingestion

   Monitoring

   Scaling

Software/SDKs

   Software and SDKs

Glossary

   Glossary