Three seed formats walk into a converter. One accepts a 12-word mnemonic, the second expects 20-word Shamir shares with an RS1024 checksum, and the third insists on a version tag of 100 or 101 — and the bridge has to figure out which one you typed before it can do anything useful. The SLIP-39 / BIP-39 / Electrum Seed Bridge keeps that detection in a single offline pass, then runs BIP-39 checksum validation, SLIP-39 Shamir recombination, and Electrum version-tag parsing on the same input box — and emits the BIP-32 master key plus the first five m/44'/0'/0'/0 addresses from whatever format survived the triage.
The walk-through below covers the eight things every wallet migration hits in practice: why the three formats exist side-by-side, how the auto-detect path actually decides, where the entropy boundaries sit, what happens when you cross from a 12-word BIP-39 into a 2-of-3 SLIP-39 share set, and the four failure modes that look like valid input but reject on the back end.
Why Three Seed Standards Coexist
The BIP-39 wordlist ships with 2048 English words and a checksum that catches a single-word typo before any PBKDF2 round fires. It is the lingua franca of consumer hardware wallets — Trezor, Ledger, Coldcard, and every mobile wallet that imports via 12 or 24 words. SLIP-39 sits beside it because Shamir’s Secret Sharing is the only mature answer to “what if one of my recovery sheets gets stolen” — a single 12-word sheet from a 2-of-3 set is mathematically inert, and recovering the master seed requires the threshold. For the polynomial-arithmetic primitives underneath SLIP-39, the standalone Shamir Secret Sharing tool covers the threshold scheme in isolation. Electrum predates BIP-39 by three years and uses a 100/101 version-tagged seed that looks superficially similar but routes through a different seed-stretch function, so its words are not interchangeable with BIP-39 even when the wordlist looks identical.
The bridging problem shows up the moment you migrate from one vendor’s stack to another. A Trezor Model T outputs BIP-39 natively; if you back that up with SLIP-39 shares via Trezor’s advanced backup, you now have two seeds representing the same entropy. Electrum Desktop users with a pre-2018 wallet have a version-100 seed that won’t import into modern BIP-39 wallets without manual conversion. The bridge tool reads any of those three and emits the matching native form, which makes it useful for migrations, recovery drills, and the occasional forensic audit.
How Auto-Detect Triages The Input Box
Detection runs four cheap signals before it touches any cryptography: word count, leading word uniqueness, version-tag prefix, and Shamir share-set structural rules. Twelve lowercase English words from the BIP-39 list with a valid last-word checksum is almost certainly BIP-39. Twenty or thirty-three words with member indices, group threshold, and group index fields is SLIP-39. Eleven or thirteen words prefixed by the literal string 100 or 101 is Electrum. Hex strings of 32, 48, or 64 characters route to entropy mode regardless of the surrounding label — for a sanity check on whether the underlying randomness has enough bits to support a 256-bit seed, the Entropy Calculator reports Shannon entropy per byte before you commit to a derivation.
The mode selector lets you force any of those branches — useful when a script-generated input is technically valid BIP-39 but you specifically want SLIP-39 share generation, or when an Electrum seed has the version tag inside the word string rather than as a separate prefix. Auto-detect stays the default because it is the only path that catches the “I exported a hex entropy block and pasted it where a mnemonic should go” mistake.
What The Validation Surface Actually Checks
For BIP-39, the bridge confirms the wordlist membership of every word, computes the SHA-256-based checksum from the first 256 minus N bits of entropy, and rejects with a one-line diagnostic if the last word does not match. The output table then prints the recovered entropy in hex, the full 128-or-256-character seed after the PBKDF2-HMAC-SHA512 stretch with the chosen passphrase, the BIP-32 master xprv and xpub, and the first five receive addresses on m/44'/0'/0'/0. All five addresses derive deterministically from the same seed, so a regression test on any of them is sufficient to confirm the input was processed correctly.
For SLIP-39, the bridge parses each share line into member index, group threshold, group index, member threshold, share value, and the RS1024 checksum. A 2-of-3 single-group set recombines by computing the Lagrange interpolation polynomial at the secret point and emitting the recovered entropy; the bridge then re-encodes that entropy as a fresh BIP-39 mnemonic so the user can drop the recovered seed into any standard wallet. A multi-group set reports the recovered entropy per group and stops short of cross-group recombination unless the user explicitly asks for it — a security boundary the documentation calls out because cross-group recovery is a different threat model from a single trusted group.
For Electrum, the bridge checks the version tag (100 for legacy Segwit, 101 for legacy), validates the version-tagged checksum, and either confirms the seed or rejects it with the specific byte offset where the checksum diverged. The Electrum path is read-only; converting an Electrum seed back into BIP-39 requires running the recovered seed through the BIP-39 encoding, which the bridge does as a secondary step when the mode is set to auto and the input was Electrum.
Crossing From BIP-39 Into SLIP-39 Without Losing Entropy
The migration flow that catches most people off guard is the reverse direction: you already have a BIP-39 mnemonic, and you want a 2-of-3 SLIP-39 backup instead of the 24-word sheet. The bridge handles this by recovering the entropy from the BIP-39 mnemonic, verifying that the checksum agrees, then running the SLIP-39 share-generation routine on that recovered entropy. The two share sets encode the same entropy, so any single share pair reconstructs the original BIP-39 mnemonic, which reconstructs the original master seed.
The gotcha is the iteration exponent. SLIP-39 defines three iteration counts — 2500, 5000, and 10000 PBKDF2 rounds — and Trezor defaults to 10000 (exponent 2). If you split your seed at exponent 0 (2500 rounds) and try to recover on a Trezor that defaults to 2, the device will reject the share set even though the entropy is correct. The bridge exposes the iteration exponent as an explicit option precisely so the round count matches the recovery device. Mismatched exponents are the single most common “the shares don’t work” report.
Where The Checksum Boundary Lives
The BIP-39 checksum is 3 bits for a 12-word mnemonic and 8 bits for a 24-word mnemonic — small enough that an attacker who tries random last-words has roughly a 1-in-8 or 1-in-256 chance of forging a valid checksum, but large enough that a single honest typo at the end of your recovery sheet is caught immediately. SLIP-39 uses an RS1024 codeword inside each share, which is a much stronger error-detection layer: any single share from a 2-of-3 set can be checked independently before you commit to recombining, and the RS1024 surfaces bit-level damage that a BIP-39 checksum would silently let through. For a closer look at how RS1024 sits alongside lighter-weight checksums like CRC32, the CRC32 Checksum tool documents the polynomial-arithmetic side of the same problem class.
Electrum’s version-tagged checksum is a different beast again — it is essentially a small custom checksum that ties the version prefix to the seed words, and it has been a source of cross-wallet compatibility bugs for over a decade. The bridge’s Electrum path treats any version-tag mismatch as a hard reject, which is the safer default for a tool whose output is going to be trusted with real funds.
The Four Failure Modes That Look Like Valid Input
The bridge rejects on four patterns that are easy to miss when you are pasting seed material between wallets: an Electrum seed that has the version tag in the wrong case (100 works, 0100 does not), a SLIP-39 share set where one share’s member threshold is 0, a BIP-39 mnemonic that mixes BIP-39 English words with Electrum’s overlapping but distinct wordlist (the two lists share roughly 80 percent of their words), and a hex entropy input whose length is not exactly 32, 48, or 64 hex characters. Each of these produces a single-line rejection with the specific check that fired, which makes debugging a malformed input tractable without a code review.
The fifth silent failure mode is a passphrase mismatch. BIP-39, SLIP-39, and Electrum all support an optional passphrase — the “25th word” or “hidden wallet” feature — and a single-character difference produces a completely different master seed. The bridge always shows the passphrase it used in the recovered-material table so you can confirm the input matched; if your wallet shows one set of addresses and the bridge shows another, the passphrase field is the first place to look.
Why Offline Matters For This Category
Every operation in the bridge — BIP-39 checksum, PBKDF2 stretch, BIP-32 derivation, SLIP-39 RS1024 verification, Shamir recombination — is deterministic from the input alone, which means it can run without any network access. The browser-based implementation reads your input and produces the report entirely client-side, which is the only deployment shape that lets a recovery drill happen on an air-gapped laptop without leaking seed material to a remote log or a third-party API.
The bridge validates against the canonical Trezor test vectors: the 12-word mnemonic abandon × 11 about with passphrase TREZOR should produce master xprv9s21ZrQH143K3h3fDYiay8mocZ3afhfULfb5GX8kCBdno77K4HiA15Tg23wpbeF1pLfs1c5SPmYHrEpTuuRhxMwvKDwqdKiGJS9XFKzUsAF and first address 1EqUzSw8LKertj193fGu4GQhEdRzNSsbgB. Running that test vector through the bridge on a fresh install is the most reliable way to confirm the input is being processed correctly before you trust the tool with a real wallet — every cryptographic step in the chain is exercised end-to-end, and any deviation in the output points to a corrupted dependency or a wrong wordlist path.
The Three-Line Migration Routine
The migration workflow becomes a three-line routine once the bridge is part of the toolkit: paste the existing seed, confirm the recovered entropy matches an offline-known value, and generate the new format’s shares or mnemonic. The Trezor advanced backup flow, the Ledger-to-Electrum migration path, and the Coldcard seed-import scenario all collapse to the same shape — a single paste, a single recovered table, a single deterministic output. For anyone holding seed material across more than one vendor’s stack, that collapse is the entire reason the tool exists.
Explore more wallet and key-management utilities at elysiatools.com.
