Qubic Wallet Incident: 205 Receipts, 204 Sources, and the Boundary Between Containment and Recovery

During the night of 17–18 October 2026, Qubic reported that weak wallet-seed generation had allowed an attacker to drain wallets. A seed is the secret used to derive a wallet’s signing keys: if its generation is predictable, the resulting address can remain valid while its funds are unsafe. The project reported around 2.94 trillion QU affected across 1,404 wallets. This review asks a narrower, reproducible question: what do the public transfers into one listed recipient establish, and where does the evidence stop? Project disclosure; Project explanation of the cause.

The directly checked fund path is source addresses → recipient R1. Explorer exports show 205 receipts from 204 distinct sources into R1. One of these transfers and the two transfers from the repeated source were also opened individually with their transfer-event rows. The path drawn here ends at R1. Later containment code names a separate escrow address, but this review does not join R1 to escrow with a verified execution event or independently establish victim repayments. A later project announcement reports that repayments have begun; that attributed update is distinguished below from the checked transaction subset.

The roles before the totals

QU is the native asset counted in the Qubic Explorer; the Explorer labels it QUBIC. This article uses QU consistently. A Qubic identity is the public address, not its secret seed. A tick is the network’s numbered processing step, which lets records be ordered without treating a browser’s clock display as UTC. A transfer event describes a balance movement; it is not interchangeable with a separately signed transaction.

The wallet code, the transfer record and the recovery mechanism answer different questions. Public source code can show what a patch was designed to change. Transfer records show who paid which public address and how much. Neither alone proves the attacker’s exact method, real-world identity or a completed refund.

What was checked, and what was not

The three principal findings follow from those boundaries. The receipt inventory reconciles to the community subtotal for R1. One address appears twice, explaining why transaction count and source count differ there. Finally, the later frozen-address list and escrow code establish a containment design, not transaction-level proof of recovery. The sections below explain the records behind each finding.

17–18 October — receipts converge on one address

Qubicmap’s incident checker lists seven initial recipients. R1 has the largest displayed subtotal: 568,777,432,013 QU attributed to 204 listed source addresses. Instead of adopting that row without checking it, we exported all three pages of the Explorer’s displayed signed-transfer table for R1, at 100 rows per page. The resulting 205 unique records sum to exactly the same amount. Community incident dataset; VNJZRGGRYRTKHANUZHLTHTSBQOFCTCJKUKLCVIWCSBRTZNYOJEVPGYDCDRCM.

These exports independently support that one recipient’s displayed inventory. They do not independently establish every row in the community dataset, prove who owned the source keys, or replace a native consensus replay. In particular, the sum of the seven displayed source counts is not an independently deduplicated, cross-recipient victim count.

Start Figure 1 with the source group at the top and follow the single solid arrow into R1. It represents the 205 exported QU receipts, not 205 different victims. The sample panel anchors one of those receipts to an individually opened transaction. The broken line underneath is an observation boundary, not a route to an unnamed service.

Figure 1. Blue-gray boxes summarize the exported source and recipient roles. The solid arrow means recorded QU receipts; it is not scaled to quantity or time. The pale sage panel is one individual detail check, not an additional inflow. Full records and links are retained in Appendix B.

The matching subtotal makes the community lead useful without making every wider allegation verified. The next question is why the Explorer gives 205 receipts while the dataset names 204 source addresses. That difference can be resolved inside the exported records, without guessing an extra victim.

One source paid twice — transaction count is not victim count

At tick 85,362,890, the repeated source sends 17,065,760,963 QU into R1. At tick 85,371,060 it sends another 1 QU to the same recipient. Both transaction detail pages show the same full source and destination, and each contains a matching QU_TRANSFER event row. First transfer; Later 1 QU transfer.

Counting this source once, rather than once per transfer, yields 204 distinct source identities across 205 receipts. The later 1 QU payment is not evidence of a test, a refund or a different attacker: its intent is not recorded. This local reconciliation also does not resolve a separate public discrepancy between 1,404 and 1,405 affected identities, or between seven initial recipients and eight wallets mentioned in later community commentary.

The final sampled receipt provides a second type of cross-check. At tick 85,371,146, the Explorer transaction and event both record 106,444,954 QU from source S into R1. Qubicmap’s lookup for S returns the same hash, quantity and tick, classifying it as drained. That is corroboration of the dataset entry, not independent evidence of consent or ownership. Sample transaction; Sample event.

Time requires a separate caution. Qubicmap explicitly labels this sample 18 October 01:26:10 UTC; the Explorer in the reviewed browser displays 10:26:10. The nine-hour difference is consistent with the local browser setting, but the exported CSV has no timezone label and raw UTC was not independently obtained. Appendix B therefore preserves its display time as recorded and orders records by tick. It does not silently relabel those timestamps as UTC.

18 October — the patch changes seed generation, not existing keys

After the reported transfer window, the wallet repository records a change replacing Math.random-based generation in the create-vault and seed-edit flows with a shared secure generator. The v4.26.4 helper reads random bytes through crypto.getRandomValues. It refuses to generate a seed if that capability is absent. Pinned wallet patch; v4.26.4 release.

The helper produces 55 lowercase letters. It accepts byte values below 234, then maps each accepted value to one of 26 letters; rejecting the remaining byte values avoids giving some letters more possible inputs than others. This is a direct code observation, not a measurement of how unpredictable the random input on an affected device was (its entropy). We did not reproduce the attacker’s seed search, inspect a victim device, or establish which exact bundle every affected wallet ran.

A public proposal opened on 12 February 2026 already discusses secure seed generation. Its existence is relevant history, but it does not by itself establish a decision-maker’s knowledge, intent, or the precise cause of every affected key. Likewise, publishing a patched generator does not replace keys created earlier or prove that every installed wallet has updated. Earlier public proposal, PR 229.

19 October — a frozen list and an escrow design

The project’s earlier update reported a network halt at tick 85,371,949. On 19 October, Core PR 1048 was merged for v1.308.2. The pinned frozen-address file contains 2,797 distinct identities and specifies FREEZE_FROM_TICK 85,371,950. All seven dataset recipients and the individually sampled source occur in that exact list. The larger list must not be called 2,797 confirmed victims: the containment change also addresses at-risk funds. Project halt statement; Merged Core change; Pinned frozen-address list.

The associated sweep code describes reducing frozen balances, increasing the escrow balance and logging QU transfers, alongside asset handling. A later commit explicitly sets the escrow identity preserved in Appendix A. This is a different type of evidence from an ordinary signed transfer: protocol-generated balance movements may not appear as signed transactions in an Explorer table. Sweep implementation; Escrow identity commit.

Read Figure 2 from top to bottom as evidence stages, not a stream of money. The first box is the pinned code configuration. The second is an Explorer account-header observation. The dashed third box outlines the execution and reimbursement records still needed. The bottom panel separately identifies the later project announcement; it is not another directly checked transfer. There are no fund-transfer arrows between these boxes because this review has not verified those joins.

Figure 2. Sage marks directly read repository configuration; blue-gray marks a separate aggregate Explorer observation; the dashed neutral panel marks missing execution and repayment evidence. The bottom panel is a later project statement, not an independently verified payment record. Vertical order is a reading guide only. These are not amounts to add together.

The escrow account header displayed 2,836,660,961,867 QU and 1,441 incoming transfers during the 20 October review, with its latest incoming tick shown as 85,398,715. Its detailed Transactions and Events panels returned no records at that time. R1’s header likewise showed a later outgoing count, while the signed-transfer export contained only receipts. The Explorer’s Events feature warns that coverage is provisional. These mismatches prevent a transaction-level reconstruction of the sweep; an empty detail table does not prove that no protocol movement occurred. XMGUNWJYLLUUZANFEWJNNIDMXNSDMPOVFAHWOERKDDAWDREZLANHTFJBKMPB.

Nor can the escrow header be subtracted from the incident total and called missing funds or recovered funds. The two figures have different populations and observation points. A recovery conclusion requires the actual sweep events, their source identities, quantities and ticks, followed separately by evidence of payments to entitled holders. None of those missing joins is drawn as a confirmed path here.

20 October — the project reports restart and first repayments

At 18:14:20 UTC on 20 October (21 October in Korea), Qubic announced that the Computor quorum had approved recovery, the network was live again, the reclaim platform was open and the first funds had returned to verified owners. A following post said affected funds had been moved into protected escrow during the halt. These are newly read project statements, not independently matched sweep or repayment transactions. Restart and first-repayment announcement; Project escrow account.

This changes the reported operational stage from planned containment to announced recovery in progress. It does not change the 205-receipt inventory or provide a verified recipient-by-recipient refund ledger in this review. The statement does not supply a repayment amount in the text examined; no recovery percentage is calculated. Figure 2 therefore keeps the directly checked code/header evidence separate from the project’s later announcement and draws no payment arrow.

The project also states that the claim window runs until 1 May 2027. Readers should navigate from the verified project announcement for current instructions; this report neither submits a claim nor requests a seed. The source’s announcement of first payments must not be rewritten as full restitution. Project claim-window statement.

What the wider claims still need

The project’s 18 October statement said 87.1% remained on-network and 12.9% had reached MEXC and been frozen. This is a dated project account. This review has not obtained and verified the complete MEXC deposit identity and transaction chain, an exchange confirmation, or a current freeze-status record. It therefore does not label any of the seven recipients as MEXC or call a payment a completed cash-out. Dated project funds-status statement.

An alternative interpretation of the missing signed outbound records is a system-generated sweep rather than an ordinary signed transaction. The official implementation makes that technically plausible. It remains an interpretation until the relevant execution records are obtained. The same discipline applies to the two small-versus-large payments: a visible sequence is not a recorded motive.

Where the next response should focus

For affected holders, the specific concern is the generation of the original secret, not an ERC-20 allowance. A software update can prevent the old generation path from being used again; it cannot make an already exposed secret unpredictable. Any migration or claim should use the project’s verified channels and current containment instructions, without submitting a secret seed to a checker. The public checker reviewed here uses an address, not a seed.

For maintainers, the next evidence should join the approved release to its actual network execution: frozen identity, movement event, quantity, escrow destination and tick. For service investigators, the next separate task is the exact MEXC deposit trail and the service’s status record. For this report, the strongest completed result is narrower: one independently summed recipient inventory, a concrete explanation of its extra transfer, and a clearly marked boundary between containment design and demonstrated recovery.

Appendix A — full address roles and source boundaries

The next table transcribes the community dataset, not seven independently replayed inventories. Only R1’s 205-row signed-transfer listing was exported and reconciled. “Source entries” follows the site’s grouping; a globally unique victim count has not been independently established.

The seven quantities sum to 2,939,606,531,944 QU and their displayed source counts sum to 1,404. Frozen-list membership was checked against the pinned file for all seven recipients and the sample source. Membership describes the code’s target set, not the legal identity or guilt of an address owner.

Appendix B — reproducible receipt inventory

The following 205 records reproduce the three downloaded Explorer pages for R1, sorted by tick and hash. They are exported listing observations, not 205 individual detail-page or signature-replay checks. Every row has the same R1 destination given in Appendix A, input type 0 / Transfer, and the exported status Successful transfer. Full source identities and full transaction hashes are preserved. Amounts are exact QU integers; no USD valuation or additional fee estimate is included. The time column is the CSV’s browser display time on 18 October 2026, with timezone unspecified in the export—not a UTC claim.

Receipt records 1–15

Receipt records 16–30

Receipt records 31–45

Receipt records 46–60

Receipt records 61–75

Receipt records 76–90

Receipt records 91–105

Receipt records 106–120

Receipt records 121–135

Receipt records 136–150

Receipt records 151–165

Receipt records 166–180

Receipt records 181–195

Receipt records 196–205

Method: the actual Explorer Download Page Data control was used on all three pages with 100 rows per page. Rows were deduplicated by full hash; distinct sources were counted independently. Integer addition gives 568,777,432,013 QU. Three selected transactions were separately opened and matched to their visible event rows. No private key was requested, no recovery action was executed and no address-owner attribution is inferred from these exports.

Primary and attributed sources