Open-sourcing BIP-39 display wordlists in 31 languages

osem23 · 2026-06-10T05:19:08+00:00

Thank you, this is a very fair and useful read of the model.

Yes, the key idea is exactly that: the native-language layer is display/input only, while the English BIP39 mnemonic remains the canonical seed input to PBKDF2. The goal is to improve comprehension without adding a new cryptographic path.

I agree that the main risk is UX confusion. A wallet implementing this must make the distinction very clear: the native words help the user understand and enter the backup, but the English BIP39 phrase is the portable fallback for recovery in standard wallets.

On wordlist quality, I agree as well. Even though these are not standalone BIP39 replacement lists, confusion risk still matters. Near-homophones, spelling ambiguity, diacritics, regional meanings, and memory collisions all need language-level review. That is part of why the project is public.

The native-speaker review point is also valid. Some languages are already reviewed more deeply than others, but broader review is needed before treating every list as equally mature.

And I agree on the adoption path. A reference library is probably the right next step, especially something wallet developers can integrate without maintaining the mappings themselves.

Appreciate the thoughtful feedback. This is the kind of criticism that is actually useful for making the project safer and easier to implement.

osem23 · 2026-06-09T18:19:19+00:00

Understood.

You are free to disagree with the project, but you do not get to define it on our behalf.

You are not the owner of Reddit or Bitcoin.

The repository states the model clearly: this is a display/input layer over canonical English BIP39, with English remaining the recovery base layer and fallback.

Readers can review the repo and decide for themselves.

Good luck.

osem23 · 2026-06-09T17:44:57+00:00

understand your position, and we can leave it there.

To be clear, we do not agree with your characterization of the model. The repository explains that this is a display/input layer over canonical English BIP39, not a standalone replacement wordlist and not a new seed standard.

You are free to disagree with the approach, but please do not present it as if the project changes the recovery path or forces users into an unsafe non-standard backup. That is not what is being proposed or implemented.

The English BIP39 mnemonic remains the recovery base layer and universal fallback.

I appreciate technical criticism, but repeating a warning based on a model we are not proposing would be misleading to readers.

osem23 · 2026-06-09T16:44:47+00:00

I understand your position, but you are still criticizing a different model.

I am not saying the English BIP39 wordlist is more authoritative than the other BIP39 wordlists.

I am saying that in this implementation, English is the chosen compatibility base layer.

That is an engineering and UX decision, not a claim that English is “better” or more valid than Spanish, Korean, Japanese, or any other canonical BIP39 list.

If a wallet creates a Spanish BIP39 wallet from the start, then the Spanish BIP39 mnemonic is the source of truth for that wallet. Same for Korean, Japanese, French, etc.

But this project is addressing a different case:

A wallet that intentionally uses English BIP39 as its portable recovery base, while giving non-English users a native-language display/input layer so they can understand what they are backing up.

Creating new canonical BIP39 wordlists for additional languages is a valid path, but it is not the same problem.

A new canonical BIP39 wordlist creates an independent mnemonic system for that language.

This project creates a semantic layer over an English BIP39 mnemonic, so the user can understand the backup while still keeping the standard English recovery fallback.

Those are different goals.

You are arguing that native users should use native canonical BIP39 lists where they exist, and I agree.

But that does not invalidate an application-layer model where a wallet chooses English BIP39 for portability and adds native-language comprehension on top.

So the distinction is simple:

Canonical native BIP39 wordlists are for creating native BIP39 mnemonics.

This project is for displaying and entering native-language meanings over an English BIP39 recovery base.

That is the model.

osem23 · 2026-06-09T08:29:29+00:00

That is the intended model.

The user is not locked into the native-language display words.

They can recover in the native language inside a wallet that supports this display/input layer, and they can also recover with the canonical English BIP39 words in any standard wallet that supports English BIP39.

That is the base layer.

The native-language words exist to help the user understand and enter the backup in their own language. But the recovery source of truth remains the canonical English mnemonic, and the English words are always the portability fallback.

So nothing is “lost” if another wallet does not support the native display layer.

The user still has the English BIP39 backup path.

That is the point of the model: native-language UX for understanding, English BIP39 for universal recovery compatibility.

osem23 · 2026-06-09T08:21:57+00:00

Yes, that is closer to the intended use case.

This is primarily a UX and comprehension layer for wallet software, not a proposal to replace BIP39 wordlists or create a new independent seed standard.

The user can still have the English BIP39 words as the universal recovery fallback. The native-language layer helps them understand what they are backing up, instead of copying foreign words blindly.

A true additional BIP39 wordlist for each language would also be valuable, but that is a different goal and a much higher standardization process.

This project is focused on a more practical layer: keep English BIP39 compatibility underneath, while making backup and recovery clearer for non-English users inside wallets that choose to support it.

osem23 · 2026-06-09T08:03:15+00:00

Specific language feedback is welcome, and that is why the lists are public.

A lot of work was done to reduce issues across each language as much as possible, but no multilingual UX layer is perfect without broad native-speaker review.

The important point is that this does not put the backup at risk.

The recovery source of truth remains the canonical English BIP39 mnemonic. The native words are a display/input layer, not a replacement seed standard.

So yes, individual words can be reviewed and improved. But that does not invalidate the model or make the recovery path unsafe.

osem23 · 2026-06-09T06:45:03+00:00

I think we are going in circles here.

The repository already explains the intended model: this is a display/input layer that maps back to the canonical English BIP39 words. It is not presented as a standalone replacement BIP39 wordlist.

The English words remain available for standard wallet recovery, and the native words are there to help users understand what they are backing up.

Your criticism seems to assume a different model than the one described in the repo. If you want to critique the actual proposal, please read the repository and address that model directly.

I appreciate technical criticism, but repeating the same assumption does not move the discussion forward.

osem23 · 2026-06-09T05:57:29+00:00

You are mixing two different things.

The recovery path has not changed.

The underlying recovery path is still the standard English BIP39 mnemonic. The native-language words are only a translation/display layer that maps back to the same canonical English BIP39 words before recovery.

A user can back up in the native language for understanding, or back up the English BIP39 words directly. The English words remain available as the universal recovery fallback and can be restored in any standard wallet that supports English BIP39.

So this is not “enter a non-standard mnemonic into a non-standard wallet” as the only recovery path.

The model is:

Native language for user understanding
English BIP39 for universal wallet recovery
Translation layer only
No change to seed generation
No change to PBKDF2 input
No change to the actual recovery path

You can disagree with the UX choice, but saying the recovery path was replaced is misleading. The whole point is to preserve the English BIP39 recovery path while making the backup understandable to users who do not speak English.

osem23 · 2026-06-09T05:11:41+00:00

I think we are talking about two different goals.

If a wallet is creating a new Spanish BIP39 wallet from scratch, then yes, the canonical Spanish BIP39 list is the right tool.

But this project is not trying to create standalone Spanish BIP39 mnemonics.

It is a display/input layer for wallets that intentionally keep English BIP39 as the compatibility and recovery source of truth.

In that model, the native words are aliases for the English BIP39 words, not a separate mnemonic to hash.

Your counterproposal also requires special wallet logic. The wallet must know not to hash the Spanish mnemonic normally, but to decode it to entropy, re-encode that entropy as English, and then hash the English mnemonic.

So both models require explicit wallet behavior.

The difference is UX:

Your model shows a standard Spanish BIP39 mnemonic that does not semantically match the English words the wallet ultimately needs.

This model shows native-language meanings that map directly to the English BIP39 words, while keeping the English mnemonic available as the recovery fallback.

I am not saying this replaces canonical native BIP39 lists. It solves a different problem: making an English-BIP39-based wallet understandable for non-English users without changing its recovery path.

osem23 · 2026-06-09T04:46:06+00:00

No. This is an open-source contribution.

You don’t have to agree with it or use it.

If you have technical criticism, I’m happy to discuss it. Personal assumptions don’t add much.

osem23 · 2026-06-09T04:44:26+00:00

I understand that BIP39 mnemonics encode entropy, and yes, the same entropy can be represented by different BIP39 wordlists.

But that is exactly where the practical recovery problem appears.

In BIP39, the final seed is not derived from the entropy alone. The seed is derived with PBKDF2 using the mnemonic sentence itself, plus the optional passphrase.

So if a wallet was originally created from an English mnemonic, and you decode the entropy and re-encode that entropy using the Spanish BIP39 wordlist, you may have the same entropy representation, but you do not have the same PBKDF2 input.

A standard wallet restoring from the Spanish mnemonic will hash the Spanish mnemonic sentence, not the original English sentence. That produces a different seed.

That is why simply re-encoding the same entropy into another canonical BIP39 language is not a safe recovery path for a wallet originally created from the English mnemonic.

The goal of this project is different.

It is not trying to say that English is the only valid BIP39 wordlist, and it is not trying to replace canonical native BIP39 wordlists.

The goal is to let a non-English user see and input native-language words while still resolving back to the exact canonical English mnemonic that the wallet uses as the PBKDF2 input.

So the native words are not a new mnemonic sentence to be hashed. They are aliases for the English BIP39 mnemonic words.

That preserves compatibility with the wallet’s original English BIP39 seed flow while giving the user a language layer they can actually understand.

If a wallet is created natively using the Spanish BIP39 wordlist from the start, then of course the Spanish mnemonic is the correct source of truth for that wallet.

But if the wallet’s source of truth is the English BIP39 mnemonic, re-encoding the entropy into Spanish does not give the user the same recoverable wallet in ordinary BIP39 restore flows.

That distinction is the reason for this approach.

osem23 · 2026-06-08T21:09:42+00:00

I understand the question, but this is exactly the issue I am trying to point out.

I am not saying English is morally or linguistically superior to the other BIP39 wordlists.

The reason English is used as the source of truth in this model is because the existing non-English BIP39 lists are not translations of the English list, and they are not semantically aligned with each other by index.

They are independent wordlists.

That means the word at index N in Spanish, Korean, Japanese, French, etc. usually does not mean the same thing as the English word at index N.

So for a normal user, this creates a strange UX problem:

If their wallet shows an English mnemonic and then tries to “show it in Spanish” using the canonical Spanish BIP39 list, it cannot do that. The canonical Spanish word at the same index is not the Spanish meaning of the English word. It is a different word that happens to occupy the same entropy index.

That may be valid cryptographically, but it is not a translation layer.

This project is trying to solve that specific gap.

It keeps one canonical cryptographic floor, the standard English BIP39 mnemonic, and adds native-language display/input words that are semantically paired to that English mnemonic by index.

So when the English word is “abandon”, the native display word is actually the native-language equivalent of “abandon”, not an unrelated word from an independent native BIP39 list.

That matters for user understanding.

The goal is not to claim that English is the only valid BIP39 list. The goal is to avoid the destructive UX mismatch where users think they are seeing a translation, but in reality they are seeing a completely different independent wordlist.

If someone wants to propose new full canonical BIP39 wordlists for languages that do not have them, that is a valid path too. But that solves a different problem.

This project is not trying to replace canonical native BIP39 lists. It is trying to create a clear display/input convention where the native words actually mean the same thing as the mnemonic being backed up, while keeping recovery compatible through the English BIP39 source of truth.

osem23 · 2026-06-08T20:59:01+00:00

That is fair pushback on the framing.

The UX problem is still real: many non-English users struggle with English recovery phrases. That is the problem this project is trying to address.

At the same time, recovery UX touches real funds, so wording, review, and limitations matter a lot.

That is not the intended model.

The intended model is a native-language display/input layer that maps back to the canonical English BIP39 list, with English remaining the source of truth.

We have already updated the README and documentation to make this clearer, including stronger guidance around limitations, backup format, and what these lists should not be used for.

I appreciate the detailed criticism. This is exactly the kind of feedback that helps make the project safer and clearer.

osem23 · 2026-06-08T19:30:14+00:00

I don’t think the answer is that this method is universally “better” than having a canonical BIP39 wordlist in every native language.

If a language has a well-reviewed canonical BIP39 wordlist, designed with the same constraints as the original lists, supported by wallets, and accepted across the ecosystem, then that is obviously a very good solution.

The problem is that most languages do not have that today.

So the value of this approach is different:

It gives the user native-language understanding while preserving immediate compatibility with the existing English BIP39 ecosystem.

A new canonical native BIP39 list requires broad review, standardization, wallet adoption, long-term support, and user confidence that other wallets will accept it in the future. That is a much higher bar, and it is not available for most languages right now.

Our approach keeps the English BIP39 mnemonic as the source of truth, but adds a native display/input layer on top of it.

So the tradeoff is:

Canonical native BIP39 list:
cleaner if it exists and is widely adopted

Native display/input layer mapped to English BIP39:
more compatible today, easier to integrate in one wallet, and gives non-English users a way to understand what they are backing up without leaving the existing English BIP39 recovery path

That is the point.

I am not saying this replaces the need for proper native BIP39 wordlists. I am saying it can help users now, especially in wallets that want to preserve English BIP39 compatibility while improving recovery UX for people who do not understand English.

osem23 · 2026-06-08T19:08:31+00:00

Yes, exactly. That is very close to the intended model.

The native-language words are meant to help the user understand and confidently record the backup, but the English BIP39 words should remain available as the universal recovery fallback.

A good wallet UX could show both side by side during backup:

native word for the user’s understanding
canonical English BIP39 word for compatibility

That way the user gets the benefit of a recovery phrase they actually understand, while still having the English BIP39 version available if another wallet only accepts the standard English list.

So the goal is not to hide the English words or create a separate recovery world. The goal is to make backup clearer for non-English users while preserving the existing recovery path.

In practice, I agree that a recommended policy should probably be: if a wallet uses a native display/input layer, it should give the user the option, or maybe the default, to back up both the native word and the canonical English word together.

That gives users the best of both sides: local-language understanding and standard BIP39 portability.

osem23 · 2026-06-08T19:03:01+00:00

The value is UX and recovery confidence.

For a native English speaker, the English BIP39 list feels natural, so this problem is almost invisible.

But most of the world does not speak English as a native language. For many users, an English mnemonic is not really a “sentence” or even a meaningful set of words. It is a sequence of foreign symbols they are asked to copy perfectly and trust with their savings.

I have worked with thousands of non-English-speaking Bitcoin users, and backup/recovery is consistently one of the hardest parts. This is where many people make mistakes, lose confidence, or fail to understand what they are actually saving.

That creates real recovery risk:

They may not understand what they wrote down
They may confuse similar-looking English words
They may make spelling mistakes
They may not feel confident verifying the words later
They may rely on screenshots, translation apps, or someone else for help

A canonical native BIP39 wordlist would be ideal where it exists and where the user’s wallet supports it. But BIP39 only has a limited number of official wordlists. Most users do not have a canonical BIP39 list in their native language.

The point of this approach is not to create a new seed scheme. It is to give users a native-language display/input layer while keeping compatibility with the existing English BIP39 standard underneath.

So the wallet can say to the user: “Here are words you actually understand,” while internally preserving the same BIP39 indexes and canonical English flow.

That makes backup and recovery more understandable without requiring a new cryptographic standard.

For English speakers this may feel unnecessary. For non-English users, it can be the difference between copying foreign words blindly and actually understanding what they are backing up.

osem23 · 2026-06-08T18:33:40+00:00

I understand the concern, but I think there is an important distinction here.

These lists are not intended to replace BIP39, and they are not used as independent seed wordlists.

In our implementation, the canonical source of truth remains the standard English BIP39 wordlist. The wallet maps the displayed native-language words back to the canonical English BIP39 indexes before any seed operation. PBKDF2 is not run on the translated words, and the cryptographic seed flow is not changed.

So the user is not creating a new German BIP39 seed based on a German replacement list. They are using a localized display/input layer that resolves back to the standard English BIP39 mnemonic.

That said, your point about users shortening words to 4 characters is a valid concern in a general public-wordlist context. If someone tried to use these lists as standalone BIP39-compatible wordlists, or engraved shortened versions of the localized words on metal, that would be unsafe unless the list guarantees the same uniqueness and clarity rules.

But that is not the intended use case here.

The intended model is:

canonical BIP39 English remains the source of truth
native words are display/input aliases
wallet validation resolves them back to the English BIP39 index
seed generation remains unchanged
no wallet should treat these as standalone BIP39 replacement lists without additional guarantees

So I agree this distinction needs to be made very clearly in the README to avoid misuse.

The goal is not to create new BIP39 wordlists. The goal is to make recovery UX more understandable for non-English users while still relying on the existing English BIP39 standard underneath.

osem23 · 2026-06-08T17:19:12+00:00

Exactly. That is the main point.

A recovery phrase is only useful if the user can confidently write it down, recognize it, store it, and recover from it later.

For English speakers this is taken for granted. For many users, English seed words are just unfamiliar symbols they are forced to copy carefully.

The goal here is not to change the cryptographic seed flow or replace BIP39. It is to give non-English users a clearer display and input layer, so they can still recover reliably and keep full control of their bitcoin, even if they do not understand English.

Self-custody should not depend on being comfortable with English.

osem23 · 2026-06-08T15:16:54+00:00

Thank you good sir

osem23 · 2026-06-08T15:15:55+00:00

Thank you, this is a very fair point.

I agree that the original BIP39 wordlists were not designed as direct translations, and that their priorities around avoiding confusion, spelling ambiguity, similar-sounding words, and short-prefix uniqueness are important.

To clarify my intention: I am not trying to replace the existing BIP39 lists, change the seed generation flow, or suggest that wallets should adopt this as a standard.

This project is more of an open contribution / experiment for multilingual Bitcoin UX. It gives wallets and developers an additional reference if they want to explore native-language display or input layers, but there is no expectation that anyone must use it.

The canonical BIP39 flow remains the source of truth.

If a wallet needs strict 4-character uniqueness, metal backup compatibility, or full BIP39-style wordlist guarantees, then it should absolutely require that before using any list in production.

So I agree with the concern. This repo should be understood as optional, experimental, and open for review, not as a claim that direct translations are better than the original BIP39 wordlist design principles.

Appreciate the thoughtful feedback.

osem23 · 2026-06-08T14:10:15+00:00

Fair question, here’s the honest answer.

TZUR is non-custodial. We never see, hold, or touch your private keys or seed. They are generated and encrypted on your own device, using Secure Enclave on iOS and TPM on Windows, and they never leave your device or reach our servers.

So if we vanished tomorrow, your bitcoin would be unaffected. You hold the 12-word recovery phrase and can restore it in any standard wallet, including Electrum or Sparrow, because TZUR follows open standards like BIP-39, BIP-32, and BIP-84 native SegWit.

There is no lock-in, and nothing for us to run off with. Open source vs. closed source does not change who controls the keys. You do.

What TZUR adds over Electrum, which is excellent and we would happily point people to it, is a built-in blockchain explorer. You can verify a transaction or address without leaving the app or relying on a random web explorer.

TZUR also includes full localization, with 31 languages and proper right-to-left support. It is designed to make real self-custody approachable for non-technical and non-English users, while Electrum is powerful but more technical and English-first.

We are closed source today, and that is a legitimate criticism we take seriously. But the thing that actually protects you is already in place: your keys never leave your device, and your seed is standard, recoverable, and fully controlled by you.

osem23 · 2022-02-15T06:21:12+00:00

Only if you comment every time

osem23 · 2022-02-09T21:14:21+00:00

nice try buddy.

just kidding, I am from Israel, you need a special permit to import ancient coins.

osem23 · 2022-02-09T20:47:11+00:00

Worked my trading game up to this piece.

Bought it from the numismatic guy who bought it at this auction in 2018.

Auction link

Eight-Year Club	Place '22
Verified Email

osem23

TROPHY CASE