Three ways to load a seed: Pick a tab below. 🤖 generates a fresh random mnemonic, 📥 lets you type one you already have, and 🎲 takes raw entropy from dice / coins / cards. Once a seed is loaded you can add a BIP39 passphrase, and the rest of the toolkit unlocks.

What this does: A seed produces an unlimited tree of addresses. Pick the address style (BIP84 for modern bc1q..., BIP86 for Taproot bc1p..., BIP49 for nested-segwit 3..., BIP44 for legacy 1...) and a list of receive addresses is generated. The account-level xpub can be imported into any compatible wallet to watch-only the same addresses.

What this does: BIP47 lets you share one stable "payment code" instead of generating a fresh address every time. When someone wants to pay you, they paste your payment code into their wallet; both wallets derive a fresh address from the two codes, so each payment still gets its own unlinkable address. PayNym is the same idea with cute robot avatars.

What this does: Multisig requires multiple cosigners to spend. Paste each cosigner's account-level extended public key (Ypub or Zpub) on its own line, set the threshold (e.g. 2 for 2-of-3), and addresses will appear below. If you have a seed loaded, your own xpubs appear at the top - click "Add as Cosigner" to include yourself.

What this does: BIP85 turns one master seed into unlimited deterministic children. Pick an Index (0, 1, 2…) and out comes a fresh 12/18/24-word seed phrase or a random-looking password. The same index always produces the same child, so you only ever need to back up the master.

Power user feature. If you lose the master seed, all children are gone too.

How this works: Roll 5 physical dice for each word in your passphrase. Type the digits (e.g. 14352) into the box below or click Add word to auto-roll. Each 5 dice produces one Diceware word - append as many as you want. Your generated passphrase appears below and is automatically set as the loaded BIP39 passphrase.

How to use: In the Seed Workspace, enter your mnemonic and try a candidate passphrase. Come back here, paste a Bitcoin address you know belongs to that wallet, then click Search. The tool will scan derived addresses from that seed+passphrase to see if the address appears.

Each search can take ~20 seconds. The default derivation path is BIP84 (m/84'/0'/0'/0) - edit it if you used a different scheme.

2-of-3 paper backup: Your seed gets split into three cards. Any two cards combined recover the original. No single card on its own reveals anything. Keep the three cards in different geographic locations for redundancy without single-point-of-failure risk.

All-shares-needed split: XOR your loaded seed with N additional seeds. Each share looks like a valid 12/24-word seed on its own and reveals nothing useful. You need every share to recover the original. This is different from 2-of-3 splitting (where any 2 suffice) - XOR is N-of-N.

What this does: Hamming backups add error-correction codes to a seed phrase so a damaged or partially unreadable backup can still be recovered. The redundancy lets you reconstruct missing or corrupted words from the surviving ones.

How to use: Click NEW KEY to generate a random pad, then ENCRYPT to produce a ciphertext. Store the key and the ciphertext in two different places. To recover, paste both back in and click DECRYPT. If you have both, you get the seed; with either alone, you get nothing.

How to use: The last word of a BIP39 mnemonic isn't random - its first few bits act as a checksum. Type the first 11 (or 17/23) words you already have, then either flip the bit toggles or click Flip the bits to randomize the remaining entropy. The tool figures out which checksum word makes everything valid.

What this does: Paste a single Bitcoin private key (WIF like L1aW… or 64-char hex) and see the corresponding Legacy, Nested SegWit, and Native SegWit addresses. Or switch to multisig mode and paste public keys (one per line) to build a quick m-of-n script address. No seed required.

Why this is better than Seed XOR: XOR requires every share to recover (N-of-N). Shamir lets you set a threshold - any 2 of 3, 3 of 5, etc. Lose one card, you still recover. A single share on its own reveals mathematically nothing.

Three formats, same algorithm:

• SLIP-39 (SatoshiLabs / Trezor): each share is a 20- or 33-word mnemonic from a dedicated SLIP-39 wordlist. Has its own optional passphrase. Supports hierarchical groups (e.g. "any 2 of group A plus any 3 of group B").
• SSKR (Blockchain Commons): shares are compact binary, typically shown as hex or wrapped in UR animated QR codes. No built-in passphrase; the outer container is expected to provide encryption.
• Foundation Shard (Passport Prime): a dCBOR-encoded variant of the same Shamir scheme, designed for NFC KeyCard backups. Byte-for-byte compatible with Passport Prime's Magic Backups.

Shares from one format are not interchangeable with another - pick whichever matches the wallet you intend to recover with.

Why this exists: Most wallets let you add notes - "rent to landlord", "Coinbase deposit", "savings change addr". BIP-329 is the portable JSONL format for moving those labels between wallets. Format:

{ "type": "tx",     "ref": "<txid>",       "label": "Bought pizza" }
{ "type": "addr",   "ref": "bc1q…",            "label": "Donation address" }
{ "type": "xpub",   "ref": "xpub…",            "label": "Savings account" }
{ "type": "output", "ref": "<txid>:0",     "label": "Change", "spendable": true }

Six possible type values: tx, addr, pubkey, input, output, xpub. Full spec on GitHub.

Either upload a .jsonl file exported from your wallet (read locally in the browser, never leaves the device), or paste the contents directly. Both work the same way.

BOLT-11 is the original Lightning invoice format. One-shot, expires quickly, encoded as a long lnbc… string. Decoder shows: amount, recipient node, payment hash, route hints, expiry, description.

BOLT-12 is the modern replacement. Reusable like a BIP-47 payment code, supports recurring payments. Three sub-types: lno1… offers (request to be paid), lni1… invoices, lnr1… invoice requests.

Decoder only - no signature verification, no network calls. Same content you'd see on a Lightning block explorer.

Paste anything from a Bitcoin scripting workflow and the tool will figure out what you gave it:

• Policy - human-friendly form, e.g. or(pk(Alice),and(pk(Bob),older(144))). The compiler picks an efficient Miniscript for you.
• Miniscript - the precise lower form that maps 1:1 to Bitcoin Script. Every expression has a known witness cost and a static safety proof.
• Output descriptor - what wallets actually export: wsh(...), tr(...), sh(wsh(...)). Handles BIP-389 multipath (<0;1>/* or /** shorthand) and validates the #checksum. With real xpubs the tool also derives the first receive + change addresses.

Two script contexts:

• P2WSH (Segwit v0): ECDSA keys, multi(k,…) for multisig.
• Tapscript (Taproot leaf): Schnorr x-only keys, multi_a(k,…) for multisig.

Spend paths show required signers, preimages, and timelocks - with human time on every older(N) / after(N).

Nothing is signed or broadcast - pure offline analysis.

What this does: A PSBT (BIP-174) is the standard format wallets use to coordinate a transaction across multiple signers - hardware wallets, multisig cosigners, watch-only software. It carries the unsigned transaction plus all the UTXOs, signatures, and BIP-32 derivation paths that any signer might need.

This inspector reads but never signs or modifies. Paste a PSBT before signing it elsewhere to confirm exactly what you're about to authorise: which inputs are being spent, where the money is going, what fee you're paying, and which cosigners have already signed.

What this does: BIP-353 puts a Bitcoin payment URI (Silent Payment address, BOLT-12 offer, on-chain address, etc.) into a DNSSEC-signed DNS TXT record. Senders type name@domain into their wallet, the wallet looks up the record, follows the URI, and pays.

Offline note: The resolution step (DNS lookup + DNSSEC validation) needs the internet. This tool only handles what's offline: building the URI + TXT record to publish, and decoding the URI value once you have it. Run the actual lookup in a connected wallet.

What this does: BIP-352 lets you publish one static address that anyone can pay you at, with each payment going to a fresh unlinkable Bitcoin address on-chain. Your "scan key" lets you find incoming payments; your "spend key" lets you spend them. Both are derived from your seed at standard paths.

Use the tabs below to generate your address, inspect someone else's, send a payment, compare to BIP-47, or read about how it works.

How to use: Type each word you have. Click a word to mark it typo (probably right but maybe wrong) or unknown (no idea - try every possibility). Add an address you know belongs to that wallet if you have one - it lets the tool tell a real match from millions of valid-looking-but-wrong candidates.

For non-word inputs (entropy hex, binary, or wordlist indexes), switch to the matching mode at the top.

Why this exists: Exchanges, custodians, and audit firms routinely ask "sign this message to prove you control this address." It's the standard way to prove ownership of Bitcoin without spending from it.

Two standards: BIP-137 is the original (works with legacy 1... and 3... addresses). BIP-322 is the modern replacement that works with any address type including SegWit (bc1q...) and Taproot (bc1p...).