When trust fails around Bitcoin
The recent security incidents did not demonstrate a break in Bitcoin’s rules. They exposed the promises surrounding them: that a wallet would generate sound keys, a provider would protect your records, and a claim on bitcoin could be redeemed. Self-sovereignty begins by separating those promises from Bitcoin itself.
Bitcoin does not maintain a shipping database. It does not run an email marketing account. It does not promise that a token on another network is backed, or decide when a payment company will release a payout.
Companies and software do those things. When they fail, the damage to Bitcoin users can be real without being a failure of Bitcoin’s consensus rules. Calling every such incident a “Bitcoin hack” hides the system that actually failed—and the authority its users had entrusted to it.
That distinction is not an excuse for the industry. It is an obligation to be more precise about whom we trust. A wallet can remain in your possession while an attacker reconstructs its keys. A token can remain in your wallet while its reserve or exit depends on somebody else. Keeping a key is not the same as removing every trusted party.
On September 14, Swiss Bitcoin Pay disclosed suspected access to internal systems and paused its servers. It said customer records might have been accessed and that user funds were safe. That last assurance was the company’s statement, not an independent finding. Its follow-up explained that it temporarily holds some incoming Lightning funds while batching payouts on-chain. The important distinction is between a payout destination you control and money still moving through somebody else’s service.16;17.
The payment company’s infrastructure is not Bitcoin’s ledger. Yet its customers still bear the consequences. That is the thread connecting this summer’s cases: not a demonstrated defeat of Bitcoin’s rules, but failures in the systems people trusted to reach, hold or use it.
A summer of different failures
The timeline below selects eight Bitcoin-related cases documented between June and September 14, 2026. Some involve theft or unbacked claims; others involve phishing, exposed records or a vulnerability disclosure. A disclosure date is not necessarily the attack date. This is not a census of hacks, a loss leaderboard or evidence that attacks are becoming more frequent.
Method
Selected source-backed incidents and disclosures, June 1–September 14, 2026. Cards follow chronological sequence; spacing is not elapsed time. Labels distinguish event and disclosure dates. Follow-ups stay with the original case. No total loss, frequency trend or exhaustive census is inferred.
June 24 — A security warning arrives through the letterbox. Coinkite warned about physical letters impersonating it and demanding a supposed post-quantum firmware upgrade. The company said its server audit had found no reason to suspect a breach. The source of the addresses was unresolved. A convincing letter was evidence of impersonation, not proof that a wallet manufacturer had leaked its database.01.
June 25 — Bitcoin claims appear without bitcoin behind them. A forensic report subsequently linked from Osmosis governance traces unbacked nBTC issuance to June 25. The report identifies 25 distinct packets minting about 40.65 BTC-denominated nBTC, with much of it reaching the allBTC pool. These were not counterfeit bitcoin accepted by Bitcoin nodes. They were claims issued through another system. September’s backing-restoration proposal is a later response, not the attack date or proof that recovery was completed.02;03.
July 30 — The keys themselves are the weak point. Coinkite’s Coldcard advisory disclosed weak seed generation and thefts affecting specified models and firmware. The device did not have to be remotely taken over: an attacker able to reconstruct a private key does not need the owner’s hardware. The broken assumption was that the wallet had created an unpredictable secret—not that Bitcoin would refuse a valid signature from someone holding it. The manufacturer’s guidance distinguishes affected generation methods and says a firmware update does not repair an already affected seed.04.
August 13, expanded September 4 — The wallet and the customer file are separate systems. Trezor disclosed exposure at shipping provider ShipMonk, then expanded the affected scope in September. According to Trezor, the incident concerned customer records, not its devices or internal systems. The follow-up belongs on the same incident’s timeline. A leaked delivery address does not prove a current bitcoin balance, but it can give an impersonator a credible detail to use against a customer.08. SG previously examinedsatoshigazette.org.
September 6 — Holding a sidechain key does not control its reserve. Liquid’s operator report described an Elements verification flaw that enabled unbacked L-BTC and withdrawals from the Bitcoin reserve. Chainalysis separately analysed the exploit and subsequent return of funds. The distinction is structural: signing for an L-BTC balance is not the same power as unilaterally spending the bitcoin held by the federation.09;11. Oursatoshigazette.org examines that exit dependency.
September 9 — Self-hosting still requires a secured service. Alby disclosed a management-access vulnerability affecting publicly reachable Hub versions 1.7.0–1.18.5. It reported one impacted user, without a loss amount, and said version 1.19.0 and later were unaffected. Its mitigation guidance includes updating, changing the unlock password and deleting app connections for exposed affected installations—not simply hiding a web page. A separate documentation fix corrected misleading localhost guidance. Running software yourself does not make its management interface safe by default.12;13.
September 9–10 — The familiar delivery system carries the fraud. Trezor dates its phishing campaign to September 9; Brevo describes identifying and closing a cross-account authorization flaw on September 10. The platform’s own sending capability had been abused. A familiar sender therefore could not establish that the message’s instructions were legitimate. Recipient counts must not be presented as wallets stolen.14;15. SG’ssatoshigazette.org follows the attack from delivery to the request for a wallet backup.
September 14 — Records may outlive a payment-service outage. Swiss Bitcoin Pay’s initial notice listed email addresses, Bitcoin addresses, IBANs, transaction history and hashed passwords among the information potentially accessed. The scope remained uncertain. Its assurance about funds does not settle the separate question of privacy. SG’ssatoshigazette.org preserves that distinction rather than turning a suspected exposure into a confirmed theft.
Non-custodial does not mean trust-free
Coldcard matters here precisely because it does not fit a comforting story about careless exchange users. The manufacturer’s technical account describes a software integration failure in the random-number path used to create keys. Block’s Bitcoin engineering team published source-linked analysis of predictable random-number behaviour, while explicitly limiting what its preliminary work established. Block also develops wallet products; its analysis is useful because readers can inspect the technical argument, not because a competing brand is a neutral authority.05;06.
Self-custody removes the need for a custodian to authorize a withdrawal. It does not prove that the secret was generated unpredictably, that no copy exists or that the signing software behaves correctly. Bitcoin can validate a signature. It cannot determine whether the person producing it is the rightful human owner or an attacker with the same key.
Third-party trust is therefore broader than leaving coins on an exchange. It includes reliance on a wallet implementation, a hosting service, a shipment processor or a federation’s redemption policy. Self-hosted software is not a third-party custodian simply because somebody else wrote it; nevertheless, its code and configuration remain dependencies to examine. Moving the software into your home changes who operates it, not whether a flaw can exist.
The opposite exaggeration is also wrong. A dated advisory is not proof that every device from that manufacturer remains vulnerable forever. Coinkite publishes a model-specific status page and remediation guidance. The relevant questions are which firmware generated a seed, which generation method was used and what the current guidance requires—not whether a logo belongs in the “safe” or “unsafe” camp.07.
This is why brand loyalty is a poor substitute for verification. A shipping-data leak and a weak seed are both serious, but they betray different promises. “Bitcoin still works” is true to the distinction only if we also name what failed around it and who was responsible for that system.
Keep the keys. Run the node. Know what each does.
Spending authority — Keep the keys. Control authorization without a custodian. Does not prove a seed was unpredictable or remains secret.
Independent validation — Run your node. Check Bitcoin rules; connect your wallet to use it. Does not erase leaked records or guarantee token backing.
Proof-of-work — Understand mining. Participate in block production and history security. Does not protect stolen keys. Pool and payout dependencies remain.
Keep the keys means keeping spending authority out of a custodian’s hands. It also requires a recoverable, understood setup. A backup exposed to an attacker is not made safe by keeping the hardware device locked away. Equally, adding complexity that the owner cannot recover is not automatically an improvement.
Run a node—and connect your wallet to it means checking Bitcoin transactions and blocks against the rules you accept. A node sitting unused elsewhere does not independently check what your wallet’s chosen server tells it. Using your own backend can also reduce the wallet information disclosed to public servers. It does not make the public ledger anonymous, erase information already leaked or certify that a wallet’s seed was sound.18;19.
Mine, if it fits your circumstances, to participate in proof-of-work and block production. Mining helps make transaction history costly to rewrite. It is not an additional lock on a private key and cannot reverse a valid spend made by a thief who obtained that key. A pooled miner also needs to understand who supplies the block template and who owes the payout. Hashing and independently choosing transactions are not necessarily the same role. You do not need to mine to hold keys or validate Bitcoin.20;satoshigazette.org.
These are complementary forms of participation, not a ladder on which buying more equipment eventually makes every risk disappear.
For bridged or federated assets, add another question: what can I actually redeem without permission? A correctly displayed token balance answers a different question from whether its backing exists, who controls it and what conditions govern the exit. The Liquid and Nomic cases belong alongside Bitcoin reporting because bitcoin is the promised asset—not because those systems inherit Bitcoin’s guarantees.
The file that you cannot move to cold storage
A company can restore a server. A customer cannot reliably recall every copy of a stolen database.
Bitcoin’s transaction history is public. An address alone is not an identity; once information links the two, historical activity can become easier to associate with a person. Address reuse can extend that exposure. None of this means every address holder owns every balance an observer attributes to them. It does mean that privacy requires attention before a leak, not only a password reset afterwards.21.
Here the burden cannot fairly fall only on the customer. SG’s position is that a company selling sovereignty should explain what it retains, why it retains it, which suppliers receive it and when deletion actually happens. “Our devices were not compromised” may be an important and accurate statement. It is not a complete answer about the people in the customer file.
The same standard applies to email and support. A reader should reach an advisory through an independently checked official channel rather than obey an urgent link. But a provider must secure its authorization boundaries; users cannot compensate for a platform allowing one account to act as another. Blaming recipients for trusting the delivery infrastructure evades the provider’s part of the failure.
Five questions worth keeping after the headline fades
Before choosing a wallet or service, ask:
- Who can spend? Include backups, recovery providers, app connections and funds awaiting payout—not only the device in your hand.
- What am I verifying myself? Distinguish a locally validated Bitcoin transaction from a service’s displayed balance or a token’s backing claim.
- What can stop my exit? Identify custodians, federation decisions, withdrawal conditions and pending settlement.
- Who can connect my identity to my activity? Include shipping, payments, support and wallet-query providers.
- What is my recovery procedure? Check that it addresses the actual failure. A password change, software update and migration to a sound new seed solve different problems.
No single incident in this selection establishes that Bitcoin’s consensus rules were broken. That is an important distinction, not an excuse to dismiss harm around Bitcoin. Nor does the selection prove perfect protocol security or that self-custody has no risks.
The lesson is not that users were foolish to trust anyone. Modern tools have dependencies, and the people building them owe users honest descriptions of those dependencies. The lesson is that trust should be limited, explicit and open to verification—not smuggled back in under a Bitcoin logo.
Keep spending authority where you can exercise it. Validate the ledger you rely on. Understand who controls a payout, a reserve, a software release or a file containing your address. Demand less unnecessary data collection and better evidence from the companies asking for your confidence.
Bitcoin’s rules are not a company’s promise. Read the ledger. Keep the keys. Know the difference.
Method: This is an original synthesis of selected public disclosures, technical reports and SG’s earlier reporting, reviewed on September 14, 2026. Dates distinguish events from disclosures and later updates. Vendor assurances are attributed; unresolved losses and data access are not promoted to confirmed facts. The timeline excludes unverified allegations and incidents outside its June–September window. It does not aggregate monetary losses, count affected people across overlapping notices, or attribute attacks to AI. Active-incident guidance must be rechecked before publication.