Neutral Infrastructure Series, Part 2: the lifecycle of your trade, from signature to shred

This is Part 2 of our Neutral Infrastructure Series. Part 1 set out the neutrality standard. Part 3 is the checklist to put to your provider.

TL;DR

• Between signing and confirmation, your transaction passes through a short chain of privileged positions: your provider at submission, the leader’s TPU, the scheduler, and finally the shreds that carry it to the rest of the network.
• Your exposure is concentrated in the first two stages, when your provider and the leader hold your transaction before the market knows it exists.
• The scheduler’s commit is what we call network parity: the first moment anyone can buy access to your transaction, and everything after it is a fair race won on engineering.
• You can send your transactions directly to the leader or block and take your RPC provider out of the picture.

The lifecycle of your trade, from signature to shred

Most traders picture transaction submission as a broadcast: you send, the network hears. In reality, it passes through a chain of privileged positions, and you can't reason about your exposure without knowing who holds your transaction at each point. Whoever holds your unconfirmed transaction knows what you’re about to do before the market does, and could, at its choosing, trade on that knowledge by inserting a similar trade ahead of yours, positioning for the price move yours will cause, or selling the preview to someone who will. Each of those would cost you by letting someone else capture value your trade created before it’s even landed. Part 1 of this series sets out the standard we think addresses these risks.

Here's the path a typical transaction takes, and what's visible at each stage.

Stage 1: submission. Your RPC provider sees everything

You sign a transaction and submit it to an RPC endpoint or a transaction-sending service. At this instant, apart from the wallet or app you signed with, only one company in the world knows your intent: your provider. The transaction hasn't touched the leader, hasn't been scheduled, and doesn't exist as far as the market is concerned. Anything you want to buy/sell/list/launch is visible to your provider. A provider willing to act on that view could place a similar trade ahead of yours, moving the price against you so you receive less than you expected, or even take a loss.

This is the stage with the purest information asymmetry. A provider at this stage knows what you're about to do before anyone else can. Sending services that route your transaction across multiple pathways widen the circle, and each added pathway operator is another privileged observer.

Stage 2: the leader's TPU. Ordering power enters the picture

Your transaction arrives at the current leader’s transaction processing unit (TPU). The leader decides inclusion and ordering for its slot, unless it has handed block building to an external builder (more on that below), and on Solana that control is substantial, which makes a leader’s own slots the most efficient place to act on any signal the leader holds.

To be precise about what is and isn’t the concern here: how leaders order and pack their blocks is its own debate. Custom scheduling and bundle markets exist across the network, reasonable people disagree about them, and this series takes no position on block packing. The problem we’re describing is narrower, and it appears when you connect stages 1 and 2. 

If your provider also builds the blocks for its validator, then for its leader slots, the company ordering the block is the same company that saw your transaction before anyone else. 

Ordering power is normal. A private preview of your intent is not. Together, that combination can turn a leader slot into a window that can be used against you. Your provider’s MEV or order flow disclosures should tell you whether it builds blocks for its own validators and what it permits itself to do in that position. Part 3 (which we will post later) gives you the specific questions to ask. 

Most validators use external block builders to improve block rewards & capture tips. A well-designed external block builder can also reduce the conflict described above, because the company that saw your transaction first is no longer the one deciding its order. It does not erase what that company already knows; a provider that saw your transaction at submission still holds that information, whoever builds the block. Triton’s validators currently use two block engines: Jito’s and Harmonic’s. Based on their published documentation, here is how each works.

Jito is the first widely adopted Solana MEV solution and is migrating to its latest offering called BAM (Block Assembly Marketplace), which runs in a TEE (Trusted Execution Environment). According to Jito, BAM leaders determine ordering inside the TEE, and the leader must produce the block as ordered, without modification. If it works as designed, a provider that also operates the validator gains no ordering edge, because it does not control block building. Jito retired its transaction mempool in March 2024 and does not currently offer MEV order flow auctions from TPU ingestion.

Harmonic is a new competitor to BAM and operates similarly, using an external block builder machine (not a TEE). Like BAM, once your provider delivers your transaction to the leader’s TPU, the provider no longer influences its ordering. Also, like BAM, and according to Harmonic, a validator operator has no visibility into the block-building process and cannot influence auction outcomes, including when the provider is also the validator operator. 

Harmonic also offers validators a private Order Flow Auction (OFA) service on transactions sent to them. The OFA allows vetted third-party searchers to compete for arb opportunities and pay extra priority fees and tips to the validator. The auction process is hidden from the RPC provider and validator operator, so they can’t influence the outcome. That means your transactions can be offered to searchers through an auction when sent to a Harmonic leader. 

Both Jito and Harmonic allow vetted searchers and traders to submit transaction bundles directly to their block engines. If you know your target leader runs BAM or Harmonic, you can skip the RPC provider altogether and send bundles directly to the block engine, which then becomes the party you are trusting with your transaction. See Jito’s and Harmonic’s websites for more details.

Stage 3: scheduling. The earliest sellable signal

Inside the leader, the scheduler commits to executing your transaction before any block data leaves the machine. This scheduled-but-not-yet-propagated state is the earliest moment a pending transaction can be observed by anyone outside the parties discussed above, and it has recently become a product category: pre-confirmation streams that deliver scheduled transactions to subscribers before shreds exist. Triton sells one, as do other major providers.

This is what we call network parity: the first moment the playing field is level, because any participant can buy the same data, on published terms, from multiple  providers.

From here, it's a fair race. Shred streaming, fast gRPC delivery, low-latency propagation: everyone starts from the same data here, so the race is won on engineering. That is why part 1 drew the neutrality line exactly here.

Stage 4: shreds. The network finally gets a copy

The leader packs executed transactions into entries, slices them into shreds, and transmits them to the rest of the cluster. The information is public; anyone running a node, or subscribing to a shred stream, can see it. Anyone trading on data from this stage onwards is simply trading.

What this means for you

We see four practical conclusions:

First, your exposure is concentrated at stages 1 and 2. Nothing in Solana prevents a provider from acting on what it sees before preconfs are available; only the provider's own commitments do.

Second, a provider’s terms of service and disclosures are the only commitments you have on this, so read them. A provider with no MEV or order flow disclosure hasn't promised you anything at all.

Third, the most useful question you can put to any provider is whether they act on anything before the network has it. A provider committed to network parity can be as fast as physics allows without ever holding an edge over its own customers. That's the standard we set out in part 1, and it's the standard we hold ourselves to: Triton never trades on information it sees before the scheduler commits to executing your transaction, and the data we deliver is available to you at the same moment it is available to anyone else.

Finally, you can skip the provider altogether by sending transactions directly to the leader or block builder. See the FAQ below for how.

In part 3, we turn this into a working checklist: the questions to send your provider, and what good and bad answers look like.

FAQ

Isn't all of this just MEV, which happens everywhere?

MEV on public data is a market dynamic. The concern in this piece is narrower and older than crypto: an intermediary using a privileged, pre-public view of client orders. In securities markets, regulators generally prohibit it. On Solana, it's a matter of each provider's policy.

If a provider discloses it, is it fine?

Disclosure is better than silence, and consent is better than disclosure. But consent granted by accepting a terms of service document is thin. Part 1 of this series argues that anything touching customer order flow should be an explicit opt-in.

Can't I just avoid a provider's validator?

Sometimes, partially. You can try to target other validators, but routing on Solana isn't fully under your control, and providers say as much in their own disclosures.

If you want enforcement rather than an attempt, Yellowstone Shield lets you define on-chain policies that control exactly which validators may or may not receive your transactions; Shield-aware infrastructure will not forward your transactions to a validator you’ve excluded or, if you use an allowlist, to any validator you haven’t included. 

That still leaves the submission stage, where your provider sees everything first, which is why the cleaner fix remains choosing infrastructure whose operator has committed not to exploit the position (see the next question).

Can I skip the RPC provider entirely?

Yes. Yellowstone Jet, our open-source transaction sender, implements Solana's QUIC protocol, enabling your infrastructure to deliver transactions directly to leaders' TPUs. Run it yourself, and no provider ever sees your transaction before the leader does. 

Jet supports stake-weighted connections for reliable landing under congestion, and Yellowstone Shield policies let you control which validators can receive your transactions. The leader still sees your transaction; nothing removes that, but the privileged window this post worries about disappears. It's licensed under Apache 2.0 and free to self-host; we'd rather you run it than have to trust any provider, including us.

* A note on the future:

Some validators Triton operates are run on behalf of third-party clients who control their own block-building settings. Triton will not opt in its own validators without public disclosure.

When working with external block builders, Triton hasn't acted on the order flow, participated in the auction, or influenced the outcome. We remain a neutral party. Likewise, Triton doesn't receive kickbacks, profit sharing, or any out-of-band payments from the auctions.