This is part 3 of our neutral infrastructure series. Part 1 defined the neutrality standard. Part 2 mapped where your transactions are exposed.
TL;DR
- You can benchmark a provider's latency, but the only way to learn what they do with your order flow is to ask them (or go full sleuth mode and try to find evidence of your provider trading your order flow afterwards)
- These seven questions cover all of it: validator operations, order flow handling, data products, consent, and verifiability
- For each one, we've included what a good answer looks like and the red flags to listen for
- Send them to your current provider; the answers, and the non-answers, will tell you a lot
Why a checklist
Benchmarking tools will tell you which provider lands your transactions fastest. Nothing will tell you what a provider does with its view of your transactions except the provider, and they'll only tell you if you ask precisely.
These questions are designed to be sent as written. Written answers create a record, and providers choose their words carefully when they know the answer might be quoted back to them. If a sales engineer answers verbally but won't confirm in writing, that tells you something too.
The seven questions:
1. Do your terms of service or disclosures permit you to extract MEV on transactions I submit through your services?
The honest answers are "no" and ideally “no, and we’re happy to put that in writing” or "yes, here's the disclosure." Both are useful.
Red flag: being pointed at a terms of service document and told to read it yourself. If the permission exists, the provider knows where it is.
2. Does any affiliated entity, desk, or partner trade using data from order flow on your infrastructure?
Vertical integration doesn't stop at validators. Trading arms, partnered market makers, and revenue-sharing arrangements with searchers all create paths for your order flow to become someone's signal.
Good answer: a clean no, or a yes accompanied by a precise description of what data the affiliated party receives and when, relative to network propagation.
3. If I opt out of any order flow program, what exactly changes in how my transactions are handled?
Opt-outs are only meaningful if they change the data path. Ask for the mechanical difference: different routing, different filters, different infrastructure, or just a flag in a database.
4. What happens to my transactions during your own leader slots?
Part 2 showed why this is the highest-leverage window. A good answer describes ordering policy plainly: for example, standard client scheduling with no custom reordering and no internal visibility ahead of execution.
Red flag: any answer that distinguishes between how customer transactions and other transactions are treated during the provider's slots, in either direction. Special treatment cuts both ways.
5. Is consent to any of the above granted through your terms of service, or through explicit opt-in?
By this point, you'll know what the provider does. This question establishes how you agreed to it. Consent buried in a terms of service document you accepted at signup generally holds up legally, but you never saw it and never weighed it.
Good answer: anything touching order flow is separate, explicit, opt-in, and revocable.
6. How much of your stack is open source and independently verifiable?
You can't audit a provider's intentions, but you can audit code. open source sending/routing/streaming infrastructure, published plugins, and reproducible benchmarks shrink the space where a provider could do something other than what they claim. With a closed stack, you're taking the provider's word for all of it.
7. Will you put your answers to questions 1 through 6 in writing?
This is the cheapest commitment test available. A provider confident in its answers has no reason to refuse, and a written record means today's policy can't be revised next quarter without anyone noticing. Published disclosures that commit to advance notice of changes are worth something here; ask whether yours does.
Scoring the answers
No provider will score perfectly on a purity test, and that's fine. Validators, data products, and even MEV participation on public data can all coexist with neutrality toward customers. What you're looking for is a provider that can answer every question directly, draws the line at network parity, treats consent as something you actively give, and is willing to be held to it in writing.
For the record, here's how we'd answer. Triton doesn't trade on customer order flow, delivers data at or after preconfs, and builds in the open: the Yellowstone suite that powers our streaming, from Dragon's Mouth to Fumarole, is open source and inspectable. Ask us these questions, and we'll answer in writing.
Your infrastructure provider should never hold a position against you. Send the questions and see what comes back.
Talk to SupportFAQ
My provider answered some questions well and dodged others. Now what?
Weigh the dodges by stage. Evasiveness on questions about whether the provider takes action based on your transactions matters far more than vagueness about open source percentages.
Is it rude to send this to a provider I've worked with for years?
A good provider will welcome it, because clear standards reward the providers already meeting them. The ones who find the questions uncomfortable are the reason to ask.
Can I verify any of this independently?
Partially. Validator stake is public, disclosures are published, and open source code is inspectable. The rest relies on written commitments, which is exactly why question 7 exists.
Triton's answers
1. Do your terms of service or disclosures permit you to extract MEV on transactions I submit through your services?
No
2. Does any affiliated entity, desk, or partner trade using data from order flow on your infrastructure?
No
3. If I opt out of any order flow program, what exactly changes in how my transactions are handled?
You can opt out of any order flow program by using Yellowstone Jet, our open source transaction sender, to allow your infrastructure to deliver transactions directly to the leader’s TPU.
4. What happens to my transactions during your own leader slots?
We use two external block builders: Jito’s and Harmonic’s, to reduce any conflicts of interest. No custom reordering, no internal visibility, no influence over the outcome.
5. Is consent to any of the above granted through your terms of service, or through explicit opt-in?
We commit to the consent principle. Before we offer a product or service that uses private customer order flow, 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.
6. How much of your stack is open source and independently verifiable?
The vast majority of our stack is open source. In fact, our GitHub is named “rpcpool” because when we started building, we were building what now underpins all of Solana: products like Yellowstone gRPC (Dragon’s Mouth), Yellowstone Shield, and Old Faithful.You can find our team’s work on https://github.com/rpcpool and https://github.com/solana-rpc
7. Will you put your answers to questions 1 through 6 in writing?
Done!