Why does the same seed phrase produce different addresses in Tonkeeper and Ledger Live?

Tonkeeper uses the canonical TON standard — one mnemonic becomes one Ed25519 keypair via PBKDF2 with salt 'TON default seed' and 100,000 iterations. Ledger, by contrast, builds a SLIP-0010 tree on top of an Ed25519 seed along the path m/44'/607'/account'. The same words feed both, but the cryptographic transforms are different — different private keys, different addresses.

Is this a bug or by design?

By design, but poorly documented. The TON Foundation walked away from BIP-32/BIP-44 trees and rolled its own derive. Hardware wallets (Ledger, Keystone) physically cannot implement TON-derive inside their Secure Element for every coin — they share a single BIP-39 master seed and layer SLIP-0010 on top. Engineering trade-offs collided.

Can I migrate a wallet from Ledger to Tonkeeper using only the 24 words?

No. Import the Ledger 24 words into Tonkeeper and you get a different, empty address. To move that specific account you would have to export the raw Ed25519 private key from Ledger (which Ledger Live does not allow directly) or sign a migration transaction: create a fresh Tonkeeper address and transfer funds out of the Ledger account.

Is MyTonWallet compatible with Tonkeeper on the same mnemonic?

Yes, in single-account mode MyTonWallet uses the same canonical TON derive as Tonkeeper — the same 24 words yield the same address. But MyTonWallet supports a Multi-Account mode (including BIP-39 24-word import and Ledger accounts) where addresses differ. Always check which mode is active when importing.

How many words is a TON mnemonic — 12 or 24?

The canonical TON mnemonic is always 24 words from the standard BIP-39 wordlist. BIP-39 itself allows 12, 15, 18, 21 or 24, but the TON spec pins it at 24. If a wallet offers to create a TON account from 12 words, that means it goes through BIP-44 / SLIP-0010, not the canonical TON standard.

What is the passphrase (25th word) on TON and why is it dangerous?

The passphrase is an optional extra password mixed into the mnemonic during key derive. With an empty passphrase a TON wallet creates one address; with a non-empty one it creates a completely different one. Tonkeeper supports it through the salt 'TON fast seed version'. The main danger: if the passphrase is not recorded somewhere separately, you cannot recover the wallet from the 24 words alone — every wrong character gives a different address.

Can I use a single BIP-39 seed for TON, Ethereum and Solana?

Technically yes, via libraries like bip_utils. You derive ETH at m/44'/60'/0'/0/0, SOL at m/44'/501'/0'/0' and TON at m/44'/607'/0' via SLIP-0010. But: the TON address from that multi-chain seed will NOT match the address a canonical TON wallet would produce from the same 24 words. And the attack surface grows — one chain getting popped risks all the others.

Is TON mnemonic safer than BIP-39?

On entropy — equivalent: 24 words × ~11 bits = 264 bits (minus checksum). But the TON mnemonic uses 100,000 PBKDF2 iterations versus 2,048 for BIP-39, which makes brute-forcing a partially-leaked word list orders of magnitude more expensive. On the other hand, no HD tree means key compromise compromises ALL of your TON funds under that mnemonic at once.

TON mnemonic vs BIP-39: why addresses differ

A typical scenario: a user wrote down 24 words from Tonkeeper, bought a Ledger, imported the same phrase into Ledger Live — and saw an empty TON account at a different address. First reaction: “I’ve been hacked.” In reality this is a fundamental TON peculiarity that wallet documentation rarely explains. This article is a technical breakdown of what is actually happening under the hood, why the standards diverged, and what to do about it in practice.

TL;DR

One seed phrase ≠ one address. Cryptographically, the same 24 words can produce different private keys depending on which standard the wallet uses.
Canonical TON mnemonic (Tonkeeper, MyTonWallet single-account, tonweb-mnemonic) is a TON Foundation standard built on the BIP-39 wordlist but with a different PBKDF2 derive and no HD tree.
BIP-39 + SLIP-0010 (Ledger, Trezor, MyTonWallet multi-account, bip_utils) is what hardware wallets use, because they share a single master seed across all coins. The TON derivation path is m/44'/607'/account'.
Both paths produce different addresses from the same 24 words. Not a bug — a design choice.
Migration between them is only possible by transferring funds, not by re-importing the mnemonic.

If that’s enough, you can skip the rest. What follows is for readers who want to understand why this happened and how it works cryptographically.

Where seed phrases came from

Mnemonic seed phrases originated in the Bitcoin community in 2013 as an answer to a real problem: 256-bit private keys are impossible to remember reliably, enter by hand, or dictate over the phone. The BIP-39 standard (Bitcoin Improvement Proposal 39) proposed an elegant solution — encode entropy as a sequence of words from a 2,048-word dictionary.

The standard BIP-39 wordlist is 2,048 English words 3-8 letters long, chosen so that the first four letters of every word are unique. That simplifies entry and reduces typo risk (abandon, ability, able, etc.). Localised wordlists exist in Japanese, Spanish, Chinese — but TON, like most wallets, only uses English.

Once BIP-39 became the de facto Bitcoin wallet standard, almost every blockchain project picked it up — Ethereum, Solana, Polkadot, Cosmos, and yes, TON. But “using BIP-39” means different things in different projects, and that’s where the divergence begins.

BIP-39: entropy → mnemonic → seed

Cryptographically, BIP-39 describes three transforms:

Entropy → mnemonic. Random 128, 160, 192, 224 or 256 bits (for 12, 15, 18, 21 or 24 words respectively) are split into 11-bit groups. A checksum — a few bits of SHA-256 over the entropy itself — is appended. Each 11-bit group indexes one of the 2,048 words.
Mnemonic → seed. The PBKDF2 function is applied:

PBKDF2-HMAC-SHA512(
    password   = mnemonic_words_joined_with_spaces,
    salt       = "mnemonic" + optional_passphrase,
    iterations = 2048,
    dklen      = 64
)

Output: 64 bytes (512 bits) of seed. No longer human-readable — raw material for further key derivation.

Seed → master key. That’s BIP-32 territory, see below.

Note the PBKDF2 parameters: the salt always begins with the constant string "mnemonic", and there are only 2,048 iterations. By modern standards 2,048 iterations is very little (brute-forcing PBKDF2 on a GPU is cheap). But BIP-39’s logic is not about brute-force resistance (24 words give 264 bits of entropy — uncrackable), it’s about standardisation.

BIP-32 and BIP-44: hierarchical wallets

BIP-32 describes how to deterministically build a tree of arbitrary depth of private and public keys from one master seed. Idea: one backup recovers billions of addresses, and public keys can be derived independently of private ones (for watch-only wallets).

Each tree node is addressed by a path of the form m/index/index/index/.... An index with an apostrophe (44') marks hardened derivation — a special mode where deriving a child requires the parent private key. Without the apostrophe, normal derivation allows deriving child public keys from a parent public key.

BIP-44 layered on top of BIP-32 standardises the path structure:

m / purpose' / coin_type' / account' / change / address_index
m / 44'      / coin_type' / 0'       / 0      / 0

coin_type is a standardised coin number from the SLIP-0044 registry. Bitcoin is 0, Ethereum is 60, Solana is 501, TON is 607. The canonical BIP-44 path for the first TON address would therefore be:

m / 44' / 607' / 0' / 0 / 0

But that is not what Tonkeeper or MyTonWallet actually use. Why — read on.

SLIP-0010: HD wallets for Ed25519

BIP-32 was originally written for secp256k1 — the curve Bitcoin and Ethereum live on. Solana, TON and Cardano use Ed25519. A naive port of BIP-32 to Ed25519 does not work for algebraic reasons.

SLIP-0010 (by SatoshiLabs) generalises BIP-32 to non-secp256k1 curves, including Ed25519. Key differences:

Master key is derived as HMAC-SHA512(key="ed25519 seed", msg=seed) (instead of "Bitcoin seed" for secp256k1).
Hardened-only derivation. For Ed25519, normal (non-hardened) derivation is cryptographically impossible — every index in the path is implicitly hardened.
No standalone public-key derivation. “Derive child public from parent public” does not work on Ed25519, so SLIP-0010 for Ed25519 does not support watch-only mode.

Solana uses SLIP-0010 with m/44'/501'/account'/0'. Ledger uses SLIP-0010 with m/44'/607'/account' for TON (no change or address_index, since both would be hardened on Ed25519 anyway).

Why TON walked away from BIP-44

This is where it gets interesting. The TON Foundation, while designing its wallet protocol, made several design choices that diverge from settled practice.

1. Custom PBKDF2 salt and more iterations

Canonical TON does not use BIP-39 derive from mnemonic to seed. Instead of salt "mnemonic" and 2,048 iterations, it uses:

PBKDF2-HMAC-SHA512(
    password   = mnemonic_bytes,
    salt       = "TON default seed",
    iterations = 100000,
    dklen      = 64
)

100,000 iterations versus 2,048 for BIP-39 is two orders of magnitude more expensive for a brute force attack. If a partial list of your words leaks (say 22 of 24), recovering the missing two on the TON standard takes substantially longer than on BIP-39.

2. Two-stage mnemonic validation

Before the main derive, the TON mnemonic is also validated through a fast PBKDF2 with salt "TON seed version" and 390 iterations (or 256 with passphrase-mode salt "TON fast seed version"). The first byte of the result must equal 0 — otherwise the phrase is not a valid TON mnemonic. This lets the wallet decide whether an entered phrase is a “TON phrase” or a “regular BIP-39 phrase”.

In practice this means only 1 in 256 random BIP-39 phrases also happens to be a valid TON phrase. So generating a TON mnemonic is iterative: roll 24 words, check the first byte of the validation PBKDF2, repeat until you hit 0.

3. One mnemonic = one keypair

Canonical TON does not build an HD tree. After derive, the first 32 bytes of the PBKDF2 result are used directly as the Ed25519 seed, from which a single keypair is produced. No m/44'/607'/0'/0/0 — just one key per mnemonic.

To get several TON accounts you need either several different mnemonics (which Tonkeeper does in multi-wallet mode) or a switch to a non-canonical SLIP-0010 derive (which MyTonWallet does in Multi-Account mode).

4. Optional passphrase

TON supports a passphrase (analogous to the BIP-39 25th word) through the same mnemonic validation but with a different salt — "TON fast seed version". This lets the wallet tell whether the phrase is “regular” or “with passphrase”.

What different wallets actually do

Tonkeeper

Canonical TON standard. 24 words → PBKDF2 with salt "TON default seed" → 32-byte Ed25519 seed → one keypair → one address. No derivation paths. Supports passphrase via the "TON fast seed version" salt.

For multiple accounts Tonkeeper stores multiple separate mnemonics; it does not derive them from a common seed. Importing a “regular” BIP-39 phrase into Tonkeeper that fails TON validation (first PBKDF2 byte ≠ 0) raises an error.

MyTonWallet

In single-account mode MyTonWallet is fully Tonkeeper-compatible — same canonical derive, same 24 words give the same addresses.

In Multi-Account mode MyTonWallet supports importing a BIP-39 seed (12 or 24 words) and applies a SLIP-0010 derive along m/44'/607'/account'. That gives Ledger compatibility but is not compatible with Tonkeeper on the same words.

When you import 24 words into MyTonWallet you are asked to pick a mode — critical moment. “TON mnemonic” = canonical derive (Tonkeeper-compatible); “BIP-39 / Ledger” = SLIP-0010 (different addresses).

Tonhub

Canonical TON standard, compatible with Tonkeeper and MyTonWallet single-account.

Ledger Live + TON app

Ledger uses one shared BIP-39 24-word seed for every coin (Bitcoin, Ethereum, Solana, TON and so on) — a hardware constraint. The Secure Element has no room for a separate TON derive. So Ledger does:

Mnemonic (24-word BIP-39) → seed (BIP-39 derive with salt "mnemonic", 2,048 iterations).
Seed → SLIP-0010 ed25519 master key.
Master key → derive along m/44'/607'/account'.
Resulting private key → Ed25519 keypair → TON address.

This is a completely different path than Tonkeeper. Same 24 words in, different addresses out. The difference is not in one step of the chain, but in the whole chain.

When you connect a Ledger to Tonkeeper over USB, Tonkeeper does not ask for the Ledger mnemonic. Instead it asks the device for the public key along the right path and the Ledger signs transactions on-device. The mnemonic never leaves the Secure Element. More in the guide on connecting Ledger to a TON wallet.

Keystone, GridPlus, and other hardware wallets

Same constraints as Ledger — a shared BIP-39 seed across all coins, SLIP-0010 derive along m/44'/607'/account'. Addresses do not match the Tonkeeper-mnemonic address.

Concrete example: different addresses from the same words

Suppose you have 24 Tonkeeper words:

abandon abandon abandon ... abandon about

(Not a real TON phrase — it would fail first-byte validation — but it illustrates the chains.)

Through Tonkeeper derive:

words → PBKDF2(salt="TON default seed", iter=100000) → seed32
seed32 → Ed25519 keypair → UQA... (address 1)

Through Ledger derive (SLIP-0010):

words → PBKDF2(salt="mnemonic", iter=2048) → seed64
seed64 → HMAC-SHA512("ed25519 seed", seed64) → master_key
master_key → derive_hardened(44') → derive_hardened(607') → derive_hardened(0') → keypair
keypair → UQB... (address 2)

UQA... and UQB... are two different TON addresses derived from the same 24 words. Both valid, both controlled by the phrase owner — but different wallets with different balances.

Migration in practice: moving funds between wallets

If you created a wallet on Ledger and want to migrate to Tonkeeper (not Tonkeeper-in-Ledger-mode, but a “native” Tonkeeper wallet) — re-importing the mnemonic will not work. Different addresses, zero balance on the new one.

The right procedure:

Create a new Tonkeeper wallet with a fresh mnemonic (or use an existing one).
Record the new Tonkeeper address.
In Ledger Live (or in Tonkeeper’s Ledger mode) sign a transfer transaction from the Ledger account to the new Tonkeeper address.
Wait for confirmation, check the balance on the new address.
The old Ledger account can stay empty — it is still controlled by the Ledger, just without funds.

The reverse (Tonkeeper → Ledger) goes the same way: connect the Ledger as a new account inside Tonkeeper and transfer funds from the Tonkeeper mnemonic to the Ledger account through a regular transfer.

The full TON wallet recovery walkthrough covers diagnostic cases where the mnemonic “does not work” because of a standards mismatch.

Passphrase on TON: an extra risk

TON wallets (Tonkeeper, MyTonWallet) support an optional passphrase — an extra password on top of the 24 words. Technically it changes the PBKDF2 derive salt: instead of just "TON default seed", the salt becomes "TON default seed" + passphrase.

That means:

A wallet with an empty passphrase and a wallet with passphrase hello123 are two completely different addresses from the same 24 words.
The wallet cannot be recovered if the passphrase is lost. Unlike BIP-39 (where short passphrases can be brute-forced through a script), the 100,000-iteration TON derive makes brute force impractical even on short passphrases.
The passphrase must be recorded separately from the mnemonic and stored as carefully as the phrase itself.

For larger amounts (>$10K), a passphrase gives real protection against compromise of the physical mnemonic medium. For “spinning around” sums, the passphrase will more likely create loss risk than protect you. See TON cold storage strategies.

Security: TON mnemonic vs BIP-39

By entropy — equivalent. 24 words from the BIP-39 wordlist give log2(2048^24) ≈ 264 bits of entropy minus 8 checksum bits = 256 bits of effective entropy. The same as a 24-word Bitcoin wallet.

By brute-force resistance — TON mnemonic is meaningfully stronger. 100,000 PBKDF2 iterations vs 2,048 on BIP-39 is roughly 50× more work per candidate. If 22 of 24 words are leaked and the attacker needs to find the remaining 2, the BIP-39 case takes hours on a modern GPU; the TON case takes weeks.

By blast radius — worse on TON. In BIP-39 + BIP-44 a single mnemonic generates a tree of billions of addresses, and compromise of one private key (e.g. via an RPC leak) only affects that one address. In canonical TON, one mnemonic = one keypair, so a key compromise compromises ALL of your TON funds under that mnemonic.

That is why secure seed phrase storage practices for TON are even more critical than for Bitcoin — you have no “spare” addresses in an HD tree.

Checklist: things to verify before writing down a seed

Which wallet generated the mnemonic? Tonkeeper / MyTonWallet single-account → canonical TON standard. Ledger / MyTonWallet multi → SLIP-0010.
How many words — 12 or 24? The TON standard is always 24. 12 words = BIP-39 / SLIP-0010 path.
Is a passphrase enabled? If so, recorded separately and verified by recovery test?
What address does the phrase correspond to in the wallet? Write down the first 6-8 characters of the address alongside the phrase — a backup check against “wrong phrase”.
If you plan to use the same mnemonic on a Ledger, verify that both wallets show the same address. If different — that is normal, but log which address came from which wallet.
Run a recovery test on a different device (not the same phone). Importing the mnemonic into a fresh app and comparing addresses is the only proof you wrote it down correctly.

What to read next

If this article clarified the picture, next reads:

Secure seed phrase storage practices 2026 — where to keep the 24 words so they outlive you.
How to recover a TON wallet from a seed phrase — step-by-step, with diagnosis of “does not work” cases.
How to connect a Ledger to a TON wallet — practical focus on Tonkeeper-Ledger integration.
MyTonWallet vs Tonkeeper — comparison 2026 — pick a wallet with mnemonic compatibility in mind.
TON cold storage strategies — multisig, hardware, Shamir for larger amounts.

The main takeaway: 24 words are not an “address” — they are input material for a derive function. Which function gets applied is up to the wallet. Knowing this, you stop panicking when Ledger Live shows the “wrong” balance on your words, and you can pick tools with intent for your security model.