If you are running v2.8.0, update now
Do not trade on that build. Get the current release and unzip it over the same folder — your wallet, journal and existing chain survive. The v2.8.0 zip is deliberately not linked anywhere on this site.
The attestation chain is the reason a PaperTrench leaderboard record means anything. Every fill is committed to a SHA-256 hash chain the moment it happens, before the outcome is known, so trades cannot be inserted, deleted or backdated after the fact.
A chain that silently stops recording is therefore worse than no chain at all. It leaves you believing you have a verifiable record while you are quietly accumulating a hole in it.
What went wrong
The attestation chain was being migrated to a new segmented store. v2.8.0 was cut while that migration was in flight, and it shipped with the two halves out of step: fills asked for the new segmented chain store, and the new store was not aboard.
So every paper fill on v2.8.0 tried to append to a chain writer that did not exist, and failed.
It failed loudly. The honest "could not be added to the verification chain" toast fired on every single fill — the failure was visible on screen, every time, not swallowed.
That toast exists because of an earlier rule: no silent death, ever. This is the release where that rule earned its keep. A user on v2.8.0 was told, at the moment of each fill, that the chain had not recorded it.
What it did and did not affect
Your wallet, balances, positions, rounds, journal and P&L. All of it recorded normally. No data was lost and nothing was corrupted.
The attestation chain only. Fills made during the v2.8.0 window are absent from it — they exist in your history, but carry no chain commitment.
The practical consequence is narrow but real: those fills cannot be proven to have been recorded before their outcome was known. For ordinary practice that changes nothing. For a leaderboard submission, it is a gap.
What the verify panel says about it
The gap is shown. It is not smoothed over, back-filled, or re-derived.
It would be technically easy to walk your fill history after the fact and manufacture chain entries for the missing window. It would also destroy the entire point: a chain entry written after the outcome is known proves nothing, and a verifier cannot tell a helpfully back-filled entry from a dishonest one.
So on v2.8.1 the chain records again from that moment forward, and the verify panel honestly shows the gap rather than pretending it is not there. A record that admits a hole is worth more than one that quietly papers over it.
The rebuild itself (F-14)
The migration that caused the mess was worth doing, and it landed whole in v2.8.1. The chain moved out of the wallet state and into a single-writer segmented store.
A fill now rewrites one small tail segment instead of the whole history.
Four things fall out of that:
- Multi-tab chain races are gone. One writer, by construction — not by hoping two tabs never write at once.
- No hash is ever truncated. The old shape had a size ceiling that could clip history; heavy traders hit exactly this class of problem back in v1.2.8.
- Backups are downgrade-safe. A backup taken on the new build restores intact on a pre-segmentation build. Upgrading should never strand your own data on the far side of a version bump.
- Resets clear the chain atomically with the wallet — no state where you have a fresh wallet and a stale chain.
And the part that matters to anyone who has already submitted a record: the leaderboard verifier format is unchanged. This was an internal storage change, not a protocol change.
Why write this up at all
Nobody would have noticed if this page did not exist. The bug is invisible unless you read your own toasts carefully, the affected window was short, and no money is real.
But the product's entire claim is that its numbers are true, and we publish our own defect register for the same reason. A team that hides the one bug that undermines its verification story has no standing to ask anyone to trust the verification story.
The Turbo receipts card — the Settings card counting warm vs cold opens, median routing latency and per-site main-thread stalls, all measured locally and never sent anywhere — was in v2.8.0 and went unmentioned in its release notes. It is described in both entries now, where it belongs. More on Turbo →
v2.8.0 shipped with attestation-chain recording broken
The release accidentally carried half of an in-flight migration: fills asked for the new segmented chain store, which was not aboard, so every paper fill made on v2.8.0 failed to append to your local attestation chain (the honest "could not be added to the verification chain" toast fired each time — the failure was visible, the chain simply could not record). Your wallet, balances and P&L were never affected — the chain is the tamper-evidence layer used by leaderboard verification. On v2.8.1 the chain records again; fills made during the v2.8.0 window are simply absent from the chain, and the verify panel will honestly show that gap rather than pretend it is not there.
The attestation chain grew up (F-14)
It moved out of the wallet state into a single-writer segmented store: a fill now rewrites one small tail segment instead of the whole history, multi-tab chain races are gone, and no hash is ever truncated. Backups are downgrade-safe — a new backup restores intact on a pre-segmentation build. Resets clear the chain atomically with the wallet, and the leaderboard verifier format is unchanged.
For the record: v2.8.0 also contained the Turbo receipts card
The Settings card counting warm vs cold opens, median routing latency, and per-site main-thread stalls — measured locally, never sent anywhere. Its release notes did not mention it; the feature description now lives in both entries, where it belongs.