HostNexFlow › Library › Burner wallet vs browser extension
Burner wallet vs browser extension wallet: two threat models, not two products
A burner is a keypair you expect to throw away. An extension wallet is a keypair you expect to keep. Every security difference between them follows from that one expectation — how much is behind the key, what an approval can reach, and what you can recover when it goes wrong.
The question "which is safer" has no answer until you say what you are defending. A browser extension wallet holding your long-term position is a high-value target with a strong perimeter; a burner holding this afternoon's trading float is a low-value target with almost no perimeter at all. Both are hot wallets — the key is on an internet-connected device — and both are one bad signature away from being empty. The difference is what "empty" costs, and what you had to click to get there.
NexFlow runs surfaces on both sides of this line. The Telegram mini app generates a PIN-encrypted local key on your device — a burner by design, described on its feature page — while the wallet-trade lane connects an extension wallet and asks you to sign every transaction yourself. A third lane, the account wallet, is neither: an enclave-held key with no seed phrase, which we mention because it is where people who dislike both of these models end up. Every row below describes how these surfaces work as of 2026-09-27, sourced to the pages that document them, or states a property common to every wallet of that type.
The threat-model table
| Threat or property | Burner wallet (ephemeral local keypair) | Browser extension wallet |
|---|---|---|
| Where the key lives | Generated on the device and encrypted at rest — in our mini app, with a PIN-derived AES-GCM key (PBKDF2-SHA256, 310k iterations); only ciphertext reaches Telegram CloudStorage (/features/telegram-mini-app/, as of 2026-09-27). | In the extension's encrypted storage on the device, unlocked by a password for the browser session (general property of extension wallets, as of 2026-09-27). |
| Intended lifetime | Short — a float for one session or one strategy; rotate when done (design intent, as of 2026-09-27). | Long — one address you keep and accumulate in (general property, as of 2026-09-27). |
| Blast radius of a compromise | Whatever is in the burner and nothing else; the whole point is that this is small ("small balances are the right size for it", /features/telegram-mini-app/, as of 2026-09-27). | Everything the extension's accounts hold plus everything they have open approvals on (general property, as of 2026-09-27). |
| Signing prompt | Typically none per trade after PIN unlock — the key is local and the surface signs in-app; only already-signed transactions leave the device (/features/telegram-mini-app/, as of 2026-09-27). | One popup per transaction; you approve each in the extension (/features/wallet-trade/, "You approve every transaction in your wallet's popup", as of 2026-09-27). |
| Approval sprawl | Limited by lifetime — a key you rotate carries no ancient approvals (design property, as of 2026-09-27). | Accumulates — every dapp you ever approved may retain a token allowance until revoked (general property of EVM allowances and Solana delegate approvals, as of 2026-09-27). |
| Phishing surface | The surface that holds the key — in our case, the mini app inside Telegram; a fake site cannot request a signature from it. | Any site that can call the extension's provider; malicious sites request signatures that look like legitimate ones (general property, as of 2026-09-27). |
| Recovery if the device is lost | Only via the one-time key backup the app forces before first trade; without it the burner is gone (/features/telegram-mini-app/, as of 2026-09-27). | Seed phrase restores every account derived from it (general property, as of 2026-09-27). |
| Recovery if the key is stolen | None — move what is left, discard the key; loss is bounded by the float. | None — move what is left to a fresh seed; loss is bounded by the whole wallet plus approvals. |
| Host platform can read storage | Yes — Telegram can read CloudStorage, so the PIN is the protection; the app forces a 6+-character PIN (/features/telegram-mini-app/, as of 2026-09-27). | The browser and any extension with sufficient permissions can, in principle, observe the page; the extension's password is the protection (general property, as of 2026-09-27). |
| Fee on NexFlow | Flat 1% on executed trades (/features/telegram-mini-app/, as of 2026-09-27). | Flat 1% on executed trades via the wallet-trade lane (/features/wallet-trade/, as of 2026-09-27). |
Blast radius is the whole argument for a burner
Security people talk about blast radius because it is the one variable you control completely. A burner is not safer because its cryptography is better — it is the same curve, the same signature. It is safer because you never put more in it than you are prepared to lose in a single bad afternoon. When a burner is compromised, the attacker gets the float. When an extension wallet holding a year of accumulation is compromised, the attacker gets the year. Our mini app's own documentation says this without euphemism: it is a hot wallet, the PIN is the protection, and small balances are the right size for it. That is the correct way to describe any burner, ours included.
The flip side is that a burner's small size makes people careless with it in ways they would never be with the main wallet — reusing it for weeks, letting it grow, skipping the backup. A burner that has quietly become your main wallet has all of an extension's blast radius with none of its recovery. Rotate it, or admit it is no longer a burner.
Approvals: the cost of a long-lived key
An extension wallet's real exposure is usually not the balance; it is the approvals. Every EVM token allowance you granted to a contract, every Solana delegate approval you signed for a program, sits on that address until you revoke it. A year of active use leaves a trail of standing permissions, some to contracts that have since been upgraded, abandoned or exploited. When one of them turns hostile, it does not need your signature — it already has it. The one-popup-per-transaction model of the wallet-trade lane is the right discipline for this: you see and approve each action, and the page never holds anything. But the discipline only protects the future; it does not clean up the past. A burner sidesteps the problem by not having a past. A key you generated this morning has no ancient allowances to exploit, and a key you discard tonight will never accumulate any.
Neither of these is "non-custodial" in the marketing sense that matters. Both hold the key on your device, which is what the word means — and both are hot, which is what the word does not say. Our account wallet deliberately avoids the term because its key lives in an enclave rather than on your device; the burner and the extension earn it, and also earn the exposure that comes with it.
Recovery: the burner's honest weakness
This is where the extension wins, and it wins cleanly. A seed phrase written down once restores every account derived from it on any device, forever. A burner has no such structure. In our mini app the key is generated locally and the app forces a one-time backup before your first trade — if you skipped it, lost the phone, and forgot the PIN, the float is gone, and no one can help. That is not a bug; it is what ephemeral means. The right response is not to bolt recovery onto a burner but to never hold more in it than you would shrug at losing. If you find yourself wanting robust recovery for a wallet, that wallet is not a burner and should not be run as one.
Theft is symmetric: neither model can recover a stolen key. You move what is left to a fresh key and count the loss. The difference is only in the size of the count — and in the case of the extension, in the hours spent revoking approvals from an address you no longer trust.
Who should pick a burner, who should pick an extension
Pick a burner if you are trading a float you can afford to lose, on surfaces where a signature popup per action would defeat the purpose — rapid entries, in-chat trading, sniping — and you are disciplined enough to rotate it and keep it small. Take the forced backup seriously and treat the PIN as the only lock on the door, because it is.
Pick an extension if the wallet holds anything you intend to keep, you want to approve every transaction with your own eyes, and you can live with the approval hygiene a long-lived address demands. Use it through a lane like wallet trade that never holds your funds and asks for one signature per action, and revoke old allowances on a schedule.
Most careful traders run both and never let them touch: a burner for the fast lane, an extension for the position, and a hard rule about which one a given token is allowed to be bought with. Whichever key is signing, the contract on the other side is the same risk — run it through the token checker before either wallet touches it.
Frequently asked
Is a burner wallet safer than a browser extension wallet?
It has a smaller blast radius, not stronger cryptography. A burner holds a float you can afford to lose and carries no accumulated approvals; an extension holds your position and every allowance you ever granted. Both are hot wallets, and both are lost the same way — one bad signature or one stolen key.
How does the NexFlow mini app burner store its key?
The key is generated or imported on your device and encrypted with a PIN-derived AES-GCM key (PBKDF2-SHA256, 310k iterations); only the ciphertext is stored in Telegram CloudStorage, and only already-signed transactions leave the device, as documented on its feature page as of 2026-09-27. Telegram can read CloudStorage, so the PIN is the protection.
What happens if I lose the device holding a burner wallet?
You recover only if you kept the one-time key backup the app forces before the first trade. Without it the burner is gone. That is what ephemeral means, and it is why a burner should never hold more than you would accept losing. An extension wallet restores from its seed phrase.
Why do extension wallets accumulate approval risk?
Every token allowance or delegate approval you sign stays on the address until revoked. Over months of use, a long-lived extension address collects standing permissions to contracts that may later be upgraded, abandoned or exploited — and those contracts no longer need your signature. A burner you rotate has no such history.
Can I trade on NexFlow with my own extension wallet?
Yes — the wallet-trade lane connects Phantom or any WalletConnect wallet and asks you to sign every transaction yourself; the page never holds funds. It carries the same flat 1% fee as every other surface as of 2026-09-27, in exchange for one popup per action.