Stellar Transaction Submission & Mempool Management

introduction

MEMPOOL AND NONCE MANAGEMENT

Reliable Transaction Submission on Stellar

How Stellar Core's transaction queue processes submissions, enforces ordering, and why exchanges and high-frequency applications must handle nonce gaps, fee bidding, and error codes precisely.

Stellar Core maintains a per-source-account transaction queue, not a global mempool. Each account's transactions are ordered strictly by sequence number. A submission with a sequence number that is not exactly one greater than the account's current ledger sequence is rejected with tx_TOO_EARLY or tx_TOO_LATE. This design eliminates nonce gaps but creates a head-of-line blocking problem: a single stuck transaction can prevent all subsequent transactions from the same account from being applied.

To manage this, operators must implement a submission loop that handles tx_TOO_EARLY by retrying after the current ledger closes and tx_TOO_LATE by re-fetching the account sequence and resubmitting. During fee surges, Stellar's dynamic fee auction requires transactions to bid above the current ledger's effective fee to be included. The fee_charged field in transaction results reflects the actual fee deducted, which may differ from the max_fee specified. Soroban transactions add resource fee dimensions for CPU instructions, RAM, and ledger I/O, requiring preflight simulation to estimate costs before submission.

Exchanges and custodians managing high-throughput accounts should implement a bounded transaction buffer, pre-allocate sequence numbers, and use CHANGE_TRUST and CLAIMABLE_BALANCE operations to decouple deposit flows from the hot wallet's sequence. Monitoring for tx_BAD_AUTH_EXTRA and tx_INSUFFICIENT_FEE errors provides early warning of misconfigured signatures or fee estimation logic. Chainscore Labs can review submission architectures, retry logic, and Soroban resource estimation to prevent stuck transactions and ensure reliable settlement under load.

MEMPOOL AND SUBMISSION OPERATIONS

Transaction Lifecycle Quick Facts

Key operational facts about how transactions enter the Stellar Core transaction queue, how they are ordered, and what causes them to be rejected or dropped. Use this table to validate submission logic and error-handling strategies.

Area	What changes	Who is affected	Action
Transaction ordering	Transactions are ordered by fee rate (stroops per operation) within the ledger, not by submission time. A higher fee rate is required to jump the queue during surge pricing.	Exchanges, high-frequency bots, wallet providers	Implement fee-bumping or fee-rate calculation logic. Monitor surge pricing conditions to avoid stuck transactions.
Sequence number management	Stellar enforces strict sequential account sequence numbers. A gap or reuse causes tx_BAD_SEQ. Submitting with a future sequence number causes tx_BAD_SEQ until the account catches up.	Custodians, exchanges managing many accounts, automated agents	Build a sequence number cache updated after each successful submission. Use Horizon's next_sequence_number endpoint. Implement retry logic for tx_BAD_SEQ.
Transaction validity window	Transactions include a minTime and maxTime bound. If the ledger close time is outside this window, the transaction is rejected with tx_TOO_EARLY or tx_TOO_LATE.	All submitters, especially those building transactions offline or queuing them	Set a generous but bounded validity window (e.g., 2-5 minutes). Rebuild and resubmit if rejected for time bounds. Do not use an unbounded maxTime of 0.
Mempool admission	Stellar Core's transaction queue has a limited size per ledger. During congestion, low-fee transactions are dropped from the queue to make room for higher-fee transactions.	High-volume applications, arbitrage bots, airdrop distributors	Monitor the surge pricing threshold. Implement fee-bumping (CAP-0015) to increase the fee of a stuck transaction without changing its sequence number.
Transaction result codes	Stellar Core returns a TransactionResult code. Common failures include tx_INSUFFICIENT_BALANCE, tx_BAD_AUTH (invalid signatures), and tx_INTERNAL_ERROR. Soroban transactions return a separate InvokeHostFunctionResult.	Integration developers, exchange operations teams	Parse the full result XDR. Do not rely solely on HTTP status codes. Log and alert on unexpected tx_INTERNAL_ERROR results. Verify Soroban result codes against the contract's expected behavior.
Soroban resource fees	Soroban transactions consume CPU instructions, RAM, and ledger I/O. The total resource fee is computed pre-flight and deducted from the source account's balance. If the actual consumption exceeds the estimate, the transaction fails and fees are still consumed.	Soroban smart contract developers, wallet providers	Use simulateTransaction to get an accurate resource estimate before submission. Add a safety margin to the resource fee. Instruct users on the refundable fee model to manage expectations.
Submission retry logic	A transaction rejected with tx_BAD_SEQ or tx_TOO_LATE must be rebuilt with a new sequence number or time bounds before resubmission. A transaction rejected with tx_INSUFFICIENT_FEE can be resubmitted with a higher fee.	All automated submitters	Categorize errors into 'rebuild required' and 'resubmit possible'. Implement exponential backoff for network errors. Do not blindly retry a transaction that failed with a sequence number error.

technical-context

MEMPOOL MANAGEMENT AND LIFECYCLE

The Stellar Core Transaction Queue

How Stellar Core receives, sequences, and forwards transactions before they are applied to the ledger, and the operational constraints that builders must manage.

Stellar Core's transaction queue is the gateway between a submitted transaction and its inclusion in a closed ledger. Unlike fee-prioritized mempools in other protocols, Stellar's queue is primarily ordered by the source account's sequence number, enforcing strict per-account ordering. This design eliminates nonce-gap uncertainty but introduces a unique operational constraint: a single stuck transaction can block all subsequent submissions from the same account until it is resolved or expires. The queue is managed in-memory by each validator and is not part of the consensus state; transactions are gossiped between peers but only applied when a validator proposes a candidate transaction set during consensus.

The lifecycle of a transaction in the queue is governed by its minTime and maxTime bounds, which define the ledger close window in which it is valid. A transaction is rejected with tx_TOO_EARLY if the current ledger close time is before its minTime, and with tx_TOO_LATE if it is after its maxTime. This mechanism is critical for pre-signed transactions and time-sensitive operations, but it is also a common source of integration errors. High-frequency applications, such as exchanges, must carefully manage nonce ordering and time bounds to avoid head-of-line blocking. A transaction with a maxTime far in the future can clog the queue, while one with a narrow window risks permanent failure during network congestion.

Fee bidding in Stellar's queue operates as a secondary ordering mechanism within the constraints of sequence number ordering. When multiple transactions for the same source account are in the queue, Stellar Core uses a fee-bump auction to select the transaction that will be applied next, allowing a higher-fee transaction to replace a lower-fee one with the same sequence number. However, this does not allow a transaction with sequence number N+1 to bypass a stuck transaction at sequence number N. Operators must implement robust nonce management, including pre-flight checks for tx_TOO_EARLY and tx_TOO_LATE errors, and a retry strategy that accounts for ledger close cadence. Chainscore Labs can review exchange and wallet transaction submission logic to identify queue-blocking failure modes and improve submission reliability under high throughput.

IMPACT ANALYSIS

Who Is Affected

Exchange & Custodian Impact

High-frequency deposit/withdrawal pipelines are directly exposed to mempool management failures. Nonce ordering errors (tx_bad_seq) and fee mispricing during surge conditions can halt all automated operations.

Key risks:

Stuck transaction chains: A single tx_TOO_LATE failure can block all subsequent transactions for an account, requiring manual intervention to clear the queue.
Fee auction losses: During network congestion, static fee configurations will be outbid, causing time-sensitive withdrawals to fail.
Horizon ingestion lag: Submitting transactions based on stale Horizon state leads to incorrect sequence numbers.

Action: Implement a dynamic fee-bumping strategy with exponential backoff. Build a nonce manager that can detect and clear stuck sequences. Chainscore can review your submission pipeline for race conditions and surge-price resilience.

implementation-impact

RELIABLE TRANSACTION PROPAGATION

Core Submission Strategies

Strategies for constructing and submitting transactions that land reliably in the next ledger, even under high contention.

Nonce Management and Ordering

Stellar enforces strict sequential account nonces. A gap in sequence numbers will halt all subsequent transactions for that source account. High-frequency applications must implement a monotonically incrementing counter, synchronized with the latest ledger state. For exchanges operating multiple submission workers, use a distributed atomic counter or a single-threaded submission queue per source account to prevent nonce collisions. Always query Horizon's next_sequence_number immediately before building a transaction to avoid tx_bad_seq errors caused by a pending transaction consuming the expected nonce.

Fee Bidding and Surge Pricing

During network congestion, transactions are prioritized by fee per operation in the transaction queue. A static fee will result in tx_too_late errors as higher-paying transactions displace yours. Implement a dynamic fee-bumping strategy: monitor recent ledger fee statistics from Horizon's /fee_stats endpoint and set the max_fee to a percentile above the current mode. For Soroban transactions, account for both the inclusion fee and the resource fees for CPU and RAM. Wallets and exchanges should allow users or automated systems to pre-sign fee-bump transactions, enabling a child transaction to replace a stuck parent without re-authorization.

Preflight and Soroban Simulation

Soroban transactions require resource cost estimation before submission. Use the simulateTransaction RPC endpoint to preflight the contract invocation. This returns the minimum resource fees, the exact footprint, and the latest ledger sequence number required for a valid transaction. Failing to preflight will result in a failed submission. Your system must assemble the transaction envelope from the simulation results and submit it within the validity window of the ledger. For time-sensitive operations, build a retry loop that re-simulates and re-submits if the ledger advances before the transaction is included.

Submission Retry and Error Handling

A robust submission pipeline must handle tx_too_early, tx_too_late, and tx_bad_seq gracefully. tx_too_early indicates the timebounds are set in the future; wait and resubmit. tx_too_late means the transaction was displaced from the queue; re-fetch the account state, rebuild with a higher fee, and resubmit. tx_bad_seq requires a full state refresh before retrying. Implement exponential backoff with jitter for transient network errors, but fail fast on deterministic errors like tx_insufficient_balance. Always log the full transaction result XDR for post-mortem analysis.

Channel Accounts for Throughput

A single source account's sequential nonce creates a hard throughput ceiling of one transaction per ledger. To scale beyond this, use channel accounts: a pool of pre-funded, co-signing accounts that distribute the nonce sequence across multiple submission lanes. Each channel account submits independently, allowing parallel transaction processing. The coordinating service must round-robin or load-balance across the pool and monitor each channel's balance and sequence number. This pattern is essential for exchanges processing high-frequency deposits and withdrawals.

Timebounds and Transaction Expiry

Every Stellar transaction includes a validity window defined by minTime and maxTime. Set minTime to the current ledger close time to prevent replay, and set maxTime to a point far enough in the future to allow for network latency and retries, but not so far that a stale transaction could unexpectedly execute. A common pattern is a 2-5 minute window. If a transaction is not included before maxTime, it is permanently invalid. Your submission system must detect this and rebuild the transaction with fresh timebounds before retrying.

TRANSACTION SUBMISSION FAILURE MODES

Error Mode and Risk Matrix

Common failure modes when submitting transactions to Stellar Core, their causes, affected systems, and required operational responses.

Error Mode	Failure Cause	Affected Systems	Severity	Mitigation
tx_TOO_EARLY	Transaction submitted with a timebound that is not yet valid (MinTime in the future)	Exchanges, wallets, automated payment systems	Medium	Verify clock synchronization with NTP; implement client-side pre-validation of timebounds before submission
tx_TOO_LATE	Transaction submitted after its timebound has expired (MaxTime in the past)	High-frequency traders, time-sensitive settlement systems	High	Set generous MaxTime windows (e.g., 5 minutes); implement retry logic that rebuilds the transaction with fresh timebounds
tx_BAD_SEQ	Sequence number mismatch due to nonce gap, duplicate submission, or unconfirmed prior transaction	Custodians, exchanges managing many accounts, parallel submitters	Critical	Implement a source-account sequence number cache; serialize submissions per source account; use tx_INSUFFICIENT_FEE as a signal to re-fetch account state
tx_INSUFFICIENT_FEE	Fee bid too low to enter the transaction queue during surge pricing	Wallets with static fee estimation, DeFi protocols, arbitrage bots	High	Implement dynamic fee estimation using Horizon /fee_stats; build a fee-bumping strategy using FeeBumpTransaction for time-critical operations
tx_INTERNAL_ERROR	Stellar Core rejected the transaction due to an internal processing error, often during high load	All submitters during network congestion or node resource exhaustion	Medium	Retry with exponential backoff; submit to a different Stellar Core node; monitor node health metrics for resource saturation
Transaction stuck in queue	Transaction entered the mempool but is not being included in a ledger close due to low fee or ledger surge	Time-sensitive applications, liquidations, oracle updates	High	Monitor transaction status via Horizon /transactions/:hash; implement a fee-bump or replace-by-fee strategy; set a submission timeout and resubmit with a higher fee
Silent submission failure	Horizon or SDK accepted the transaction but it never reached Stellar Core or was dropped without error	All integrators relying on Horizon submission without direct Core fallback	Critical	Always verify submission against Stellar Core's transaction status; implement a direct Stellar Core submission path as a fallback; monitor for Horizon ingestion lag
Account merge race condition	Transaction submitted to a source account that was merged via AccountMerge operation before the transaction executed	Custodians closing accounts, exchanges performing account consolidation	High	Implement a pre-submission check for account existence; serialize merge operations with other submissions; verify account state after merge before submitting dependent transactions

PRODUCTION READINESS FOR HIGH-THROUGHPUT ENVIRONMENTS

Submission System Implementation Checklist

A systematic checklist for exchanges, custodians, and high-frequency applications to validate their transaction submission architecture against Stellar's mempool behavior, nonce ordering, and fee-bidding mechanics before production deployment.

What to check: Verify that your submission system maintains a strictly sequential, per-source-account nonce counter that is atomically incremented on successful submission, not on transaction construction.

Why it matters: Stellar enforces strict sequential nonce ordering. A gap or duplicate nonce causes tx_BAD_SEQ, while a nonce that is too far in the future causes tx_TOO_EARLY. In high-throughput environments, concurrent submissions from the same source account will fail if the nonce counter is not synchronized across submission threads.

Readiness signal: Your system correctly handles a burst of 100 transactions from a single source account without a single nonce-related error. The nonce counter is sourced from the latest ledger state, not a local cache.

resource-links

STELLAR OPERATIONS

Canonical Resources

Canonical references for Stellar transaction submission and mempool management, including sequence-number handling, fee bidding, Horizon submission, Stellar Core behavior, and operational monitoring.

Stellar Transaction Fundamentals

Use the official Stellar transaction documentation as the baseline for transaction envelopes, source accounts, sequence numbers, fees, time bounds, and operation ordering. For transaction submission systems, this is the first place to validate assumptions behind tx_bad_seq, tx_TOO_EARLY, and tx_TOO_LATE handling. Exchanges and wallets should map these rules directly into nonce management, transaction construction, replay prevention, and retry policies rather than treating Stellar transactions like account-nonce models from other chains.

EXPLORE

Horizon Submit Transaction API

Horizon remains a common submission interface for payments, exchange withdrawals, and wallet flows. Review the official submit endpoint behavior, response format, and error reporting before implementing retry logic. A failed submission response can indicate malformed XDR, bad sequence ordering, insufficient fee, expired time bounds, or network-side rejection. Production systems should persist the submitted transaction hash, distinguish final failures from transient submission failures, and avoid blindly regenerating transactions without checking account sequence state.

EXPLORE

Stellar Core Source and Release Notes

Stellar Core is the authoritative implementation for consensus participation, transaction admission, queueing, surge pricing, and ledger close behavior. Operators should track the stellar-core repository and release notes for changes that affect transaction submission reliability, fee behavior, validation rules, or node configuration. Before upgrading production infrastructure, test representative high-throughput submission workloads against the target Core version and verify that Horizon, RPC, SDKs, and internal nonce managers observe the same transaction outcomes.

EXPLORE

Stellar SDKs and Client Libraries

Official and ecosystem SDKs encode transaction building, signing, XDR serialization, fee setting, and submission helpers. Integration teams should track SDK lifecycle status and avoid relying on deprecated helpers for sequence fetching or automatic retries. For high-frequency applications, treat SDK submission methods as building blocks, not a complete mempool strategy: explicitly control time bounds, fee bids, sequence reservation, idempotency keys, and error classification in application code.

EXPLORE

Stellar Go Repository for Horizon and XDR Tooling

The stellar/go repository contains important implementation code for Horizon, protocol client tooling, XDR bindings, and Go-based integration components. Teams operating their own Horizon instance or building submission infrastructure should use this repository to confirm behavior that may not be fully obvious from API documentation alone, including response handling, ingestion dependencies, and generated protocol types. Pin versions deliberately and test XDR parsing whenever Stellar Core or protocol definitions change.

EXPLORE

Stellar Network Status

Use the official Stellar status page as part of transaction submission incident triage. Spikes in tx_TOO_LATE, submission timeouts, Horizon lag, or ledger close delays may be caused by local infrastructure, upstream API degradation, or broader network conditions. Exchanges, custodians, and payment operators should correlate internal queue depth, failed submissions, Horizon health, Stellar Core sync state, and public status updates before escalating to emergency fee changes or withdrawal pauses.

EXPLORE

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

TRANSACTION LIFECYCLE AND MEMPOOL OPERATIONS

Frequently Asked Questions

Common operational questions for exchanges, wallets, and high-frequency applications submitting transactions to the Stellar network. Covers nonce management, fee strategies, error handling, and mempool behavior.

Stellar requires strict sequential nonce ordering per source account. A gap or duplicate will cause a tx_BAD_SEQ error.

Operational checklist:

Maintain a local, thread-safe counter for each account's next sequence number.
After submission, increment the counter immediately. If the submission fails with a timeout (not a definitive error), do not increment.
Use Horizon's /accounts/{id} endpoint to fetch the current sequence number on startup or after a detected gap.
For high-throughput accounts, consider using a channel account pool to parallelize submissions without nonce contention.
Why it matters: A single stuck transaction with a low sequence number will block all subsequent transactions for that account until it is resolved or expires.
Readiness signal: Your system can sustain 100+ tx/min per source account without a tx_BAD_SEQ error under normal network conditions.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

Transaction Submission and Mempool Management

Reliable Transaction Submission on Stellar

Transaction Lifecycle Quick Facts

The Stellar Core Transaction Queue

Who Is Affected

Exchange & Custodian Impact