Skip to main content
Every state-changing operation on Vanna follows the same four-step pattern: build → simulate → sign → submit. This page explains each step and provides reusable utilities.

The Four Steps

1

Build the transaction

Create an InvokeHostFunction operation that calls the target contract and method with encoded arguments.
2

Simulate

Send the unsigned transaction to the Soroban RPC’s simulateTransaction endpoint. This returns the required authorization entries, computed resource fees, and the expected return value — without submitting to the network.
3

Sign with Freighter

Attach the simulation’s auth entries and fees to the transaction, then ask Freighter to sign the XDR-encoded transaction.
4

Submit and wait

Submit the signed transaction via sendTransaction(). Poll with getTransaction() until the status is SUCCESS or FAILED.

Core Utility


Encoding Arguments

Soroban contract arguments are xdr.ScVal values. The Stellar SDK provides nativeToScVal to convert JavaScript primitives:

Decoding Return Values


Example: Deposit XLM Into Lending Pool


Example: Borrow XLM via AccountManager


Example: Read-Only (Simulation Only)

For pure reads you don’t need to sign or submit — just simulate with any dummy account:

Handling Token Approvals

Most Soroban token operations require the caller to pre-authorize token transfers. For the Stellar SDK, this is handled automatically via the simulation’s auth entries — assembleTransaction attaches them. However, some operations require an explicit approve() call on the token contract before the main transaction:

Resource Limits and Fee Estimation

Soroban transactions have CPU, memory, and ledger entry limits. The simulation returns resource estimates — assembleTransaction applies them. If a transaction is consistently failing with resource errors, increase the fee budget:

Next Steps