Onchain perpetual futures rely on fast, predictable order handling, and the sequencing of transactions can make or break trade outcomes. Over the past few years, transaction ordering has emerged as one of the most critical design challenges in onchain perpetual markets.
In practice, the order in which trades and cancellations are processed directly affects fill quality, slippage, and whether an order gets executed at all.
For example, whether a market maker’s cancellation lands before or after an incoming taker’s order can determine if the maker loses money on stale quotes. In short, onchain perps require deterministic, high-frequency sequencing. Even small reordering can lead to bad fills, failed cancels, and wildly inconsistent execution. In fact, many of the common issues in perp trading arise not from network latency or block time, but from transactions being reordered in unexpected ways.
Why ordering matters for perps
Perpetual exchanges rely on rapid processing of cancels, updates, market orders, and liquidations. Sequencing determines whether a cancel transaction takes effect before a matching trade, whether a limit order is hit at the intended price or at a stale quote, and whether large trades impact the order book in predictable ways.
In practice, a single missequenced order can cascade into losses and market instability. For example, a market maker might submit a cancellation just after the fair price moves, but if that cancel is processed after an incoming market order (rather than before), the taker trades at a better price and the maker is picked off on a stale quote.
Similarly, if an intended price-feed update or oracle data is inserted at the wrong point in a block, liquidation triggers can become unreliable. These effects compound under load, as during congestion ordering becomes inconsistent. Cancels may land after taker orders, takers may fill against stale quotes, and liquidation timing becomes unreliable. The result is wider spreads and thinner liquidity and unpredictable experience for traders.
Common problems from poor ordering include:
- Stale or poor fills. When transactions are reordered, trades may execute at worse prices. Outdated book state.
- Failed or late cancels. Cancellations can end up taking effect after the trade they were meant to avoid.
- Inconsistent execution. Identical orders sent at similar times can experience wildly different outcomes depending on subtle timing differences or queue positions.
- Degraded market quality. To compensate for the execution risk created by misordered transactions, liquidity providers widen spreads or reduce order sizes, leading to higher effective costs for takers.
These effects are similar to traditional market adverse selection and front-running in offchain finance, but onchain the transparency and transaction ordering mechanisms introduce a different set of challenges . It’s not just network speed or block time that’s the bottleneck, but rather the uncertainty and control over ordering that poses challenges to onchain perps today.
Front running and intent leakage: Ethereum vs. Solana
Before going deeper into Solana-specific fixes, it’s interesting to contrast the ordering idea on Solana with EVM-style chains like Ethereum.
On Ethereum, pending transactions sit in a public mempool, which is a globally visible pool of unconfirmed transactions. Bots scan this mempool for large trades or orders, then attempt to jump in front. They do so by paying higher gas fees or using miner collusion to prioritize their own transaction. This common pattern of front-running and sandwich attacks arises because every pending trade’s intent is fully visible to everyone before inclusion.
By contrast, Solana’s architecture does not use a single public mempool. Instead, Solana implements well-known Gulf Stream: transactions are forwarded directly to the upcoming block producer called leader.
In practice, wallets send transactions to validators, which then push them to the scheduled leaders. This means there is no global queue that everyone sees simultaneously. As a result, the typical Ethereum-style mempool scanning is harder on Solana.
Only the current leader and its few neighbors see incoming transactions before execution. While this reduces some forms of intent leakage, it does not eliminate extractive behavior entirely. Solana still allows priority fees and there is a default multi-threaded scheduler inside each validator.
In fact, research shows that Solana’s leader scheduler effectively orders transactions by a combination of FIFO and priority fees, but with inherent randomness between threads. This means that even without a global mempool, a fast searcher who submits a transaction quickly can sometimes outpace others to a given account’s data, and validators can still prioritize higher-fee transactions. As the Gate notes, on Solana bots can pay priority fees to ensure their transactions are processed before the target transaction, much like on Ethereum. Solana design mitigates the simple mempool front-running risk but still faces MEV: validators and bots with privileged access or high fees can reorder txns within their slots.
One important nuance is that describing this purely in terms of priority fees can be an oversimplification on Solana. In practice, a meaningful share of MEV has historically flowed through validator-side private orderflow, where searchers compete using direct validator tips and bundle-style delivery rather than relying only on the in-protocol priority fee. This effectively creates private mempool–like channels at the validator and builder layer. Intent is visible to a smaller set of actors, and ordering is influenced by offchain auctions and relationships, not just onchain fee fields.
Understanding these differences is crucial. On EVM chains, front-running is largely a public-mempool game, whereas on Solana it is more about validators’ scheduling and fees. Any comprehensive perp platform on Solana must therefore account for its unique propagation model. There’s no global intent leak to monitor, but there is leader-determined ordering and a priority-fee market.
One more thing is that bots paying priority fees can be an oversimplification on Solana. A share of MEV has historically flowed through validator-side private orderflow, where searchers compete with direct validator tips and bundle-style delivery rather than relying only on the in-protocol priority fee. This effectively creates private mempool-like channels at the validator/builder layer. Intent is visible to a smaller set of actors, and ordering is influenced by off-chain auctions and relationships, not just on-chain fee fields.
Current ordering infrastructure
Solana’s ecosystem is actively iterating on transaction ordering at two layers.
At the protocol layer, initiatives like Jito’s Block Assembly Marketplace (BAM), Harmonic, and the planned Application-Controlled Execution aim to reshape how blocks are assembled and how ordering decisions can be made more explicit.
At the application layer, perp venues experiment with custom execution paths. BULK is the clearest example, designed to reduce the practical uncertainty that comes from operating inside a general-purpose runtime and shared blockspace.
The Jito model
BAM’s core idea is to reduce opaque, leader-local ordering by interposing a block-building layer that can enforce policy and produce evidence. Instead of a single validator deciding what comes first, users submit transactions to BAM scheduling nodes running inside TEEs. Those nodes can privately filter and order transactions, and then forward an ordered bundle to the slot leader for execution.
The important shift is not perfect ordering, but more accountable ordering. If ordering rules are applied inside the enclave, the system can generate proofs that make those decisions auditable. The limitation is that this still sits inside Solana’s slot-based execution envelope and economic prioritization dynamics. Even with better visibility and enforcement hooks, applications are still competing for inclusion in a shared slot, and the system remains sensitive to congestion regimes and fee-driven prioritization.
In other words, BAM can materially improve transparency and control at the block-assembly step, but it does not automatically translate into deterministic, application-specific sequencing under all conditions. That is especially applicable for workloads where cancel-before-fill style guarantees are the point.
The Harmonic model
Harmonic approaches the problem from the opposite direction. Rather than hardcoding a venue-specific execution path, it tries to make ordering outcomes healthier by improving the block-building market.
By supporting an open marketplace of competing builders, validators can choose among multiple block proposals instead of relying on a single opaque construction process. That competitive dynamic can reduce some classes of winner-takes-all ordering behavior and can align block construction with validator-defined preferences.
The remaining open question is how consistently those preferences can map to the kind of microstructure guarantees perp traders care about. A market of builders can improve incentives and reduce certain abusive behaviors, but perps still need fine-grained intra-block sequencing semantics and stable behavior under congestion. In that sense, Harmonic is promising as a market-structure upgrade for block building, but it may need complementary mechanisms to translate better block building into predictable perp execution.
These initiatives move the state of the art forward. BAM/ACE by making ordering more accountable and programmable, BULK by showing how much predictability you can get when sequencing is integrated into execution, Harmonic by making block construction more competitive. The gap they collectively illuminate is that perps are unusually sensitive to intra-block sequencing, and shared blockspace plus congestion creates corner cases where influence is not the same as guarantee.
The Bulk model
In parallel, application-layer designs aim to pull more sequencing logic closer to the matching engine itself. BULK is the cleanest example of an execution-first approach. Instead of treating ordering as something to influence from the outside, it restructures the path orders take to reach matching. Incoming orders are fed through a dedicated sidecar that pre-processes orderflow before it hits Solana’s normal transaction pipeline.
BULK’s validator-client integration can produce very low processing latency, and lets the venue impose a strict FIFO discipline with cryptographic sort keys to prevent late reordering within its own pipeline. The trade-off is that determinism is strongest inside BULK’s controlled execution path, while the broader system constraints still exist at the edges.
Participation depends on validators running the client, and end-to-end behavior is still coupled to how Solana schedules compute and handles contention during peak load. So the model demonstrates what is achievable when ordering is treated as part of the execution engine, but it also highlights that application-scoped guarantees tend to be domain-specific and operationally coupled to deployment assumptions.
Toward dedicated perp execution: Parasol
Transaction ordering is a foundational issue for on-chain perpetual markets. Solving it requires coordination between blockchain infrastructure and DEX design. The Solana ecosystem is actively iterating: from Jito’s BAM and ACE giving apps on-chain sequencing tools, to DEXs like BULK building fairer engines, to consensus-layer upgrades like Multi-Leaders on the horizon. Together, these efforts aim to shrink the gap between centralized exchanges and on-chain perps in terms of execution quality.
One emerging idea is to go even further: building specialized execution environments dedicated to dApps, in this case for perps. We envision a hyperliquid-style execution model just for perpetuals. Parasol would allocate dedicated blockspace to a perp DEX, with short, fixed execution cycles and deterministic sequencing rules.
In this model, a perp DEX could enforce strict ordering policies, such as all cancels first without interference from unrelated transactions. We describe it as one that solves ordering problems by giving perp DEXes dedicated blockspace and deterministic sequencing, and by using strict ordering rules to reduce MEV and ambiguity.
Although it’s still early, the approach illustrates the direction developers are thinking. If general-purpose Solana could face challenges in guaranteeing fair perp execution, perhaps a specialized layer can be built.
Final thoughts
Transaction ordering is the hidden force shaping every on-chain perp trade. Solana community recognizes this and is building solutions at every layer: from auction models to validator-side matching and multi-proposer protocols. We are contributing to this evolution by working publicly on Parasol.
By understanding and improving ordering, developers can help on-chain perps approach the consistency and fairness of traditional markets. The journey is ongoing, and these innovations point toward a future where decentralized futures markets are not only fast, but reliably fair and efficient.
