Summary
Every Stellar SDK (Python, JS, Java, Go) provides a high-level TransactionBuilder for constructing, signing, and submitting transactions. Rust has no equivalent — developers must work directly with stellar-xdr types, which is low-level and error-prone.
The CLI already contains transaction-building logic (builder traits, operation construction, signing, simulation/assembly), but it's tightly coupled to CLI concerns (clap, config, printing). Extracting this into a standalone crate would fill the gap and give Rust developers a first-class transaction building experience.
What exists today in the CLI
TxExt trait for building transactions (tx/builder/transaction.rs) — already has no CLI dependencies
Amount and Asset helpers (tx/builder/)
Assembled struct for post-simulation transactions (assembled.rs) — depends only on stellar-xdr + soroban-rpc
Signer abstraction with local key, Ledger, Lab, and secure store backends (signer/)
- 23 operation builders (
commands/tx/new/) — currently coupled to clap/config
- Soroban authorization signing — mostly pure crypto
Proposed scope
A new workspace crate (e.g. cmd/crates/stellar-transaction-builder/) providing:
TransactionBuilder with a fluent API matching other SDKs: source account, fee, sequence number, operations, memo, preconditions, build()
- Operation helper functions for all 23 operation types (pure functions: XDR types in,
OperationBody out)
TransactionSigner trait decoupled from CLI printing/config
Assembled transaction wrapper and simulation support (feature-gated behind rpc)
- Soroban auth signing utilities
What stays in the CLI
sim_sign_and_send_tx orchestrator (caching, printing, explorer URLs)
- clap argument parsing and config/address resolution
- User interaction (prompts, confirmations)
Prior art
- Python:
stellar_sdk.TransactionBuilder — fluent method chaining, 60+ operation append methods
- JS:
StellarSdk.TransactionBuilder — constructor with options, addOperation(), build()
- Java:
org.stellar.sdk.TransactionBuilder — builder pattern with method chaining
- Go:
txnbuild.NewTransaction(TransactionParams{...}) — struct-based params with operation array
All follow the same separation: building (pure) → simulation (async) → signing (crypto) → submission (async).
Suggested approach
- Create the new crate alongside existing code (no breaking changes to CLI)
- Migrate CLI to consume the new crate incrementally
stellar-ledger already demonstrates this extraction pattern successfully
Summary
Every Stellar SDK (Python, JS, Java, Go) provides a high-level
TransactionBuilderfor constructing, signing, and submitting transactions. Rust has no equivalent — developers must work directly withstellar-xdrtypes, which is low-level and error-prone.The CLI already contains transaction-building logic (builder traits, operation construction, signing, simulation/assembly), but it's tightly coupled to CLI concerns (clap, config, printing). Extracting this into a standalone crate would fill the gap and give Rust developers a first-class transaction building experience.
What exists today in the CLI
TxExttrait for building transactions (tx/builder/transaction.rs) — already has no CLI dependenciesAmountandAssethelpers (tx/builder/)Assembledstruct for post-simulation transactions (assembled.rs) — depends only onstellar-xdr+soroban-rpcSignerabstraction with local key, Ledger, Lab, and secure store backends (signer/)commands/tx/new/) — currently coupled to clap/configProposed scope
A new workspace crate (e.g.
cmd/crates/stellar-transaction-builder/) providing:TransactionBuilderwith a fluent API matching other SDKs: source account, fee, sequence number, operations, memo, preconditions,build()OperationBodyout)TransactionSignertrait decoupled from CLI printing/configAssembledtransaction wrapper and simulation support (feature-gated behindrpc)What stays in the CLI
sim_sign_and_send_txorchestrator (caching, printing, explorer URLs)Prior art
stellar_sdk.TransactionBuilder— fluent method chaining, 60+ operation append methodsStellarSdk.TransactionBuilder— constructor with options,addOperation(),build()org.stellar.sdk.TransactionBuilder— builder pattern with method chainingtxnbuild.NewTransaction(TransactionParams{...})— struct-based params with operation arrayAll follow the same separation: building (pure) → simulation (async) → signing (crypto) → submission (async).
Suggested approach
stellar-ledgeralready demonstrates this extraction pattern successfully