Skip to main content
This guide is available on four different programming languages: Typescript, Kotlin, Flutter (Dart) and Swift. You can change the shown version on each page via the buttons above.
In the previous section we learned how to create a wallet and a Stellar object that provides a connection to Horizon. In this section, we will look at the usages of this class.

Accounts

The most basic entity on the Stellar network is an account. Let’s look into AccountService that provides the capability to work with accounts:
Now we can create a keypair:
If using react-native, createKeypair won’t work. Instead use the helper method createKeypairFromRandom like this:

Build Transaction

The transaction builder allows you to create various transactions that can be signed and submitted to the Stellar network. Some transactions can be sponsored.

Building Basic Transactions

First, let’s look into building basic transactions.

Create Account

The create account transaction activates/creates an account with a starting balance of XLM (1 XLM by default).

Modify Account

You can lock the master key of the account by setting its weight to 0. Use caution when locking the account’s master key. Make sure you have set the correct signers and weights. Otherwise, you will lock the account irreversibly.
Add a new signer to the account. Use caution when adding new signers and make sure you set the correct signer weight. Otherwise, you will lock the account irreversibly.
Remove a signer from the account.
Modify account thresholds (useful when multiple signers are assigned to the account). This allows you to restrict access to certain operations when the limit is not reached.

Modify Assets (Trustlines)

Add an asset (trustline) to the account. This allows the account to receive transfers of the asset.
Remove an asset from the account (the asset’s balance must be 0).

Swap

Exchange an account’s asset for a different asset. The account must have a trustline for the destination asset. A swap is filled at whatever rate the network can find when the transaction is applied, which may differ from the rate you quoted to the user. The minimum destination amount (destMin) is the slippage limit that protects against that: it is the least amount of the destination asset the account is willing to receive for the amount it sends. If the swap cannot deliver at least that much, the transaction fails instead of executing at a worse rate. Derive it from a current quote minus the slippage tolerance you are willing to accept.

Path Pay

Send one asset from the source account and receive a different asset in the destination account. Like a swap, a path payment is filled at the rate available when the transaction is applied, so it takes a slippage limit. Which limit depends on which side of the payment is fixed:
  • When you fix the amount to send (sendAmount), pass destMin: the least amount of the destination asset the recipient must receive.
  • When you fix the amount to deliver (destAmount), pass sendMax: the maximum amount of the send asset the source account is willing to spend.
If the network cannot fill the payment within that limit, the transaction fails instead of executing at a worse rate. Derive the limit from a current quote plus or minus the slippage tolerance you are willing to accept.
To deliver an exact amount of the destination asset instead, pass destAmount together with sendMax:

Set Memo

Set a memo on the transaction. The memo object can be imported from “@stellar/stellar-sdk”.

Account Merge

Merges account into a destination account.

Fund Testnet Account

Fund an account on the Stellar test network

Building Advanced Transactions

In some cases a private key may not be known prior to forming a transaction. For example, a new account must be funded to exist and the wallet may not have the key for the account so may request the create account transaction to be sponsored by a third party.
First, the account must be created.
This transaction must be sent to external signer (holder of externalKeyPair) to be signed.
You can read more about passing XDR transaction to the server in the chapter below.
Signed transaction can be submitted by the wallet.
Now, after the account is created, it can perform operations. For example, we can disable the master keypair and replace it with a new one (let’s call it the device keypair) atomically in one transaction:

Adding an Operation

Add a custom Operation to a transaction. This can be any Operation supported by the Stellar network. The Operation object can be imported from “@stellar/stellar-sdk”.

Sponsoring Transactions

Some operations, that modify account reserves can be sponsored. For sponsored operations, the sponsoring account will be paying for the reserves instead of the account that being sponsored. This allows you to do some operations, even if account doesn’t have enough funds to perform such operations. To sponsor a transaction, simply start a sponsoring block (Kotlin), or simply create a building function (describing which operations are to be sponsored) and pass it to the sponsoring method (TypeScript):
Only some operations can be sponsored, and a sponsoring block (Kotlin) / builder (TypeScript) has a slightly different set of functions available compared to the regular TransactionBuilder. Note, that a transaction must be signed by both the sponsor account (sponsoringKeyPair) and the account being sponsored (sponsoredKeyPair).

Sponsoring Account Creation

One of the things that can be done via sponsoring is to create an account with a 0 starting balance. This account creation can be created by simply writing:
Note how in the first example the transaction source account is set to sponsoredKeyPair. Due to this, we did not need to pass a sponsored account value to the sponsoring block (Kotlin) / method (TypeScript). Since when ommitted, the sponsored account defaults to the transaction source account (sponsoredKeyPair). However, this time, the sponsored account (freshly created newKeyPair) is different from the transaction source account. Therefore, it’s necessary to specify it. Otherwise, the transaction will contain a malformed operation. As before, the transaction must be signed by both keys.

Sponsoring Account Creation and Modification

If you want to create an account and modify it in one transaction, it’s possible to do so with passing a sponsoredAccount optional argument to the sponsored block (Kotlin) / sponsoring method (TypeScript) (newKeyPair below). If this argument is present, all operations inside the sponsored block will be sourced by this sponsoredAccount. (Except account creation, which is always sourced by the sponsor).

Fee-Bump Transaction

If you wish to modify a newly created account with a 0 balance, it’s also possible to do so via FeeBump. It can be combined with a sponsoring block (Kotlin) / method (TypeScript) to achieve the same result as in the example above. However, with FeeBump it’s also possible to add more operations (that don’t require sponsoring), such as a transfer. First, let’s create a transaction that will replace the master key of an account with a new keypair.
Second, sign transaction with both keys.
Next, create a fee bump, targeting the transaction.
Finally, submit a fee-bump transaction. Executing this transaction will be fully covered by the sponsorKeyPair and sponsoredKeyPair and may not even have any XLM funds on its account.

Using XDR to Send Transaction Data

Note, that a wallet may not have a signing key for sponsorKeyPair. In that case, it’s necessary to convert the transaction to XDR, send it to the server, containing sponsorKey and return the signed transaction back to the wallet. Let’s use the previous example of sponsoring account creation, but this time with the sponsor key being unknown to the wallet. The first step is to define the public key of the sponsor keypair:
Next, create an account in the same manner as before and sign it with newKeyPair. This time, convert the transaction to XDR:
It can now be sent to the server. On the server, sign it with a private key for the sponsor address:
When the client receives the fully signed transaction, it can be decoded and sent to the Stellar network:

Submit Transaction

It’s strongly recommended to use the wallet SDK transaction submission functions instead of Horizon alternatives. The wallet SDK gracefully handles timeout and out-of-fee exceptions.
Finally, let’s submit a signed transaction to the Stellar network. Note that a sponsored transaction must be signed by both the account and the sponsor. The transaction is automatically re-submitted on the Horizon 504 error (timeout), which indicates a sudden network activity increase.
However, the method above doesn’t handle fee surge pricing in the network gracefully. If the required fee for a transaction to be included in the ledger becomes too high and transaction expires before making it into the ledger, this method will throw an exception. So, instead, the alternative approach is to:
This will create and sign the transaction that originated from the sourceAccountKeyPair. Every 30 seconds this function will re-construct this transaction with a new fee (increased by 100 stroops), repeating signing and submitting. Once the transaction is successful, the function will return the transaction body. Note, that any other error will terminate the retry cycle and an exception will be thrown.

Accessing Horizon SDK

It’s very simple to use the Horizon SDK connecting to the same Horizon instance as a Wallet class. To do so, simply call:
And you can work with Horizon Server instance: