For the complete documentation index, see llms.txt. This page is also available as Markdown.

Stellar Actions

Deposit into and redeem from Stellar (Soroban) vaults such as Gami earnUSDC / earnXLM. Write operations build an unsigned transaction that you sign with the user's wallet and submit back through the S

Overview

Stellar vault interactions live on the Stellar adapter (sdk.stellar), not on the higher-level vaults module (which is read-only for Stellar). Unlike EVM β€” where a deposit is signed and broadcast in one call β€” Stellar write methods follow a build β†’ sign β†’ submit flow:

  1. sdk.stellar.vaultDeposit() / sdk.stellar.vaultRedeem() build an unsigned transaction and return it as a base64-encoded XDR string.

  2. You sign that XDR with the user's Stellar wallet (e.g. Freighter).

  3. sdk.stellar.submitTransaction() broadcasts the signed XDR and resolves to the transaction hash once the network confirms it.

The SDK does not hardcode vault names like earnUSDC or earnXLM. You pass a vault's contract ID (the C… address); resolve it from the vault listing (see Get Vault Data).

sdk.stellar runs against Stellar mainnet. For testnet, see Networks at the bottom of this page.

Setup

sdk.stellar is always available β€” no extra provider configuration is required, since Stellar vault metadata is served from the August backend.

import AugustSDK from '@augustdigital/sdk';

const sdk = new AugustSDK({
  appName: 'your-app-name', // required: stable kebab-case slug identifying your app
});

// Access the Stellar adapter
const stellar = sdk.stellar;

AugustSDK is the package's default export β€” import it as import AugustSDK from '@augustdigital/sdk' (not a named import). appName is required. No providers entry is needed for Stellar, since its vault data is served from the August backend; add providers only if you also read EVM/Solana vaults.

Signing happens in your app via the user's wallet β€” there is no setWalletProvider step for Stellar. Whatever wallet you use must expose a "sign XDR" call (Freighter's signTransaction, for example).

Adapter API

Methods

Method
Returns
Description

vaultDeposit({ contractId, amount, senderAddress })

Promise<string> (XDR)

Build an unsigned deposit transaction.

vaultRedeem({ contractId, shares, receiverAddress })

Promise<string> (XDR)

Build an unsigned redeem transaction.

submitTransaction(signedXdr)

Promise<string> (tx hash)

Submit a signed XDR and poll until confirmed.

getUserPosition(vaultAddress, walletAddress)

Promise<IStellarUserPosition | null>

Read the user's on-chain share balance.

convertToShares(vaultAddress, rawAmount)

Promise<string | null>

Preview shares a deposit amount would yield.

isStellarAddress(address)

boolean

Validate a Stellar address (C… or G…).

getExplorerLink(id, type?)

string

Build a Stellar explorer URL.

Get Vault Data

Stellar vaults appear in the standard listing with chain_type === 'stellar'. Use a vault's address as the contractId for deposit/redeem.

Get User Positions

To include a user's Stellar balances in the unified positions call, pass stellarWallet (the user's G… address):

For a direct on-chain read of a single vault, use the adapter (this is also how you obtain the shares value needed to redeem):

Vault Deposit

Build an unsigned deposit transaction. This is a self-deposit: internally the receiver, from, and operator roles are all set to senderAddress.

Parameters

Parameter
Type
Required
Description

contractId

string

Yes

Stellar vault contract address (C…).

amount

string

Yes

Amount in the deposit token's smallest unit (e.g. 1 USDC @ 7 dp β†’ "10000000").

senderAddress

string

Yes

User's Stellar account (G…); pays for and receives the deposit.

Example

Optionally preview the shares a deposit would mint before building it:

Vault Redeem

Build an unsigned redeem transaction. Redeem burns shares (not asset amount), so read the user's position first. This is a self-redeem: receiver, owner, and operator roles are all set to receiverAddress.

Parameters

Parameter
Type
Required
Description

contractId

string

Yes

Stellar vault contract address (C…).

shares

string

Yes

Shares to redeem, in the share token's smallest unit.

receiverAddress

string

Yes

User's Stellar account (G…); receives the redeemed assets.

Example

Submit a Signed Transaction

submitTransaction broadcasts a signed XDR and polls until the network confirms it as successful, returning the transaction hash. The XDR must be signed for the same network the adapter is using.

Error Handling

submitTransaction throws typed August SDK errors:

  • AugustTimeoutError β€” the transaction was not confirmed within the poll budget.

  • AugustSDKError β€” the RPC rejected the submission, or the transaction confirmed as failed. Inspect err.context for { network, status } and, when the result XDR decodes, a resultCode string carrying the transaction-level reason (e.g. "txBadSeq", "txTooLate"). resultCode is undefined when it cannot be decoded.

Networks

sdk.stellar is hardwired to mainnet. To target testnet, use the Stellar namespace directly with an explicit network:

Notes & Caveats

  • Self-deposit / self-redeem only. All role addresses are set to the single account you pass; there is no third-party/operator variant.

  • Standard vault ABI assumed. Redeem assumes the deployed vault exposes redeem(shares, receiver, owner, operator). A divergent ABI surfaces as a generic Soroban simulation error.

  • Read-only on the vaults module. Available redemptions and redemption history are not yet supported for Stellar vaults; deposit/redeem are available only on sdk.stellar.

Last updated