Breadlines Research · v0
Why a Controlled Solana Delivery-Path Study Is Not Yet Runnable
A preregistered comparison stopped before collection because the supposed paths were not equivalent, independently observable study arms.
6 September 2026 · No study transaction was sent · Not a delivery-path performance claim
The short version
A delivery-path comparison only means something when every arm is reachable and can receive functionally equivalent transactions. This proposed four-path study failed that test before it generated a chart.
The proposed question
Do delivery paths differ in finalized landed outcomes for functionally equivalent Breadlines-controlled transactions, under predefined conditions?
It was never intended to measure general path quality, third-party flow, sender geography, dropped traffic, trading execution, or the cause of a difference.
Reachability
Breadlines must be able to submit through a documented public or granted interface.
Equivalence
Each arm must receive the same functional transaction shape and compute settings, except fresh blockhash and inert trial-ID fields.
1. Axiom does not document a public sender surface we could find
Axiom’s public Solana materials describe user-facing priority-fee, bribe, and MEV settings. That is useful product documentation, but it is not an external raw-transaction submission interface for an independent controlled study. Axiom: Solana Fees
Breadlines did not find public documentation for a raw signed-transaction endpoint, developer authentication procedure, rate limit, or developer pricing. This does not claim that Axiom cannot submit transactions. It means Breadlines cannot treat Axiom as an independently callable study arm without an Axiom-provided integration surface.
2. Nozomi changes transaction shape unless every arm carries its tip
Nozomi publishes an API-keyed sendTransaction surface with auto-routed and regional endpoints. It only handles submission, requiring a separate RPC for blockhashes and final receipt observation. Nozomi: Transaction Submission
Its documentation requires a System Program transfer to a Nozomi tip address, with a minimum tip of 0.001 SOL. A Nozomi-only tip changes the instruction list, writable accounts, balance requirement, and economics; it cannot be silently called a path-only treatment. Nozomi: Tipping & FAQ
A later two-arm study could include the same required tip in both Nozomi and Direct-TPU transactions. That would be a different, explicitly tipped mechanism study—not a benchmark of normal transactions.
3. RPC and Direct TPU are not clean non-BAM controls on a BAM-connected leader
Direct TPU is client-managed leader submission and forwarding, not a hosted vendor endpoint. It needs a controlled client, leader discovery, outbound QUIC, a receipt RPC, and a declared rebroadcast policy. Solana: Retrying Transactions
“RPC flow: If your validator is connected to BAM and scheduled to be a leader soon, transactions submitted via RPC are routed through BAM.”
“Direct TPU flow: Transactions sent directly to your TPU port are processed through BAM before execution.”— BAM Documentation
On a BAM-connected leader, neither generic RPC nor Direct TPU is a reliable non-BAM control. The client’s ingress choice cannot establish that the trial bypassed BAM.
4. BAM documents an enrolled Maker Priority Plugin, not a general research sender
The Maker Priority Plugin is a documented priority ingress path for enrolled market makers. Its Plugin TPU accepts raw wire-format Solana transactions as UDP datagrams on default port 5012, subject to operator confirmation. Its canonical structure requires an enrolled signer, Compute Budget instructions, an enrolled market-update program, a writable enrolled market account, and an 8-byte sequence number. BAM Maker Plugin: Getting Started
Enrollment is configured by the node operator before startup: signer public keys, programs, markets, sequence-number offsets, and fee floors are static. BAM says there is no runtime registration API. BAM Maker Plugin: How It Works
Breadlines is not an enrolled market maker with an enrolled market-update program and market account. Its harmless study transfer would not satisfy the documented plugin validation rules. That—not a lack of documentation—is why the Maker Priority Plugin cannot currently be a study arm.
The difference is structural: Phase 1 drains enrolled maker-plugin traffic before bundles and regular transactions, and BAM says higher fees or tips cannot change that ordering. The meaningful open question is whether enrollment is strictly market-maker scoped or whether a deliberately bounded research-sender path exists.
What this establishes—and what it does not
Established
- Nozomi has an API-keyed sender and a minimum-tip rule.
- BAM documents a statically enrolled Maker Priority Plugin with strict validation rules.
- BAM documents both RPC and Direct-TPU routing through a connected BAM leader.
- Direct TPU is client-managed leader submission.
Not established
- Relative quality, latency, reliability, privacy, or cost-effectiveness of any path.
- Why a particular transaction would land or fail elsewhere.
- Provider responsibility for a final outcome.
- Third-party flow, sender geography, dropped traffic, or leader-arrival timing.
No study transaction was sent. There are no performance results to interpret.
What would make a later study possible
- A documented equivalent interface that accepts the same signed transaction shape in every included arm; or
- A separately preregistered two-arm mechanism study, such as Nozomi versus self-operated Direct TPU with the same mandatory Nozomi tip in both arms.
For BAM, that means an enrollment that genuinely fits the study or a documented research-sender path, plus a way to join scheduler evidence to a final ledger receipt. For Axiom, it means a documented external submission interface if it is to be independently measured.
Why stopping here is useful
The easy failure mode is to send through whatever happens to be available and call the columns “paths.” That would hide product-internal routing, a mandatory tip instruction, and a scheduler already processing a supposed control flow.
Access documentation and transaction equivalence are part of execution methodology—not administrative details to fix after results arrive.