Stellar's traditional payment network operated with a simple fee-based priority model where validators nominally ordered transactions by fee rate, leaving little surface area for complex Maximal Extractable Value (MEV) extraction. The introduction of Soroban smart contracts fundamentally alters this landscape. Soroban brings general-purpose execution, state dependencies, and composable contract interactions to Stellar, creating the same structural preconditions that have made MEV a multi-billion dollar phenomenon on Ethereum and other smart contract platforms.
Protocols
MEV and Transaction Ordering Fairness
Investigates the potential for Maximal Extractable Value on Stellar, particularly with the introduction of Soroban's smart contract execution. Analyzes the transaction submission path, the role of validators in ordering, and whether the current fee model creates opportunities for front-running or sandwich attacks.
introduction
TRANSACTION ORDERING FAIRNESS
Introduction
How Stellar's transaction submission path and Soroban's smart contract execution create new vectors for Maximal Extractable Value.
The core risk lies in the transaction lifecycle. A user submits a transaction to Stellar's overlay network, it sits in a pending queue, and validators in the Stellar Consensus Protocol (SCP) ultimately nominate and commit transaction sets. While SCP does not have a single leader proposing blocks in the way Ethereum's proposer-builder separation (PBS) does, validators with visibility into the pending transaction pool can theoretically reorder, insert, or censor transactions within the sets they nominate. For Soroban contracts, this creates the potential for front-running, sandwich attacks, and arbitrage extraction, particularly against decentralized exchanges, lending protocols, and oracle-dependent applications.
The current fee model—a static per-operation fee with surge pricing—was not designed to price the value of transaction ordering. This mismatch means that a validator or a sophisticated bot connected to a validator can extract value by paying the same fee as a victim while capturing the profit from reordering. The operational impact extends to all Soroban developers: contracts that assume atomic execution without considering ordering manipulation are vulnerable. Chainscore Labs can review Soroban contract architectures for MEV vulnerability, model the transaction submission path for adversarial behavior, and help teams design submission strategies—such as private mempool submission or commit-reveal patterns—that minimize extraction risk before mainnet exposure.
TRANSACTION ORDERING AND EXTRACTION RISKS
Quick Facts: Stellar MEV Landscape
Evaluates the potential for Maximal Extractable Value on Stellar, particularly with Soroban smart contracts, and identifies affected actors and recommended actions.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Transaction Ordering | Soroban introduces a deterministic, fee-based ordering model without a public mempool, but validators control transaction set inclusion. | Soroban DeFi protocols, arbitrageurs, wallet providers | Review the Stellar Core transaction queue logic and model ordering guarantees for time-sensitive contract interactions. |
Front-running Risk | Without a cryptographic commit-reveal scheme, validators could theoretically inspect and preempt pending transactions they receive directly. | DEX aggregators, AMM liquidity providers, high-value traders | Design submission strategies that minimize pre-confirmation exposure, such as submitting directly to multiple validators. |
Sandwich Attacks | The lack of a public mempool makes generalized sandwiching difficult, but validator collusion or compromised nodes could enable targeted attacks. | Soroban AMM users, liquidity providers, MEV searchers | Monitor on-chain sequencing for anomalous back-running patterns and assess contract-level protections like slippage limits. |
Fee Market Dynamics | Soroban uses a resource-based fee model with surge pricing. Bidding for inclusion could create a priority gas auction dynamic. | Node operators, contract developers, exchanges | Model cost exposure under adversarial conditions and test contract behavior during resource congestion. |
Validator Centralization | A small set of validators, heavily influenced by the SDF, controls transaction ordering. This concentrates the trust required to resist MEV extraction. | Protocol governance, risk teams, institutional integrators | Monitor quorum set centralization and advocate for validator diversity to reduce single-entity ordering control. |
Cross-Chain MEV | Bridges and cross-chain protocols introduce ordering dependencies between Stellar and other chains, creating new MEV surfaces. | Bridge operators, cross-chain arbitrageurs, liquidity networks | Audit bridge relayer logic for atomicity violations and monitor for cross-domain arbitrage that exploits Stellar finality. |
Contract Vulnerability | Poorly designed Soroban contracts can leak value through ordering dependencies, oracle update timing, or liquidation sequencing. | DeFi protocol developers, security auditors | Conduct specialized MEV-focused security reviews of Soroban contracts before mainnet deployment. |
Operational Monitoring | Detecting MEV extraction requires new monitoring for validator behavior, transaction ordering anomalies, and extractable value patterns. | Infrastructure providers, data teams, risk analysts | Implement MEV-aware monitoring dashboards and alerting for unexpected validator sequencing behavior. |
technical-context
TRANSACTION LIFECYCLE AND EXTRACTION POINTS
Technical Mechanism: The Ordering Surface
A technical breakdown of where MEV opportunities arise in Stellar's transaction submission, ordering, and execution pipeline, particularly with the introduction of Soroban.
On Stellar, the ordering surface is defined by the path a transaction takes from submission to final inclusion in a ledger. Unlike Ethereum's public mempool, Stellar uses a federated model where transactions are submitted directly to validators. The Stellar Consensus Protocol (SCP) then nominates and commits transaction sets through a federated voting process, not a single-leader election. This architecture does not eliminate MEV; it shifts the extraction point. The primary opportunity for ordering manipulation lies within the narrow window where a validator assembles a candidate transaction set for a new ledger, making validators the gatekeepers of short-term ordering power.
The introduction of Soroban fundamentally expands this surface. Simple payment operations have a deterministic fee and execution cost, limiting complex MEV strategies. Soroban smart contracts, however, introduce state-dependent execution with variable costs. An adversary can now simulate a contract call's state changes, identify profitable opportunities like arbitrage or liquidations, and submit a competing transaction with a higher fee. The Stellar fee model, where the highest fee-paying transaction in a set is prioritized, creates a direct incentive for priority gas auctions (PGAs) within the Soroban environment. This transforms the validator's transaction set assembly from a simple ordering task into a potential auction block, where sophisticated searchers can compete for inclusion.
For builders and operators, the key risk is not just front-running but also the potential for 'sandwiching' in Soroban AMM or lending protocols. A validator, or a searcher colluding with one, can observe a pending user transaction that will move a price, insert their own buy transaction before it, and a sell transaction after it, extracting risk-free profit at the user's expense. The operational impact is a degradation of execution quality for normal users and a systemic incentive for validators to prioritize MEV extraction over neutral network operation. Chainscore can review Soroban contract architectures to identify these ordering-dependent vulnerabilities and help teams design submission strategies, such as commit-reveal schemes or private transaction channels, that minimize extraction risk before mainnet deployment.
MEV AND TRANSACTION ORDERING FAIRNESS
Affected Stakeholders
Validator & Node Operator Impact
Stellar validators are the primary gatekeepers for transaction ordering. With Soroban, validators gain the ability to propose blocks that include complex, state-dependent smart contract executions. This introduces a new attack surface: validators could theoretically reorder transactions within a ledger to extract value from Soroban contract interactions.
Key Risks:
- Reputational damage from perceived or actual MEV extraction.
- Increased operational complexity if running private mempool infrastructure to capture MEV.
- Potential for network instability if validators delay block production to optimize ordering.
Action Items:
- Audit your node's transaction selection logic to ensure it follows a deterministic, time-ordered queue.
- Monitor for validators deviating from the canonical ordering algorithm.
- Engage in governance discussions around formalizing fair-ordering commitments at the protocol level.
implementation-impact
MEV RESISTANCE
Mitigation Strategies & Design Patterns
Practical design patterns and operational strategies for builders and integrators to minimize MEV extraction risk on Stellar, particularly within Soroban's smart contract environment.
01
Commit-Reveal Schemes
Implement a two-phase submission process for sensitive transactions. Users first submit a hash of their intended action, wait for it to be included in a ledger, and then reveal the action. This prevents validators from front-running because the transaction content is hidden during the ordering phase. This pattern is critical for Soroban contracts handling blind auctions, sealed-bid order books, or any DeFi operation where advance knowledge of the payload creates a value-extraction opportunity.
02
Slippage Protection and Order Expiry
Design Soroban contracts and client-side integrations to enforce strict maximum slippage tolerances and short-lived transaction timebounds. A transaction that specifies a minimum output amount and a validity window of only a few ledgers drastically limits the window for a sandwich attack. If a validator reorders transactions to manipulate the price, the victim's transaction will simply fail and revert, making the attack unprofitable. This is a fundamental defense for AMM interactions on Stellar.
03
Off-Chain Ordering with On-Chain Settlement
Move the price-discovery and order-matching logic off-chain using a trusted execution environment or a network of matchmakers, and only use the Stellar network for atomic settlement. This architecture, common in high-frequency trading, prevents validators from seeing the order flow before execution. For Soroban, this means the contract only verifies signatures and executes a pre-agreed settlement, eliminating the information asymmetry that enables MEV at the protocol level.
04
Batch Auction Mechanisms
Instead of processing transactions sequentially, design Soroban protocols to collect orders over a discrete time window and execute them at a uniform clearing price. This eliminates the concept of transaction 'priority' within the batch, making front-running and sandwiching structurally impossible. The Stellar network's ledger close time provides a natural cadence for these batches, turning a potential MEV vulnerability into a fair-ordering design pattern for DEXs and liquidation markets.
05
Chainscore MEV-Resistance Review
Chainscore Labs can perform a targeted review of your Soroban smart contract's vulnerability to MEV extraction. This includes analyzing the transaction submission path, modeling potential front-running and sandwich attack vectors under the current fee model, and auditing the contract's economic logic for manipulation risks. We deliver a detailed report with actionable mitigation strategies, from contract-level fixes to operational submission patterns that minimize extraction risk for your users.
TRANSACTION ORDERING AND EXTRACTION RISK ASSESSMENT
MEV Risk Matrix for Stellar
Evaluates the potential for Maximal Extractable Value (MEV) on Stellar, particularly with the introduction of Soroban smart contracts. Identifies affected actors, failure modes, and actionable steps for operators and builders.
| Risk Area | Failure Mode | Severity | Affected Actors | Mitigation and Action |
|---|---|---|---|---|
Soroban Sandwich Attacks | Validators or bots reorder Soroban transactions to front-run or back-run a user's trade, extracting value via slippage. | High | Soroban DeFi traders, AMM liquidity providers, wallet users | Implement commit-reveal schemes or use off-chain order matching. Chainscore can review Soroban contract vulnerability to priority ordering. |
Generalized Front-Running | A non-Soroban transaction (e.g., creating a trustline to a scarce asset) is observed in the mempool and front-run. | Medium | Asset issuers, arbitrageurs, users claiming limited offers | Submit transactions via trusted validators or use low-latency submission paths. Monitor mempool visibility policies of connected nodes. |
Validator Transaction Prioritization | Validators with privileged mempool access prioritize their own transactions or those of fee-paying parties, breaking fair ordering. | High | All network users, exchanges, market makers | Diversify validator trust assumptions. Chainscore can help design submission strategies that minimize reliance on a single validator's ordering fairness. |
Soroban Fee Model Exploitation | Attackers craft complex Soroban transactions with low fees that consume excessive resources, crowding out legitimate transactions. | Medium | Soroban developers, network users during congestion | Model worst-case resource consumption. Chainscore can audit Soroban contracts for resource efficiency and cost exposure under adversarial conditions. |
Cross-Program Atomicity Abuse | An attacker exploits the atomic execution of multiple Soroban contract calls within a single transaction to extract value across different protocols. | Medium | Soroban DeFi protocols with composable logic | Audit cross-contract call flows for manipulation vectors. Implement circuit breakers on protocol interactions. |
Mempool Sniping on Bridges | A user's bridge deposit transaction is observed, and a front-running transaction claims the corresponding wrapped asset mint on Stellar first. | Low | Bridge operators, users bridging assets to Stellar | Use a unique claimant identifier tied to the source-chain transaction hash. Verify bridge contract authorization logic against canonical source. |
Time-Bandit Attacks | A validator reorgs recent ledger history to capture MEV opportunities that have already passed, undermining finality. | Low | Exchanges, high-value settlement users | Wait for sufficient ledger confirmation depth. The Stellar Consensus Protocol's safety guarantees make this difficult but not impossible under extreme network partitions. |
MEV SURVEILLANCE FOR STELLAR OPERATORS
Monitoring and Detection Checklist
A practical checklist for validators, builders, and integrators to detect and assess MEV activity on Stellar, particularly with the introduction of Soroban smart contracts. This guide focuses on signals of front-running, sandwiching, and priority gas auction (PGA) behavior within the transaction submission path.
What to check: Analyze the ordering of Soroban transactions within a single ledger close. Look for patterns where a transaction interacting with a known DeFi contract is immediately preceded or followed by a related transaction from a different source account.
Why it matters: Unlike simple payment transactions, Soroban contract calls have state dependencies. A validator (or a user colluding with one) could order transactions to extract value, such as front-running an oracle update or sandwiching a large swap.
Signal to confirm: A statistically significant clustering of related contract calls (e.g., same contract, overlapping state access) from disparate accounts within the same ledger, especially when the 'victim' transaction has a higher fee but was not prioritized as expected.
resource-links
STELLAR ORDERING AND MEV REFERENCES
Source Resources
Use these primary resources to verify how Stellar orders transactions, prices inclusion, and executes Soroban contracts. Teams assessing MEV risk should compare application assumptions against protocol code, CAP discussions, and live ledger behavior.
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.
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.
MEV AND ORDERING FAIRNESS FAQ
Frequently Asked Questions
Practical answers for builders, validators, and integrators evaluating transaction ordering risks on Stellar, particularly with the introduction of Soroban smart contracts.
Stellar's Stellar Consensus Protocol (SCP) does not use a mempool-based, time-ordered leader election like Ethereum. Instead, validators federate on transaction sets. This architecture makes generalized front-running more difficult but does not eliminate it entirely.
Key considerations:
- No public mempool: Transactions are not broadcast in a pending pool visible to searchers, reducing the surface for mempool sniping.
- Validator ordering power: The validator that nominates a transaction set has discretion over ordering within that set. A malicious or extractive validator could theoretically sequence transactions to their advantage.
- Soroban changes the game: Smart contracts introduce state-dependent execution where the output of one contract call can affect another. This creates a classic MEV surface that did not exist with simple payment operations.
What to watch: Monitor whether validators begin offering private transaction submission channels or if specialized block-building services emerge, as these are leading indicators of a developing MEV supply chain.
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.”
L
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.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
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
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.