Breadlines X-Ray now separates three questions explorers usually collapse into one:
WHAT HAPPENED
→ execution
WHAT THE NETWORK ESTABLISHED
→ consensus
WHAT THIS OBSERVER KNEW + WHEN
→ provenance
Tested it on a real failed Solana transaction.
The SVM says LANDED_FAILED.
That tells us what execution did.
It does not, by itself, prove what happened to the containing block, when an observer first saw it, or independently prove finality.
Those are different claims. So Breadlines now stores them as different evidence surfaces.
This matters even more with alpenglow: execution stays execution while the shape of consensus evidence changes.
Same transaction.
Different claims.
Different evidence.
Breadlines is ready for ugly transactions.
Failed. Confusing. Behaved differently than you expected. The ones that made you open Solscan, logs, RPC responses and still ask:
“what the hell happened here?”
Send us the signature + what you were trying to understand.
We’ll return:
→ what executed
→ where it failed
→ what committed
→ what never ran
→ what the evidence can actually prove
→ what still can’t be known
No causality fanfic.
When the evidence stops, the explanation stops.
https://t.co/Ig3jRpacxE
Solana Transaction v1 gives you 4,096 bytes.
We tried spending them on post-quantum authorization.
ML-DSA-44: 2,928 bytes ✅
ML-DSA-65: 3,817 bytes ✅
SLH-DSA-128s: 8,364 bytes ❌
Smallest tested 2-signature construction: 6,252 bytes ❌
So larger transactions unlock individual PQ authorization payloads.
They do not automatically unlock inline PQ multisig.
And we haven’t even reached the compute question yet.
New envelope. New bottleneck.
The biggest pqc blocker was just unblocked.
Create a @multisig smart wallet with 3 pqc signers each using a different signing scheme. Rotate the schemes out as the implementations mature.
Breadlines is officially building in the Crypto World’s Fair.
The mission stays simple:
Make Solana execution legible.
We’re pushing X-Ray beyond receipts into pre-inclusion evidence, source-aware preconfirmations and execution case files that separate what happened from what we only think happened.
Four weeks. Build in public.
↓
https://t.co/KEVrFOX2DE
@alessandrod Does the white space here mean replay-thread idle time, or genuinely schedulable headroom?
We would want to split executed CU, write-lock contention and work that never reached replay before calling it spare capacity. Feels measurable slot-by-slot.
@senyor_kodama Curious whether the 7.4 ms/1000 km survives when the endpoint is first executed user tx rather than first shred receipt.
If not, it’s propagation; if it does, it starts looking like execution-window loss. That split would be useful
@raikucom Land vs finalize still hides too much.
For us the useful ladder is delivered → scheduled → executed → committed.
When Raiku says “execution certainty,” which boundary are you actually guaranteeing under load?
A preconfirmation isn’t an early receipt.
The useful difference is that it can be an attributable statement made before execution one you can later reconcile against the ledger.
We built a Breadlines evidence model around that distinction:
provider-observed ≠ validator-attested ≠ chain-proven.
And if a preconfirmed tx has no matching receipt, the answer is unresolved not automatically “broken promise.”
Now we want to test this against real BAM semantics.
If execution can move this far ahead of user intent, what evidence should the signer actually receive?
Not just ‘simulation passed’, what proves the state, route and execution assumptions they reviewed are still the ones they’re signing?
9 years at solana. I do not say this lightly.
We are extremely close to a transaction finalizing before you decide to sign it.
We are not asking for a ban. We are asking for a pause.
@anza_xyz Receipt side: pulled a devnet V1 tx. Budget sits in
message.transactionConfig, no per-CU price field, just priorityFee
so our limit × price derivation does not carry over.
We fail closed on V1 rather than inherit a no-op ix.
Is priorityFee lamports or a rate?
@anza_xyz Receipt side: V1 we will read budget from the tx config, not ComputeBudget ixs.
If a node still serves a V1 sig without those fields, we label source unknown instead of inheriting the ix.
Testing that on devnet before the 15th.
What changed:
-reach and commitment are now separate.
-failed-tx frames show returned success · rolled back.
-per-root commitment stays unknown unless actually decoded
lateness / partial-commitment claims are blocked.
-UI + bot both have regression tests
Markets diff: https://t.co/dr6iBBgHbf…0196d28
Bot diff: https://t.co/MGJyeQUDxX…3663d45
Toly corrected how I was thinking about atomic execution across roots.
Took it back into Breadlines and found a real modelling issue:
execution reach ≠ state commitment.
Fixed the model, UI labels and bot claim guards. Added adversarial tests too.
implementation below
Firedancer documents signature linked scheduler arrival, execution timing and block inclusion.
Useful groundwork for richer execution receipts.
We’re exploring an offline mapping into Breadlines not announcing an integration.
https://t.co/LFVzSrI9JU
Breadlines today
Looking into Breadlines again today, and I honestly think this one deserves more attention.
What started from an idea @toly had been talking about around markets and “breadlines” has turned into something Dola is actually putting serious work behind.
The part that stands out to me is that @Dola_porr has not stopped building.
Updates have been coming back to back. Research is being published. New experiments are being pushed. The work continues even when the chart isn’t giving the project much attention.
And this isn’t just a dev throwing together random updates to keep a narrative alive.
He’s digging into what actually happens on Solana what lands, what fails, what it costs, what the chain can prove, and where the data has limitations.
He’s also been getting feedback from people actually building in the Solana ecosystem and using that to take the research further.
Three research notes in a week, a public repo as an audit trail, and now the receipt itself being built.
The goal is pretty interesting:
Give it a transaction signature → see what the chain can actually prove, what’s only correlation, and what can’t be known without provider-level telemetry.
That’s why I’m still paying attention to Breadlines.
The market might be focused on whatever tech coin is running today, but there are projects quietly doing the work before the attention arrives.
Breadlines feels like one of those.
And with tech starting to get attention again, I don’t think it’s crazy to ask:
did we forget about one of the more interesting tech experiments being built around Solana?
I think $Breadlines deserves another look.
Breadlines biggest limitation rn isn’t features. it’s visibility.
onchain data tells us what landed, but not the full execution journey before inclusion.
closing that gap is what we are working on now.
less guessing. better execution evidence.
We preregistered a controlled Solana delivery-path study, then stopped it before sending anything.
The access check found three blockers: no documented public Axiom sender surface we could find,
a mandatory Nozomi tip that changes transaction shape, and on a BAM-connected leader both RPC and
direct-TPU flow routing through BAM, so there’s no clean non-BAM control.
Solana’s execution stack is five different questions runtime, delivery, ordering, deterministic inclusion, app logic.
“Why did my transaction fail?” collapses all five into one answer, usually a confident one.