Neutral Infrastructure Series, Part 1: the neutrality standard

This is part 1 of our neutral infrastructure series directed towards searchers and traders.

Part 2 walks through the transaction lifecycle and shows exactly where your trades are exposed. Part 3 is a checklist of questions to put to any provider. Part 4 is for everyone who trades through an app or platform rather than their own endpoint. We'll add links as they're published.

TL;DR

• Every transaction you send passes through your infrastructure provider before the rest of the network sees it, which makes your provider the single most privileged observer of your trading
• In traditional securities markets, a broker-dealer trading ahead of a client's order is  front-running, and regulators prohibit it; in crypto infrastructure, there’s no purpose-built equivalent, so your provider's own policies do most of the work
• We're proposing a simple neutrality standard: no trading on customer order flow, no information advantage over the network, and consent that's explicit rather than buried in terms of service
• Triton One commits to that standard, and we think you should hold every provider you use to it

Your provider sees your trade first

When you submit a transaction on Solana, it goes to one company before it goes anywhere else. Your RPC provider receives it, routes it, and in many cases, watches it pass through their own validator before a single shred reaches the rest of the cluster.

That's an enormous amount of trust to place in a vendor, and most traders never think about it. You benchmark providers on latency and uptime. You rarely ask the question that matters more than either: what is my provider allowed to do with what they see?

And if you trade through a trading app rather than holding an endpoint yourself, the same relationship exists; you just aren’t the one who signed up for it.

In traditional finance, this question was settled decades ago. A broker who trades ahead of a client's order is front-running, and regulators treat it as a serious offence. The logic here is instructive: A broker holds a privileged position precisely because once a client places an order, the broker holds confidential information it received as the client’s agent. The law therefore bars the broker from using that information to trade for its own account ahead of the client.

Solana has no such rule. Your infrastructure provider stands in the same position as the broker, receiving users’ transactions before anyone else sees them, yet its commitments to those users are defined largely by terms of service it writes itself. 

The conflict is structural

The incentive misalignment gets bigger as providers vertically integrate. A provider that only serves data has little to gain from your order flow. But a provider that also trades? They’re your competitor, and the fight isn’t fair anymore.

Consider what a vertically integrated provider running its own validators can have at any given moment: 

1. your unconfirmed transactions, 
2. a real-time view of market state, 
3. a leader slot coming up in which they control ordering, 
4. and their own transactions in the order flow. 

Each of those is a legitimate business on its own. Combined, they form a machine that could, if its operator chose, extract value from the very customers feeding it.

The point is that whether it happens is practically constrained largely by policy, and some providers have published policies that explicitly reserve the right to pursue MEV on transactions that pass through their infrastructure. Even if those policies prohibit sandwiching and front-running customer transactions, they still permit other strategies, such as backrunning, on customer flow.

If you route transactions through a provider that also trades, its disclosures and internal controls are the main things standing between your order flow and its trading desk. You should read them the way you'd read a broker agreement.

What neutrality actually means

Neutral infrastructure is easy to say and hard to pin down, so here's our definition. A neutral provider satisfies three conditions.

No trading on customer order flow

The provider never uses a customer's unprocessed transactions as a trading signal, never lets an affiliated trading operation see customer flow before delivering to the leader, and never treats an app's opt-in as cover for exposing its users. 

That last one matters because the consent chain is broken by design: the app holding the RPC key is the one ticking the box, while the trader actually signing the transactions may have no idea their order flow is being shared before it hits the network. 

No information advantage

Anything the provider acts on, you can access too, on published terms and with no privileged delay. That's the bright line. 

The earliest observable point in a transaction's life is the moment the leader's scheduler commits to executing it, and from that moment, the data is a product anyone can buy, from us or from other major providers. 

A provider that holds itself to this standard can build fast products because it never holds a view of your transactions that you were denied. What it can never do is act on the one window where access is impossible to buy: the gap between your submission and the scheduler's commit, when your provider is the only party on earth who knows your intent.

Consent that's explicit, not buried

If a provider wants to do anything with your order flow beyond routing it, they should ask you directly and wait for an answer. It should be opt-in, written in plain language, and easy to revoke. In our view, a disclosure that activates the moment you accept a terms of service document isn’t meaningful consent.

Where Triton stands

• We built Triton to be boring in exactly this way. The data products we're proudest of, including Dragon’s Mouth and Yellowstone Geyser, stream data as the network itself receives it, with no deliberate delay, and we’ve made them open source. We also built Yellowstone Jet and Shield, which allow you to deliver transactions directly to the leader’s TPUs, and select which validators are allowed to receive your transactions - both open source so you don’t have to rely on any provider. Not even us.
• We consider the time that the scheduler commits to executing your transaction inside the leader as network parity. It’s the first moment when the playing field is level, because every trader can buy preconfs or shreds through any of the major RPC providers. Everything from this point onwards is a fair race.
• We never trade on information that we see before the scheduler commits to executing your transaction. After that point, preconfs and shreds are available for purchase and action by anyone.
• We also commit to the consent principle. Before we offer a product or service that uses private customer order flow in any new way, and to decide at that point if you want to continue using our infrastructure, we will tell you in plain language and will not include your transactions unless you affirmatively opt in.
• We're publishing this standard because we want to be held to it, and because we think the ecosystem is better when traders demand it from everyone, us included.

Hold your provider to the same bar

In part 2 of this series, we'll walk through the Solana transaction lifecycle, stage by stage, and show you exactly where your trade is visible, to whom, and what the published provider policies permit at each stage. In part 3, we'll give you a checklist of questions to put to any provider, with notes on what good answers look like.

Until then, one piece of homework: go and read your current provider's terms of service and any MEV or order flow disclosures they publish. If you can't find a disclosure, that's an answer too.

FAQ

Is MEV itself the problem?

Not always. MEV is a property of how blockchains order transactions, and plenty of MEV activity, like post-trade arbitrage on public data, is just markets working. The problem is narrower: an infrastructure provider using its privileged view of customer transactions, before the network has them, as a trading input.

Does neutrality mean a provider can't run a validator?

No. Running a validator is healthy for the network. Neutrality is about what the operator does with the privileged position, not whether they hold it. A validator operator can commit to acting only on data that’s also accessible to you.

How would I ever verify a provider's claims?

Imperfectly, which is why disclosures, open-source code, and consistent public commitments matter. A provider that publishes a standard is giving you something to hold against them later. Part 3 of this series covers verification in more depth.

Can't I bypass RPC providers entirely and send them straight to the leader?

Yes. Yellowstone Jet, our open-source transaction sender, implements Solana's QUIC protocol so that your own infrastructure can 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 are allowed to receive your transactions at all. 

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.