The Bitget Wallet and the Bitget exchange are two different products with two different custody models. The attack Bitget disclosed on September 24, 2026 hit the exchange's systems. Anyone ho
The Bitget Wallet and the Bitget exchange are two different products with two different custody models. The attack Bitget disclosed on September 24, 2026 hit the exchange's systems. Anyone holding crypto-assets in the Bitget Wallet was not automatically affected, because a different mechanism decides access there. That mechanism is precisely the point most users have never looked up: in the keyless version of the wallet, one of three key shares sits on a Bitget server, and without that share no signature comes about.
This text pulls the two apart. First the situation at the exchange, then the technology of the wallet, after that the consequences for custody, supervisory law and tax in Germany.
The shared name misleads. The exchange is a centralised trading venue. You pay money in, the balances sit in a database held by the operator, and the private keys to the addresses where the coins actually sit are managed by the company. That is custody by a third party, custodial in the jargon. You hold a claim against the exchange, not immediate control over the coins.
The wallet works differently. It is an app that generates and keeps keys on your device, and it is therefore called self-custody. The wallet's product page frames this as a property of the product and cites the protection of balances through encryption and self-custody. It also advertises access to tokens on more than 130 blockchains and a protection fund of $300 million.
A protection fund, however, is a promise from the provider and not a property of self-custody. With genuine self-custody you need no fund in the event of damage, because nobody but you reaches the keys. The more prominent a fund becomes in the advertising, the more closely it pays to look at who actually signs alongside. We come to that further down.
On September 24, 2026, Bitget disclosed that attackers had drained balances from the exchange's hot and warm wallets through unauthorised transfers, and temporarily suspended withdrawals. The sum cited moved upwards over the course of the investigation: initial reports named $351.6 million, while the later account puts it at $387.5 million. Both figures come from the communications around the same incident, and as long as no conclusive audit exists, the range is the more honest statement.
On the cause, Bitget explained that it had identified malicious activity connected to third-party security products, including a previously unknown vulnerability, a so-called zero-day. The security firm SlowMist dates the earliest suspicious activity to August 31, 2026. Mandiant describes the attackers gaining access to third-party security appliances and moving on from there into the exchange's wallet environment. Around $1.1 million was frozen or recovered through Circle, Tether and NEAR Intents.
Important for placing this: what was affected were the exchange's hot and warm wallets, meaning the systems with which a trading venue settles ongoing deposits and withdrawals. Those are corporate systems. A key that sits only on your own phone is not deposited there. Withdrawals at the exchange reopened in stages from September 28, and in the weeks that followed customers pulled out balances on a large scale.
The attack in September 2026 ran through the exchange's systems and their connection to third-party security products, not through the devices of wallet users.
The private key is the number with which a transfer out of a blockchain address is signed. Whoever has it can dispose. Whoever does not have it cannot, regardless of what an app displays. The only question that counts with any provider is therefore: who can sign?
At the exchange the answer is clear. The company signs and you submit an instruction. That has advantages, for instance if you lose a password, and it has the drawback that an attack on the corporate systems can reach your balances. At the wallet the answer in the keyless version is not simply "you" but "your device together with a server". Which forms exist for this and how they differ in cost and access separates out on exactly that question.
The Bitget Wallet offers two ways to set up an account. One is the classic mnemonic wallet with a word sequence. The other is the keyless wallet, which does without a word sequence and relies instead on multi-party computation, abbreviated MPC. No single key arises that is stored somewhere. Several shares arise instead, and several parties jointly compute a valid signature without ever assembling the complete key.
Bitget describes its own implementation in the announcement of the MPC wallet with three shares. One sits on the device you are currently using. A second sits on the platform's server. The third sits as a backup in a cloud, iCloud or Google Drive for example, and takes no part in the signature. Signing requires two of the three shares, and on this account they are the share on the device and the share on the server.
When setting up, according to the provider's own guide, you first choose "Create Wallet" in the app and then "Keyless Wallet". You set a six-digit transaction password that applies exclusively to this type of wallet, while access to the account itself runs through a sign-in procedure such as email with a confirmation code. The app then prompts a backup to the cloud, and the status switches to "Backed Up". For cases where shares have to be redistributed, the documentation names a reshare mechanism without setting it out in detail.
Here lies the core of the matter. If signing requires the share on the device and the share on the server to come together, then every transfer out of a keyless wallet depends on Bitget's server joining in. Bitget places this expressly on the record and writes that the share held on the server may take part in the signing process only with the user's explicit consent and approval. The announcement simultaneously sets this against third-party custody, where the platform could access user balances unilaterally.
That is a different statement from the one many readers turn it into. It says that, on Bitget's own account, the company does not deploy the server share without your approval. It does not say that you could sign without the server share. What happens if that server is permanently unreachable or a company discontinues the service is something the announcement does not set out. In practice that means the keyless wallet takes the burden of the word sequence off you and puts an ongoing dependency on a service in its place.
Technically that is a deliberate trade and not a flaw. A word sequence on paper is the most common reason for final losses, because it gets lost, photographed or disappears in a house fire. A procedure that replaces it solves a real problem. Only the result is then a hybrid between self-custody and a service, and anyone taking the advertising for self-custody literally underestimates the role the provider retains in the chain.
The alternative is available in the same app. A mnemonic wallet generates a word sequence that represents the seed of the key, and Bitget offers it, by its own documentation, with 12 or with 24 words. Choosing it gets you a wallet whose key can be restored from those words alone, on any compatible device and without the provider's involvement.
With that the risk reverses. Nobody can lock you out, and nobody has to sign alongside. In exchange you carry the burden of safekeeping entirely yourself, and the documentation points to exactly that: the word sequence can be stolen or forgotten and has to be stored securely. For amounts that would hurt you, this is the variant that earns the term self-custody without a footnote.
Which of the two types is running in an existing account can be checked in the app. The distinction is not cosmetic: it decides whether you can act alone when it matters.
In the keyless version one key share sits on the device in your hand, while the second share needed for signing sits on a server belonging to the provider.
The third share, which the app stores in iCloud or Google Drive, is a backup on Bitget's account and takes no part in signing. Two things follow from this. First, access to your cloud account alone is not enough to transfer in your name, because two signing-capable shares are needed for that. Second, this backup is nonetheless a sensitive point in your security chain, because it exists so that a lost device can be replaced.
The account holding this backup therefore deserves the same care as access to the wallet itself, so two-factor sign-in and a password used nowhere else. A cloud account reachable through a recovery email with weak protection undoes good procedures in the app.
The European MiCA regulation governs service providers that hold crypto-assets for others or trade in them. Anyone offering software with which users keep their own keys, by contrast, provides no custody within the meaning of the regulation, as long as the provider cannot dispose of the balances. Pure self-custody wallets therefore do not appear in the registers of authorised service providers, and their absence there is no shortcoming but a consequence of that boundary.
For users that produces a clear split in the questions to ask. At the trading venue the authorisation is relevant, because other people's money and other people's coins sit there. At the wallet the authorisation says less than the question of who signs. A wallet whose provider is needed for signing moves back towards a service in that one respect, even if it does not present itself as a custodian. What matters is that you know which of the two worlds your holding currently sits in.
If the point that bothers you about the keyless version is the dependency on someone else's server, the route leads to a device that generates keys offline and performs signatures itself. A hardware wallet holds the private key in a chip that does not release it. For signing, the unfinished transfer travels into the device, is confirmed there, and only the signature comes back. Neither an app nor a provider's server is involved.
This tier costs money and a moment of familiarisation, and it shifts the risk once again, namely onto the safekeeping of the word sequence and onto buying from a source you trust. For long-term holdings it is the most sober answer to the question of access. The differences between the devices, from the form factor to the supported networks, are set out in our hardware wallet comparison.
An intermediate solution that often gets overlooked: you do not have to decide on one form. Amounts you trade with can sit at a trading venue or in an app wallet, while the holding you intend to keep for years sits on a device without a network connection. Splitting by purpose is the part of security work that takes the least effort and delivers the most.
Anyone moving balances from an exchange to their own wallet after the incident often wonders whether that creates a taxable event. Under the German finance ministry's circular on individual questions of the income tax treatment of crypto-assets of March 6, 2025, which replaces the 2022 version, a transfer between wallets of the same owner changes nothing in the attribution: nothing is disposed of, and a running holding period continues. What remains decisive for tax is the one-year period under section 23 of the Income Tax Act and the attribution under the first in, first out method.
What does increase is the documentation work. Every transfer has to remain traceable later so that the attribution of acquisition dates holds, and self-custody does not release you from the record-keeping duty. Anyone using several wallets and trading venues quickly reaches the limit of a spreadsheet; which tools bring the transactions together is shown by our overview of crypto tax tools and portfolio trackers. For an individual case, especially with staking or lending running in the background, a visit to a tax adviser remains more reliable guidance than any how-to.
Open is the announced reform that would remove the holding period for crypto-assets acquired in future. So far it is a draft and not a law, and it changes nothing about the treatment of transfers between your own wallets.
The Bitget Wallet is not the Bitget exchange, and the attack of September 2026 ran through the trading venue's systems. Users of the wallet should therefore not be reassured because nothing happened, but because they know which variant they are running. In the keyless wallet every signature needs the share on the provider's server; in the mnemonic wallet it does not. On that hangs whether you can act alone when it matters.
(As of October 11, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)
