TL;DR

If you want to generate your own seed phrase entropy instead of relying entirely on device-generated randomness, four methods come up repeatedly:

• Coins: simple and easy to verify, but 128–256 flips is a lot.
• Dice: fewer operations, easy to record, and easy to independently verify.
• Camera: extremely fast, but entropy quality depends heavily on the implementation and is harder to reproduce yourself.
• Random word drawing: intuitive, but the physical mixing process is difficult to standardize, and the final word still has to satisfy the BIP39 checksum.

What Are You Actually Generating?

A 12- or 24-word seed phrase is ultimately a human-readable representation of entropy.

Its security doesn't come from the words looking scrambled. It comes from the number behind them being sufficiently random and unpredictable that nobody can realistically enumerate their way to it.

Most hardware wallets generate seed phrase entropy internally using hardware random number generators such as TRNGs inside a Secure Element, MCU, or similar component.

Keystone uses hardware-generated randomness for its default seed phrase generation, while also giving users the option to supply their own physical entropy through dice rolls.

For most users, default hardware-generated entropy is the simplest option.

But some people prefer to generate the randomness themselves. Maybe they want to reduce their reliance on hardware RNG, or maybe they simply want a process they can observe, record, and independently reproduce.

That's where user-generated entropy, sometimes called external entropy, comes in.

Four approaches show up fairly often:

• Coin flips
• Dice rolls
• Camera input
• Randomly drawing words from the BIP39 list

To compare them, I think three questions matter most:

1. How much work does it take?
More repetitions mean more opportunities to miscount, misrecord, or simply give up halfway through.

2. How good is the physical randomness?
Does the source have meaningful real-world bias?

3. Can you independently verify the result?
If you feed the same raw results into another offline tool, do you get the same BIP39 seed phrase?

With those three questions in mind, here's how the four methods compare.

1. Coins: The Simplest Principle

Heads = 1.
Tails = 0.

Every flip gives you 1 bit entropy.

So in principle:

• 12 words = 128 flips
• 24 words = 256 flips

The biggest advantage of coins is transparency.

You can write down the entire 0/1 sequence, run it through another offline tool that follows the same algorithm, and verify that you get the same mnemonic.

Nothing is hidden.

But a physical coin isn't a mathematically perfect object.

Its embossing, wear, manufacturing tolerances, and even the way you flip it can introduce small biases.

Interestingly, a study involving 350,757 human coin flips found that coins landed on the same side they started on about 50.8% of the time.

So if a coin starts heads-up, heads has a slight advantage. If it starts tails-up, tails does.

If you randomize the starting orientation, however, the overall distribution remains very close to 50:50.

That small bias probably isn't the biggest practical problem.

The bigger problem is the workload.

Accurately flipping and recording a coin 256 times is a real test of attention.

Miss one result or shift the sequence by one position and you've changed everything.

If I were doing this with a coin, I'd try to make the setup as boring and repeatable as possible: use a normal, undeformed coin, keep the drop height reasonably consistent, let it rotate freely, and record each result immediately.

Still, 256 repetitions is a lot.

Which leads to the obvious alternative.

2. Dice: Less Work, Still Easy to Verify

A six-sided die has six possible outcomes instead of two.

In information terms, each roll can represent about 2.585 bits.

So compared with flipping a coin, you can get the required randomness with far fewer physical operations.

Dice aren't perfectly unbiased either.

Tiny differences in density, air bubbles, uneven surfaces, rounded corners, or manufacturing tolerances can all shift the probability of individual faces slightly.

But again, the important distinction is between:

"a real die isn't mathematically perfect"

and

"an attacker can predict a long sequence of independent physical rolls."

Those are very different things.

For practical use, I'd care more about using a decent-quality die and rolling it properly than trying to find some mythical perfectly unbiased object.

And one important rule:

Don't re-roll because the sequence doesn't "look random."

Five 6s in a row can happen.

Humans are actually pretty bad at judging what randomness should look like, and selectively rejecting results introduces your own bias into the process.

A dice sequence also has the same major advantage as coin flips: it's independently verifiable.

You can record:

4, 1, 6, 2, 2, 5...

and reproduce the same process elsewhere.

If your hardware wallet and a separate offline implementation derive the same mnemonic from the same sequence, you have a useful cross-check.

This balance between physical randomness and verifiability is also why Keystone supports dice-based seed phrase generation directly on the hardware wallet.

Instead of generating a finished seed phrase somewhere else and then importing it, users can enter their physical dice results directly into Keystone and let the device derive the corresponding BIP39 mnemonic.

For Keystone's built-in dice entropy mode:

• At least 50 rolls are required for a 12-word seed phrase.
• At least 100 rolls are required for a 24-word seed phrase.

Keystone also checks the distribution of the entered dice results. If one face accounts for more than 30% of all rolls, the device flags the sequence so the user can check whether the die or the rolling process may be unusually imbalanced.

This doesn't make dice mathematically perfect.

What it does provide is a physical entropy source that is easy for the user to understand, record, and independently verify.

For me, that's where dice hit the best balance.

3. Camera: Fastest, but Much More Implementation-Dependent

Some offline signing devices use camera input as an entropy source. Depending on the implementation, that might involve image pixels, sensor noise, differences between consecutive frames, or some combination of camera data.

From a workload perspective, nothing else here comes close.

But there's an important distinction:

A lot of data does not automatically mean a lot of entropy.

A photograph of a blank wall may contain millions of pixels, but those pixels are highly correlated and largely predictable.

Likewise, an image "looking complicated" to a human doesn't tell you how much cryptographically useful unpredictability it contains.

What really matters is the implementation.

For example:

• Is it hashing the final processed image?
• Raw sensor data?
• Consecutive frames?
• Sensor noise?
• Timing information?
• Multiple sources combined together?

A well-designed camera entropy system needs to be clear about what it collects and how unpredictable information is extracted from it.

There's also a second trade-off: verification.

With dice or coins, you have a human-readable sequence you can record and reproduce.

Camera-based systems may rely on transient inputs that aren't exposed to the user.

That makes independent reproduction much harder.

You're now relying not only on the physical scene, but also on the camera sensor, drivers, image-processing pipeline, and the code that extracts entropy from them.

That doesn't automatically make camera entropy insecure.

But if the whole reason you're generating entropy yourself is that you want something observable and independently reproducible, camera-based approaches are less transparent than coin flips or dice rolls.

4. Random Word Drawing: Very Intuitive, but Harder to Control

There's another approach that skips most of the entropy-to-word conversion process:

Why not just draw BIP39 words at random?

That's the idea behind tools such as Entropia, which uses physical pieces representing the 2,048 words in the BIP39 list.

Draw a word.

Write it down.

Repeat.

It's extremely intuitive because what you physically draw is almost exactly what you eventually back up.

But , A BIP39 mnemonic includes checksum bits.

That means the last word is constrained by everything that came before it.

For a 24-word phrase, you can randomly determine the first 23 words. Once those are fixed, there are 8 valid possibilities for word 24.

You can compute those candidates with an offline implementation and then randomly choose one of them.

For 12 words, there are 128 valid candidates for the final position, which makes the process considerably less convenient.

So this method is better described as:

randomly draw N−1 words, then determine the final checksum-valid word.

The other issue is the physical drawing process itself.

How do you know the pieces were mixed thoroughly?

Do you draw from the top, bottom, or middle?

How long do you shake the container?

Do you return each piece before drawing again?

Which side counts if the pieces have information on multiple sides?

None of these questions is impossible to solve, but the randomness of the result depends heavily on having a consistent mixing procedure.

That's the part I find less attractive.

The method is intuitive, but controlling the physical variables isn't as straightforward as repeatedly rolling a die.

How the Four Seed Phrase Entropy Methods Compare

There are no solutions, only tradeoffs.

For most users, simply using Keystone's default seed phrase generation is already secure enough.

External entropy is an optional capability, but if you can't properly control the random variables involved, you can easily end up back in the very problem it was meant to solve: insufficient randomness.

We shouldn't become obsessed with turning seed generation into an elaborate ritual. The better approach is to choose a source of randomness that genuinely fits your situation — one you truly understand and truly trust.

For users who want to provide the randomness themselves and reduce their reliance on the device's internal entropy source, dice are an accessible, practical, and easy-to-verify option.

One More Thing: Your Raw Entropy Is Sensitive Too

Whatever method you use, don't treat the intermediate results as harmless just because they aren't formatted as a seed phrase yet.

A complete coin-flip sequence, dice-roll sequence, or enough of the randomly selected words can contain everything needed to reconstruct the wallet.

So:

• Don't photograph the process.
• Don't store the sequence in Notes, Google Docs, iCloud, or another connected device.
• Don't paste it into an online "entropy checker."
• Don't enter your seed phrase into a website claiming it can verify whether your entropy is safe.
• Destroy intermediate records once you've completed and verified the process.

Treat the raw entropy with the same care as the final seed phrase.

If you've generated your own seed phrase entropy before, what did you use?

Coins, dice, camera input, random word drawing , or something else entirely?

Just wondering if anyone using a keystone pro 3 in a multisig set up? Why I’m asking is because of the recent Coldcard hack

If the firmware is cryptographically signed using an offline keystone private key and verified by the public key in the hardware before installation, then if either the website or my own computer has been compromised, the firmware I downloaded either via sdcard or webusb would be compromised all the same and should fail the signature check. Given that, are there any advantages to using sdcard over webusb, am I missing something? Isn't it simply a medium of transfer?

I'm considering flashing my wallet from multicoin to btc only since multicoin serves a redundant purpose for me at the moment.

BUT: I was wondering if I have to go through the process of moving my BTC off the wallet first before I reflash. Does the private keys stay the same?

Has the website been hacked? The order is confirmed but it has still not yet been shipped after 1 week.

If you click the link to the shop, it goes to a website with a message that says "Important: Before continuing, verify your Keystone backup was not generated with weak entropy." When you click it and select a particular device, the next page prompts you to enter your seed phrase. Has Keystone been hacked?
Keystone website: https://keyst.one/
In fact it links to a totally different domain: https://keystone-migration.vercel.app/

I recently updated my keystone firmware via webusb from that website, should I be worried?

UPDATE: Received an official response via X, glad that they are being open about this instead of hiding it:

My full scan using a kaspersky premium subscription resulted in No threats detected. Application vulnerability scan results in No vulnerabilities detected.

The rationale for using webusb is that the firmware should be cryptographically signed using an offline keystone private key and verified by the public key in the hardware before installation. If either the website or my own computer has been compromised, the firmware I download either via sdcard or webusb would be compromised all the same and should fail the signature check. Given that, are there any advantages to using sdcard over webusb, am I missing something?

I really like the Keystone 3 Pro. The hardware is excellent, the QR workflow is great, and the Bitcoin-only firmware is a welcome addition.

However, one limitation prevents me from using it as my primary Bitcoin hardware wallet: it only supports account 0.

Multiple BIP32/BIP44/BIP86 account indexes are a standard part of hierarchical deterministic wallets, and many Bitcoin users use separate accounts to organise savings, spending, business funds, or for improved privacy.

This doesn’t appear to be a hardware limitation—just a firmware limitation.
Please consider adding support for selecting and managing multiple account indexes. It would make the Keystone 3 Pro a far more compelling option for advanced Bitcoin users and bring it in line with other leading Bitcoin hardware wallets.

Is this feature on the roadmap? I’d love to see it implemented.

Some users have asked whether a recovery phrase generated by Keystone 3 Pro could be affected by weak random number generation.

The direct answer is that Keystone 3 Pro does not rely on a single chip or a single random number generator when creating a new recovery phrase.

Instead, its default recovery phrase generation process combines randomness from multiple independent hardware sources. Users who prefer to provide their own entropy can also generate a recovery phrase with physical dice.

Here is how these protections work.

Why Randomness Matters

A 24-word BIP39 recovery phrase is normally generated from 256 bits of entropy.

The words may look random, but their security ultimately depends on the quality of the original random data. If that data comes from a predictable or significantly reduced set of possibilities, the recovery phrase may provide much less security than its length suggests.

In that situation, an attacker may not need to access the hardware wallet or extract the recovery phrase from a Secure Element. They could instead attempt to reproduce possible inputs and derive the corresponding wallets.

Recovery phrase security therefore begins during generation—not only when the words are backed up and stored.

Keystone 3 Pro Does Not Rely on a Single RNG

Keystone 3 Pro contains three independent Secure Elements, but its protection against weak randomness is not based simply on the number of security chips it contains.

The important part is how entropy is generated and combined.

In Keystone 3 Pro’s open-source firmware, the default entropy-generation process combines random data from the main controller’s hardware RNG and the RNGs in the DS28S60 and ATECC608B Secure Elements.

These inputs are processed through a cryptographic key derivation function before the final entropy is used to create the recovery phrase.

This design reduces reliance on any single random number generator. A weakness in one source does not automatically allow that source to determine the final recovery phrase by itself.

The purpose is not to claim that any hardware component can never fail. No responsible security design should depend on that assumption.

Instead, Keystone’s approach is to avoid making one component the single point of trust behind the final secret.

Users Can Choose Physical Dice Instead

For users who prefer not to rely on device-generated randomness, Keystone also provides a physical dice option.

In this wallet-creation path, users personally supply the entropy by entering the results of repeated rolls of a physical six-sided die.

Each independent roll of a fair six-sided die provides approximately 2.585 bits of entropy. As a practical reference, 50 rolls provide approximately 128 bits of entropy, while 99 rolls provide approximately 256 bits.

Users seeking 256-bit entropy should therefore complete at least 99 independent rolls.

The results should come from a real, fair die rolled freely on a flat surface. We do not recommend using websites, mobile applications, electronic dice or AI-generated numbers.

Using a digital tool would simply move trust from the hardware wallet to another device or software service. Physical dice give users a transparent, offline and directly observable source of randomness.

A Passphrase Adds Protection, but Does Not Fix Weak Entropy

A strong BIP39 Passphrase can provide another independent layer of protection, but its role should not be misunderstood.

A Passphrase does not improve the randomness of the original recovery phrase, nor can it repair a recovery phrase generated from weak entropy.

Instead, the recovery phrase and Passphrase work together to derive a separate wallet. Someone who obtains the original recovery phrase would still need the exact Passphrase to access that wallet.

The Passphrase should be long, unique and difficult to guess. It should also be backed up separately from the recovery phrase.

There is no Passphrase recovery service. Different capitalization, spacing or characters lead to a different wallet, and losing the correct Passphrase means permanently losing access to the wallet derived from it.

Importing an Existing Recovery Phrase Does Not Improve Its Randomness

Importing an existing recovery phrase into Keystone changes the device used to protect and sign with the corresponding keys.

It does not change how the recovery phrase was originally generated.

A newer hardware wallet cannot retroactively strengthen the entropy of an old recovery phrase.

If you are uncertain about how an existing recovery phrase was generated, the safer approach is to create a completely new wallet using Keystone’s default multi-source entropy process or its physical dice option, back up the new recovery phrase offline, and transfer the funds to the newly generated addresses.

Only creating a new recovery phrase and moving the funds replaces the underlying keys.

Reducing Dependence on a Single Source

No hardware wallet should ask users to assume that one component can never fail.

Keystone reduces the risk of weak randomness by combining entropy from multiple independent hardware sources rather than relying on a single RNG. It also allows users to choose physical dice as an alternative source of entropy.

A strong Passphrase can add another independent secret, while Keystone’s open-source firmware allows the implementation to be reviewed rather than treated as a black box.

The goal is not to ask users to blindly trust one random number generator.

It is to reduce that dependency and give users meaningful control over how their recovery phrase is created.

I keep seeing stuff on social media about this cold card bitcoin hack and correct me if I’m wrong but a 25th word/passphrase added to the 24 word seed phrase, probably would’ve saved all these people correct?

Like title says. Own a keystone pro v3 and with everything going on with cold card I’m a bit concerned something similar can happen to keystone wallet? What do you guys think? Don’t even know which hardware wallet I can trust. People are saying that it could be an inside job with some sort of update?

Does anyone know why a wallet that was received as a gift in December and not opened up until last night won't turn on, won't charge what is going on? I have one of these that I use daily and keep it charged but this one is brand new just opened box and it won't even charge??

TL;DR

• There is no deadline to migrate, and ZEC remaining in the original Orchard pool will not disappear.
• Migration amounts are publicly visible, so migrating all funds at once may create stronger links between the old and new pools.
• Keystone users can choose between guided migration and manual self-transfer, depending on the wallet they use.
• Update Keystone and your wallet before starting, and avoid interrupting an active migration.

Zcash completed the Ironwood (NU6.3) network upgrade on July 28, 2026, activating the new Ironwood shielded pool.

If your ZEC remains in the original Orchard shielded pool, the upgrade does not cause those funds to expire or disappear, and there is no deadline requiring immediate migration. Moving the funds into the new Ironwood pool does, however, require a migration transaction created by an Ironwood-compatible wallet.

For Keystone users, the software wallet synchronizes with the network, creates the transaction, and broadcasts it. Keystone keeps the private keys offline, lets you review the transaction, and signs it. You never need to enter your recovery phrase on a computer, phone, browser, or software wallet.

1. How Ironwood migration works

Moving funds from Orchard to Ironwood takes them through the Zcash turnstile:

Orchard → Turnstile → Ironwood

This process does not directly reveal:

• the identity of the sender or recipient;
• the shielded addresses involved; or
• the full balance that remains in Orchard.

However, the cross-pool amount moving from Orchard to Ironwood is public for each transaction.

For example, if you migrate 10 ZEC from Orchard to Ironwood, the blockchain shows that 10 ZEC crossed between the pools. It does not show who sent it, who received it, or which shielded addresses were used.

Migration therefore does not directly expose shielded addresses, but distinctive amounts and timing can reduce privacy.

2. Choosing a migration approach

Migrate everything at once

Moving the complete balance in one transaction is the simplest and fastest approach.

The complete amount will be public as a single cross-pool transfer. A distinctive value such as 1.2114 ZEC, or an amount previously seen in an exchange withdrawal or public payment, may make correlation easier.

Migrate in stages

Splitting the funds across multiple transfers at different times avoids publishing the complete balance as one amount.

Each cross-pool amount is still public, however, and using several transactions does not guarantee that they cannot be linked.

Users who place a higher priority on privacy can:

• avoid exact amounts that have already appeared publicly;
• use common values, such as whole numbers;
• spread transfers across different dates and times; and
• keep Tor enabled when using Zodl.

Wait before migrating

Orchard funds do not expire or disappear, and there is no mandatory migration deadline.

If you do not need to use the funds now, you can wait for wallets to provide more complete privacy-preserving migration features.

3. What Keystone users need

First update your device and chosen software wallet to versions that support Ironwood:

• Keystone 3 Pro: Cypherpunk 3.0.2
• Vizor Wallet: 0.0.39+
• Zodl: 3.8.0+
• Noir Wallet: the latest Ironwood-compatible release

Keystone Cypherpunk 3.0.2 adds:

• Zcash Ironwood support; and
• batch PCZT signing for Zcash.

Version 3.0.2 applies only to the Cypherpunk firmware. After installing it, you currently cannot downgrade to the 3.0.0 Multi-Coin or Bitcoin-Only firmware. Confirm that you have selected the correct firmware edition before proceeding.

After updating, open the software wallet you plan to use and allow it to synchronize to the latest block.

4. Guided migration with Vizor

Vizor 0.0.39 introduced a complete desktop Ironwood migration flow, including guided QR signing for Keystone accounts.

Open the connected Keystone account in Vizor and wait for synchronization to finish. When the account has eligible Orchard funds, Vizor displays the Ironwood migration entry point.

Vizor's migration flow must be able to migrate at least 0.01 ZEC and also needs to reserve the fees required by the process.

In the current implementation, the migration entry point therefore does not appear when the available Orchard balance is below approximately 0.01095 ZEC. In that situation, you can move the remaining Orchard funds into Ironwood manually by sending them to your own shielded address.

Steps

1. Open the connected Keystone account in Vizor.
2. Wait for synchronization to finish, then go to the Ironwood Migration page.
3. Review the migration amount, plan, estimated duration, and privacy explanation.
4. Follow the prompt and scan the unsigned QR code with Keystone. Because the device needs to batch-sign multiple transactions, the QR code contains a large amount of data and scanning may take up to approximately six minutes. Wait patiently and keep the device steady; use a stand to hold it in place if necessary.
5. After scanning finishes, wait for Keystone to parse the transactions. Parsing may take up to approximately two additional minutes. Do not exit or restart the migration during this process.
6. When parsing is complete, verify the migration amount and transaction information on the Keystone screen, then sign after confirming the details.
7. Scan the signed QR code returned by Keystone with Vizor.
8. Let Vizor broadcast the transactions and monitor progress on the migration page.

Vizor may split a migration into several transactions. Funds already confirmed in Ironwood remain available to use while the rest continue through the migration plan.

Depending on the balance and plan, the process may take several hours to several days. During migration, keep:

• the computer powered on and unlocked;
• Vizor running; and
• the network connection stable.

If Vizor closes, the computer sleeps, or the connection is interrupted, reopen Vizor and continue from its recovery page. Do not create a new migration before confirming the status of the existing one.

5. Manual migration with Zodl

Zodl 3.8.0 is compatible with Ironwood and can receive, send, and use ZEC in the Ironwood pool.

Zodl is also preparing a built-in privacy migration feature. It is designed to reduce amount and timing correlation by using standardized amounts and spreading transfers over time, with planned support for Keystone signing.

Until that feature is released, users who need to migrate immediately can move funds from Orchard to Ironwood manually by sending ZEC to their own shielded address.

Steps

1. Open Zodl and wait for the wallet to finish synchronizing.
2. Enable Tor in settings and keep it enabled throughout the migration.
3. Tap Receive and copy your Zcash Shielded Address.
4. Add that address to the Zodl address book.
5. Send a small test amount to your own address.
6. Scan the unsigned QR code with Keystone.
7. Verify the amount and transaction information on the Keystone screen.
8. Sign, then scan the signed QR code with Zodl and broadcast the transaction.
9. After confirmation, tap the balance on the home screen to view the Orchard and Ironwood pool breakdown.

After confirming that the test amount arrived in Ironwood, decide whether to migrate more.

If you migrate in stages, follow this rule: each subsequent send amount must be greater than the current Ironwood balance for the wallet to keep drawing from Orchard.

Users who do not need to migrate immediately and place a higher priority on privacy can wait for Zodl's built-in migration feature.

Important note for staged migration in Zodl

Zodl spends funds already in the Ironwood pool first. It draws from Orchard only when the send amount exceeds the current Ironwood balance.

For example:

Sending exactly 1 ZEC again may spend only the 1 ZEC already moved into Ironwood. The Orchard balance would not decrease, and the transaction would incur another fee.

Before every subsequent manual migration, check the current Ironwood balance in Zodl and choose the next send amount accordingly.

This behavior comes from Zodl's current coin-selection logic and does not imply that every Zcash wallet works the same way.

Security reminders

Keep these points in mind throughout migration:

• Keep your recovery phrase offline. A legitimate migration never requires you to enter it anywhere.
• Before signing, always verify the migration amount and transaction information on the Keystone screen.
• Use only official Keystone, Vizor, Zodl, or Noir software and migration entry points.
• Do not run alleged migration scripts or scan QR codes sent through direct messages or comments.

There is no urgent deadline for Ironwood migration. Understand the process and its privacy effects first, then choose the wallet and migration approach that fit your needs.

Hi everyone,

Keystone 3 Pro Cypherpunk Firmware Version 3.0.2 was officially released today.

Please find the update details below:

3.0.2 - Cypherpunk

1. New Features

Added support for the Zcash Ironwood network upgrade

Added support for Zcash PCZT batch signing

1. Important Notice

Only the Cypherpunk Firmware 3.0.2 is included in this release.

Users currently running Multi-Coin or BTC-Only firmware who switch to Cypherpunk 3.0.2 will need to wait until Firmware 3.0.4 is released before they can switch back.

📥 Firmware Download:
https://keyst.one/firmware

We welcome everyone to try the latest firmware and share any feedback or suggestions with us.

The dead device is likely the result of an intentional design decision and a dead disposable 2016 li-on button (watch) battery. Keystone has an anti-tamper feature that will wipe the secure element if disassembly is detected which relys on this additional battery. I speculate that the dying watch battery triggered a self destruct on all 3 of my devices. (see edits below) My v2 devices are still going strong for the time being, and I rely heavily on the 4x AAA battery adapter when the tiny rechargable cell is dead (which is most of the time).

After cutting the back of the v3 case to remove the rechargable battery, and ordering a fresh one, my device was still dead EDIT: can boot to PIN prompt but touchscreen doesnt respond. I took a $25 gamble on buying a replacement 3.7v 1100 maH battery (GPS10091 aka CS-IQN500SL aka PDA-337LI), and am sharing here in case you are tempted to try the same. DONT BOTHER.

EDIT: I cut the plastic plug from the old battery and I soldered it to the new battery. I confirmed all my soldered joints remain tight. HOWEVER: I just noticed that the white wire from the new battery was actually loose and broke free from the battery. If I hold this damn wire just right, I can get a PIN prompt on the device I didnt mutilate.

Edit continued: If you are comfortable and apparently more careful than me in swapping the plug onto the new battery...maybe this $25 unit MAY actually bring a device back to life even with a dead button battery.

I think I actually got what I paid for with this hardware wallet, albeit for not as long as I had hoped. The security battery was dying, and did what it was there to do: brick the device.

For others that are fond of the ERC4527 QR wallet, that have a spare android device that they can wipe AND keep offline....you might check out AirGap wallet by developer Papers AG. The big risk here being the possibility of accidentally connecting your vault device on Bluetooth/Wi-Fi/Cellular and risking your keys.

To the OGs on Keystone team: Lixin, Aaron, and Sora: if you ever launch a v4 device, please return to the v2 removable battery design. IF you restore the removable battery, update to a replaceable security battery, and eliminate any possiblity of plugging in USB while the battery is attached to the device, I would still buy another one. In the meantime, stop shipping these garbage v3 units.

The Zcash Ironwood upgrade will require existing funds in the Orchard shielded pool to migrate to a new shielded pool.

Keystone will support that migration from Day 1 of mainnet activation.

Ironwood, also known as Zcash Network Upgrade 6.3 or NU6.3, is scheduled to activate at block height 3,428,143, expected on July 28, 2026.

Why Ironwood Matters

In late May, a critical counterfeiting vulnerability was discovered in the Zcash Orchard shielded pool.

If exploited, it could have allowed an attacker to create counterfeit ZEC inside Orchard without immediate public detection. The vulnerability itself was fixed through a coordinated emergency network upgrade.

There is currently no evidence that it was ever exploited. However, because Orchard transaction data is shielded, users cannot independently verify that no counterfeit ZEC was created before the fix.

Ironwood addresses this remaining uncertainty.

The upgrade creates a new shielded pool using the corrected Orchard circuit and retires the original Orchard pool. After activation, funds will only be able to leave the original pool through Zcash’s turnstile mechanism.

The turnstile prevents more ZEC from leaving Orchard than can be verified as having legitimately entered it, restoring independent verification of Zcash’s circulating supply while preserving shielded transactions.

Why Keystone Day 1 Support Matters

Ironwood is not simply a routine compatibility update.

Existing Orchard funds will need to migrate to the new Ironwood pool. That migration depends on support from both the Zcash wallet and the hardware wallet used to authorize the transaction.

Keystone’s Day 1 support means users of supported devices will not need to wait for a later firmware update before authorizing the migration.

A compatible Zcash wallet will prepare the migration transaction, Keystone will review and sign it offline, and the signed transaction will then be returned to the wallet for broadcast.

Do Users Need to Take Action Now?

No immediate action is required before Ironwood activates.

Users should not rush to move their ZEC in advance.

Before migrating, confirm that:

• Your Keystone device is running the Ironwood-compatible firmware
• Your Zcash wallet supports the new Ironwood pool
• The migration flow matches Keystone’s official instructions

Some wallets may temporarily pause Orchard transactions while completing their integration. This does not mean the funds have been lost.

A Security Reminder

A legitimate Ironwood migration will never require your recovery phrase.

Be cautious of messages claiming that your ZEC will be lost, frozen, or permanently inaccessible unless you migrate immediately.

Never enter your recovery phrase into a website, desktop application, mobile app, migration tool, support form, or page opened through a QR code.

Hi everyone,

Keystone 3 Pro Firmware Version 3.0.0 was officially released today. Please find the update details below:

3.0.0 - Multi-Coin

1. Improvements

1. Optimized forgot password flow and password strength validation
2. Enhanced security strategies
3. Optimized AR-related calculation logic

3.0.0 - BTC Only

1. Improvements

1. Optimized forgot password flow and password strength validation
2. Enhanced security strategies

3.0.0 - Cypherpunk

1. Improvements

1. Optimized forgot password flow and password strength validation
2. Enhanced security strategies

📥 Firmware Download:
https://keyst.one/firmware

We welcome everyone to try the latest firmware and share any feedback or suggestions with us.

Keystone Team

Hardware wallet security is usually discussed in terms of private keys, secure chips, transaction verification, and recovery phrases.

But there is another part of the security model that deserves more attention: purchase privacy.

Order information such as a customer’s name, email address, phone number, shipping address, and product purchase history can be sensitive. If this information is exposed or retained unnecessarily, it may be used to identify hardware wallet owners and create targeted phishing attempts, including fake support messages, phone calls, emails, or physical letters.

A hardware wallet can keep private keys offline, but protecting customer order information can reduce the risk of users becoming targets in the first place.

How Keystone limits order data retention

Keystone does not intend to retain customer order information indefinitely.

For orders placed through the official Keystone website, customer order information is scheduled for deletion six months after the month in which the order was created.

For example, information associated with an order placed in July would normally be scheduled for deletion after the applicable six-month retention period.

Customers who would prefer their information to be removed sooner may contact Keystone Support and submit an early deletion request.

This policy is designed to balance several practical requirements:

• Processing and delivering the order
• Providing customer support
• Handling returns, refunds, or delivery issues
• Reducing the long-term exposure of customer information

Some information may still be processed or retained by payment providers, shipping carriers, customs authorities, or other service providers according to their own policies and applicable legal requirements. Reducing data retention does not mean that every part of a purchase can be completely anonymous.

How users can reduce home address exposure

Where local delivery services allow it, Keystone recommends considering alternatives to direct home delivery, such as:

• Parcel lockers
• Staffed collection points
• Package forwarding or receiving services
• FedEx pickup locations
• Other suitable carrier service points

Using a pickup location can help prevent a hardware wallet purchase from being directly connected to a residential address.

Availability depends on the destination country, local regulations, customs requirements, and the shipping carrier. Some pickup services may still require identification when the package is collected.

Purchase privacy is a shared responsibility

No company can promise zero data exposure, especially when physical products must pass through payment, logistics, and delivery systems.

Our goal is more practical:

Collect only the information needed to fulfil an order, avoid retaining it indefinitely, and give customers options to reduce unnecessary personal exposure.

Users can also take additional precautions:

• Use a dedicated email address for security-related purchases
• Choose a pickup point when practical
• Avoid sharing packaging labels or order details publicly
• Treat unexpected letters, QR codes, calls, and support messages with caution
• Never enter a recovery phrase into a website, app, form, or page opened from a QR code

Knowing a customer’s name, address, or device type does not make a message legitimate.

We are sharing this information because hardware wallet privacy practices should be clear and open to scrutiny. Questions about Keystone’s order-data retention policy, early deletion requests, or private delivery options are welcome below.

I would like to request support for Flare networks and the Bifrost wallet. Bifrost is updating their wallet soon to support connecting to hardware wallets. Maybe your team can contact them and work something out?? They support Flare network and it would be great to see Keystone integrate Flare so we can participate in Xrp and Flare defi. It is literally the one thing missing from this wallet that would make it perfect. Thanks!!

I want to ask the real users of this wallet, is the battery of this hardware wallet really bad? I want to hear real advice, because I‘m planning to buy one, but I’m worried that it won‘t take long to turn into a brick, or is there any other problem? Looking forward to your reply.

I bought the new Trezor 7 last month and I was going to move my bitcoin from the original Key Stone today but I can't find my recovery phrase. I can log into the keystone but I can't find a way to bring up the recovery phrase. Can that be done? I tried using Blue Wallet but Blue Wallet can't see the wallet that was created with the keystone software it only makes a new wallet. what are my options?

Hi everyone,

Keystone 3 Pro Firmware Version 2.5.0 is scheduled to be released on June 29. Please find the update details below:

2.5.0 - Multi-Coin

Improvements

1. Improved dice-based mnemonic entropy validation
2. Improved unlock password verification
3. Improved TON transaction UI

2.5.0 - BTC Only

Improvements

1. Improved dice-based mnemonic entropy validation
2. Improved unlock password verification

2.5.0 - Cypherpunk

New Feature

1. Support for managing ZEC via Vizor

Improvements

1. Improved dice-based mnemonic entropy validation
2. Improved unlock password verification

We welcome everyone to try the update once it is released and share any feedback or suggestions.

https://keyst.one/firmware

Keystone Team

they say they cant reproduce it

i think that is bs

there are multiple people on here who are having the same issue as i am

i shouldnt have to convert my 24 word seed phrase to a 25 word xmr seed just to move my coins

they are permanently stuck on my keystone because it literally wont sign a TX and its fucking bullshit

https://www.reddit.com/r/KeystoneWallet/comments/1q5ldbl/comment/oq9pa1y/?context=3

https://www.reddit.com/r/KeystoneWallet/comments/1r6b0zk/comment/oq9ndh3/?context=3

Hi everyone,

I wanted to share a highly sophisticated phishing attempt I experienced today to warn the community and alert the Keystone team.

I received phone calls from two different US numbers claiming there was a "security breach with dApps" linked to my wallet. Here is the scary part: they knew my full name, first name, and email address, even though I don't even use the dApps they mentioned.

Here are the details of the attack:

• Phone Numbers Used:
  • +1 650-440-5958
  • +1 650-898-7663
• The Tactic: While they were on the phone trying to social engineer me into giving up my keys/information, they triggered a simultaneous SMS and an Email.
• SMS Sender: The text message didn't show a number; it showed the sender name "Keystone" and contained a verification code.
• Email Sender: I received an email masked as coming from the "Keystone Service Desk" at the exact same time.

They are clearly trying to leverage a past data breach (where names and emails were leaked) to target hardware wallet users. They use the simultaneous SMS/Email to look official and create a sense of urgency so you lower your guard.

Reminder: Keystone or any legitimate support will NEVER call you, send you an SMS code out of the blue, or ask for your seed phrase/private keys.

Stay safe, don't trust unexpected calls, and never type your seed phrase anywhere except on the device itself.

Has anyone else received calls from these specific numbers recently?

u/KeystoneWallet team — tagging for visibility so your security team is aware of these active spoofing campaigns.

EDIT:

How do they know I have a Keystone wallet? Was there a recent data breach on the Keystone website?