Qubic: the recovery process distinguishes signatures from proof of ownership

Recovery becomes a case built on evidence

Following the incident affecting 1,404 wallets in October, Qubic describes a process intended to allocate funds to their legitimate owners. The project's claims portal sets the application deadline at 1 May 2027. It distinguishes submitting a claim, reviewing it and potentially returning funds. Opening a process therefore does not mean that every victim has already recovered their assets.

The central issue is proof of ownership. A signature from the affected identity can also be produced by someone who has reconstructed its vulnerable secret. The portal therefore requests additional evidence, such as proof of an exchange withdrawal to the address concerned or a funding record predating the incident. The signature links the claim to a destination without resolving the dispute on its own.

A generation flaw is distinct from consensus

The incident announced by Qubic concerned recovery secrets that were insufficiently random. These secrets provide access to the means of signing for wallets. When they can be guessed from an excessively limited set of possibilities, the expected protection no longer depends solely on their apparent length. An attacker can acquire the ability to sign without changing the rules by which the network recognises a transaction.

This distinction explains why a consistent blockchain history does not, by itself, guarantee the security of every piece of software used to create wallets. The network can record a technically valid signature even though the person who produced it is not the legitimate owner. The problem then concerns control of the secret rather than general falsification of the ledger.

Updating does not replace an old secret

Qubic presented version 4.26.4 as a fix for the generation of new secrets. This correction does not retroactively transform secrets already created. Opening an old wallet in a newer version and having a new destination identity are two different operations. The claims instructions request a fresh destination and specify that the affected secret must not be reused.

The project's general documentation also distinguishes wallets connected directly to nodes from those using an intermediary service. These access differences may explain an interface's availability, but they prove neither ownership of funds nor progress on a recovery claim. Software status and the decision to return funds must be monitored separately.

Steps before payment

The process provides a seven-day challenge period for approved claims. Where competing claims have not yet been resolved, the cases concerned remain on hold pending their resolution. It also separates funds held on Qubic from those transferred to MEXC, whose treatment depends on other parties. The process therefore does not provide an identical repayment date for every case.

Finally, the portal states that the team requests neither recovery secrets nor fees for this procedure. This precaution addresses the risk of a second compromise during an attempted recovery. When assessing the aftermath of the incident, containment announcements, approved claims and payments actually executed must remain three distinct pieces of information. An amount described as blocked cannot automatically be treated as money already returned to its owner.