Breadlines Research · v0.1
Execution Evidence Boundaries on Solana
What a final ledger receipt can establish, what requires delivery or sequencing telemetry, and where an honest explanation must stop.
2 September 2026 · Public discussion draft · Updated with a worked receipt and open technical questions
The short version
Delivery, ordering, final ledger inclusion, and program execution are different layers. A useful receipt should say which layer its conclusion comes from instead of turning an inference into a fact.
Four distinct execution questions
Final execution
A finalized ledger transaction can establish landed success or failure, fees, compute consumed, and sometimes the failing program frame.
Delivery
Opt-in client or provider events can establish attempted submission, acknowledgement, and retry history.
Ordering
Sequencer-specific attestations can establish claims within the system that issued them—not a universal ordering story.
Application rejection
Logs, invocation frames, documented errors, and relevant state evidence can sometimes establish a deterministic failure class.
What the ledger does not establish alone
A final receipt does not, by itself, establish when a transaction was first submitted, which provider path carried it, whether it was dropped before landing, its arrival order at a leader, or whether nearby activity caused its outcome.
Those unknowns are not a defect in the ledger. They are a boundary. The problem begins when a product silently crosses it and presents a confident causal story.
Worked receipt
A real failed transaction, without an invented story
This public transaction is deliberately an example of restraint. It demonstrates that full same-slot context can add direct observations, while still not proving why the transaction failed or who caused it.
Chain-proven
Signature 11AFoW5L6v7v…SAeueRSP landed in slot 438,137,374 and failed. Its final logs identify program NA247…pnHTUV returning custom error 60 (0x3c). The receipt records an 8,234-lamport fee and 93,689 compute units consumed.
Directly observed
A declared target-slot-only context was acquired from a full public getBlock response: 1,247 transactions including the target. Of the 1,246 other records, 40 shared at least one writable account with it. Nine public signer addresses recurred among those overlapping records.
Unknown — and intentionally left unknown
The available logs do not decode what custom error 60 means. The evidence does not establish original submission time, provider path, leader arrival order, identity, a state change, or that any overlapping transaction caused the failure. It also does not establish that another fee, route, provider, or scheduler would have changed the result.
Adjacent infrastructure, different evidence
Breadlines is not trying to replace the teams improving execution. Their work makes clearer evidence possible; the complementary question is how an application presents that evidence honestly after the attempt.
Anza / Solana core
Anza works on protocol performance, scheduling, runtime, validator software, and fair market-structure proposals. Breadlines’ complementary question is methodological: which landed-ledger observations are stable enough to discuss around a protocol change, and which remain confounded by workload or unavailable sender-side evidence?
Jito / BAM
Jito describes BAM as transparent and verifiable sequencing, including signed attestations that ordering followed its rules. Breadlines’ complementary question is how an application receipt can expose final execution and available sequencing evidence without extrapolating beyond the system that produced it.
Raiku
Raiku describes Ahead-of-Time reservations, Just-in-Time execution, and signed pre-confirmations as a deterministic-inclusion layer. Those source-specific reservation and pre-confirmation records sit directly on the boundary Breadlines cares about: they can support a stronger receipt only when they are attached to the final ledger outcome and clearly labelled as Raiku evidence.
A generic Solana ledger transaction alone does not establish that Raiku reserved, scheduled, or guaranteed it. Breadlines should preserve that distinction rather than infer Raiku participation from a final signature.
Triton / Cascade
Triton describes Cascade as a SWQoS-backed delivery network and publishes client-side guidance on retries, compute budgets, and priority fees. Breadlines’ complementary question is how an opt-in trace can join attempts and retries to the final ledger receipt without calling a delivery path the cause of a later program failure.
Helius / Sender
Helius describes Sender as low-latency submission through validator and Jito infrastructure. Breadlines’ complementary question is what minimal opt-in event model can connect an attempted submission, acknowledgement, retries, and final ledger receipt without storing keys or asserting that an unobserved transaction was dropped.
Read Sender API documentation · Read transaction-sending overview
The ask
Five technical questions for the ecosystem
These are questions, not claims that any provider lacks a feature. Public corrections, documentation, and counterexamples are useful.
- What receipt or attestation fields can a provider expose so an application can correlate a submission attempt with a final ledger signature?
- Which provider states are final, which are provisional, and what are their documented retention and uniqueness guarantees?
- What event schema would let an application preserve retries and expiry without retaining raw signed transactions or private keys?
- Which ordering evidence is system-specific, and how should applications prevent it from being misread as a global Solana ordering claim?
- What is the minimum public evidence required before describing a failed transaction as a delivery issue, a sequencing issue, or an application-program rejection?
The Breadlines standard
- Chain-proven: finalized landed state, fees, compute, raw errors, and failing frames where recoverable.
- Directly observed: declared context samples and other disclosed evidence.
- Supported inference: explicitly labeled and used only where the methodology supports it.
- Unknown: facts requiring missing telemetry, including ingress, unlanded attempts, arrival order, identity, and causal counterfactuals.
What Breadlines is not proposing
- A transaction router, sequencer, scheduler, custody system, or landing guarantee.
- Sender geography, identity, human/bot labels, or dropped-traffic claims derived from block data.
- Automatic blame of an integrator or execution provider when a downstream program fails.
- A token ranking, prediction model, or trading recommendation.