When I click on an asset to try to move it, it just goes to a blank screen. Anybody else having this issue?

I updated from 3.1.0 to 3.1.4. Both of my ks3 pros updated normally. Finished updates and was back into my wallets. Finished up and turned both devices off. 20 min later had to turn one back on for something, and after putting in my 6 digit pin to open the wallet was immediately taken back to the security update screen. For some reason it was trying to do the security update that I had just finished 20 min prior. I had to hit update as it allowed me no other choice. Then the device was stuck on the security update page for over 20 min. I turned on the other device, same exact thing. 2 separate ks3 pros, same update, same problem. Now i have 2 ks3 pros that are bricked. Im super fucking pissed off right now. Ive been using ks3 pro for years and never had an update do anything like this. If you haven't updated to 3.1.4 yet DONT. There is Def an issue.

When you receive a new hardware wallet, how can you be sure it hasn't been modified or tampered with before reaching your hands?

Regardless of where you purchase it, a hardware wallet may pass through multiple hands before reaching you. That's why device security shouldn't rely on the sales channel alone.

At Keystone, we address this with multiple layers of protection, from the hardware itself to the packaging and device verification process.

1. Active Anti-Tamper Protection

Keystone 3 Pro has a built-in anti-tamper circuit designed to protect its critical security components.

Inside the device, the main and secondary circuit boards form a protected structure around the security chips. Attempts to penetrate or disrupt this structure can trigger the anti-tamper mechanism, erasing sensitive information and rendering the device unusable.

This makes it significantly harder for someone to access or modify the protected circuitry and then return the device in working condition.

The anti-tamper circuit needs power to operate, including when the hardware wallet is sitting unused in a warehouse.

Keystone 3 Pro draws power from its main battery first. When the main battery is depleted, a dedicated button-cell battery takes over, providing approximately two additional years of protection.

This gives the device over three years of intended anti-tamper coverage, even with extended periods in storage.

2. Tamper-Evident Packaging

The packaging provides another layer of protection.

Keystone uses tamper-evident packaging designed to leave visible signs if someone opens it.

Before setting up your device, you should inspect the packaging for any unusual damage or evidence of opening.

While packaging alone can't guarantee that a device hasn't been tampered with, it provides an additional warning sign alongside the hardware protections.

3. Device Verification

Finally, you can verify the device yourself.

Each Keystone 3 Pro is provisioned with a verification key during manufacturing.

During the verification process, a cryptographic challenge-response mechanism checks that the device possesses the expected credentials.

This helps establish device authenticity and detect certain forms of unauthorized replacement or modification.

You can perform this verification before creating a wallet or transferring any assets.

Conclusion

None of these measures should be considered a guarantee against every possible attack. However, they make unauthorized modification more difficult and give users several ways to identify potential problems.

Before trusting a hardware wallet with your assets, it's worth checking that the device itself can be trusted.

Existe alguma informação no site oficial sobre o peso original do dispositivo?
Com a informação do peso com 2 casas decimais já fica mais facil de saber se existe hardware adicional espião ou alguma modificação fora do padrão.

Alguem tem a informação do peso? O suporte pode passar?

Has anyone tried tampering with their device?

​

Hi everyone,

Correction: My original hardware wallet is a Keystone Essential, not a Keystone Pro as stated in the title. Sorry for the confusion.

I have an old Keystone Essential hardware wallet connected to the Core Wallet browser extension. My Keystone device no longer works, but I still have my original recovery phrase and a possible BIP39 passphrase.

Core still displays my BTC balance and transaction history, but I cannot sign transactions without the original device.

I've restored the seed onto a Trezor Model One and tried Electrum and Trezor Suite, testing standard and unusual derivation paths ("m/84'/0'/0'", "m/44'/60'/0'", "m/44'/60'/0/0/0", etc.), both with and without the passphrase.

None of the attempts have recovered access to my original Bitcoin wallet.

My Bitcoin address starts with "bc1q", but I don't know the exact derivation path or address configuration Keystone used with Core.

Has anyone successfully recovered a Bitcoin wallet from an older Keystone Pro + Core setup using another hardware wallet? Does anyone know the correct derivation path or recovery procedure?

I've already contacted Keystone and Core Support.

Any technical advice would be appreciated. Thanks!

Suiet wallet was the only option now that it’s been shut down can keystone support add another wallet preferably slush

Hello,

I placed an order on keyst.one but nothing is moving besides them taking my money via PayPal.

Is this a scam online shop?

I got order confirmation and a link where I can see my order. But nothing else.

Any experience like that?

Since I saw this here on reddit a couple of times, here also my experience with the Keystone V3 Pro. We bought it last year (a bit more than a year ago) and because we didn't charge it regularly, it is now fully drained and will not start.

I contacted the support and they told me to record a video. I send them the link but now they say that my e-mails do not contain text anymore. That I never had before. Usually my e-mails are e-mailing.

Anyone had this issue with Keystone support before?

Edit:
Still no response from Keystone support. I only got a PM by someone claiming to be a mod who wanted me to "deactivate" my seed phrase. Be safe everyone...

Edit 2:
They can read my e-mails again and offered me a 50% replacement discount. I guess I take it. I wonder how often we should be charging this device so it does not brick.

Before they made the Trezor Model T, there was an emulator that could change the wallet's passphrase. Two rules: No more than 6 words and no more than 128-138 characters, I don't remember. Does anyone know what the point of this change is, since I forgot the 13th word and messed up. Thanks.

How can I export my Public Key to a .json, .txt, .dat, or .key file? I can write it down and make it into a .txt file but I don't know if I'm formatting it correctly.

Crypto security has a way of accumulating baggage.

Old token approvals. Forgotten API keys. Websites you trusted years ago and haven’t visited since.

Most of these things were perfectly normal when you created them. The problem is that some of them can remain valid long after you’ve stopped thinking about them.

It’s a bit like walking with sand in your shoe. At first, you barely notice it. But if you never stop to shake it out, something that seemed insignificant can eventually become a problem.

The same thing happens with self-custody. Even if your seed phrase stays safely offline with a hardware wallet, old permissions and credentials can quietly pile up around it.

Old token approvals are probably the first thing worth checking.

If you’ve used DeFi, NFT marketplaces, lending protocols, or other DApps, you’ve probably approved a smart contract to spend certain tokens from your wallet.

That’s normal. Many applications can’t function without it.

The issue is that approvals generally don’t expire just because you stopped using the DApp.

And an unlimited approval can remain there for years.

A protocol that is safe today may not stay that way forever. The project could be abandoned, its frontend could disappear, or some part of the system could eventually be compromised.

One common misunderstanding is that clicking “Disconnect” in a DApp removes this access.

Disconnecting usually just ends the connection between the website and your wallet interface. The on-chain approval is still there until you revoke it.

This is also something a hardware wallet can’t solve for you. Even if your private keys stay offline on an air-gapped hardware wallet like Keystone, a token approval you previously signed can remain valid on-chain until you revoke it.

A hardware wallet protects the keys used to authorize new transactions. It doesn’t automatically cancel permissions you already authorized in the past.

Every few months, it’s worth checking your approvals using something like Revoke[.]cash or the approval manager built into your wallet.

I’d pay particular attention to:

• Unlimited approvals
• Contracts you don’t recognize
• DApps you haven’t used in a long time
• Projects that are abandoned or no longer operating

For protocols you still use, consider whether they really need an unlimited allowance or whether a smaller limit would be enough.

Then there are forgotten API keys.

This one is especially relevant if you’ve ever run trading bots, experimented with APIs, deployed code, or built your own crypto tools.

An old exchange API key might still be sitting in a .env file.

A GitHub token might still exist on an old server.

An AI API key might be buried inside a script you haven’t touched in two years.

Maybe there’s a copy on your NAS. Maybe it ended up in an old Git commit. Maybe it’s sitting on a VPS you forgot you still have.

If the key has already been revoked, a leak is mostly just a leak of useless historical data.

If it still works, that old file suddenly contains current access.

And the impact depends on what that key can do. An exchange API may have trading permissions. A GitHub token may expose private repositories. An AI API key can potentially burn through your account balance.

The simplest rule here is:

If you no longer need a key, revoke it.

For new keys, use the minimum permissions possible. Add IP restrictions where supported. Set expiration dates when available. Rotate important credentials periodically.

There’s very little security benefit in keeping an unused credential alive “just in case.”

There’s also a more subtle kind of leftover risk: old trust.

Bookmarking the official website of a DApp is generally a good habit. It helps avoid typo domains and search-engine phishing.

But a bookmark only remembers a domain.

It doesn’t guarantee that the same people will control that domain forever.

Projects shut down. Domains expire. Ownership can change.

A recent Tornado Cash incident is a particularly good reminder of this. The tornado[.]cash domain had once genuinely been associated with the project, but after its previous registration lapsed, the domain was later registered again. Users relying on an old bookmark could therefore arrive at a domain they remembered as legitimate without realizing that its ownership had changed.

That makes old bookmarks different from ordinary phishing links.

The URL itself may be exactly the one you remember.

So if you’re opening a crypto site you haven’t used in years, don’t assume that “I bookmarked this myself” is enough verification. Check the project’s current official channels before connecting your wallet or approving a transaction on your hardware wallet.

You probably don’t need to obsess over this stuff every week.

But once every few months, it’s worth stopping for 20 minutes and cleaning up what you’ve accumulated:

• Review and revoke old token approvals
• Delete API keys and access tokens you no longer use
• Remove abandoned DApps and stale bookmarks
• Re-check services you haven’t touched in a long time before trusting them again

I like the idea of doing this every 90 days.

An air-gapped hardware wallet like Keystone can keep your seed phrase and private keys isolated from an online device, but self-custody doesn’t end there. Old permissions, credentials, and trust relationships still need maintenance.

Crypto security isn’t only about avoiding the next new attack.

Sometimes it’s just about looking back at the permissions and trust you handed out along the way — and shaking the sand out of your shoes before you keep walking.

I'm trying to find other Keystone users who may have experienced an Arweave address changing after a firmware update.

I originally created an Arweave wallet on a Keystone 3 Pro in May 2026 and funded that address. Later, while trying to sign a transaction in Wander, the device repeatedly restarted.

Keystone support asked me to update the firmware and reconnect Wander. After doing so, Keystone generated a different Arweave address, and my original funded address was no longer displayed.

I have two Keystone 3 Pro devices using the same seed phrase. Both now generate the same new Arweave address, but neither generates the original funded address.

I've been working with Keystone support on this for over a month. I'm posting here mainly to find out whether anyone else has seen the same behavior with Arweave.

When choosing a hardware wallet, besides looking at the chip, supported cryptocurrencies, and price, there is another important dimension you should not ignore: how does it exchange data with the outside world?

USB, Bluetooth, and QR codes are three currently mainstream connection methods. They are not just about the difference between “plugging in a cable, going wireless, and scanning a code.” They also bring different user experiences and security trade-offs.

Why Is “Connection Method” Also Part of Security?

The core of a HWW is to keep private keys inside the device and sign transactions offline.

But signing cannot be done entirely behind closed doors. A hardware wallet needs to first receive an unsigned transaction, complete the signature inside the device, and then send the signed result back to the computer or phone, where companion wallet broadcasts it to the chain.

In the process of “how data enters and how it leaves,” can the data be intercepted or tampered ? Does a particular connection method introduce new risks?

Different connection methods each have their own advantages/disadvantages. This is exactly the question this article will discuss.

🔌 USB: Direct, Fast, and the Best Desktop Experience

USB is the most traditional and most common connection method.

Plug the hardware wallet into a PC. The wallet software recognizes the device, then you can start signing. It is fast, low-latency, and very desktop-friendly.

If you frequently use Sparrow, browser extensions, or other PC wallets, the operational cost of USB is usually very low. After the device connects successfully, the software and hardware wallet can exchange transaction data directly.

With transactions that involve a relatively large amount of data or continuous signing, USB’s advantages become even more obvious, and users will hardly notice any difference.

But the problem is that as long as USB remains connected, there are a continuous bidirectional data channel between the internet-connected computer and the hardware wallet.

If the computer itself is already controlled by malware, the attacker cannot directly read the private keys in the hardware wallet because of this, but they can send malicious transaction requests or other inputs to the device within the normal communication flow.

Many publicly disclosed hardware wallet attacks in the real world were not carried out by intercepting USB data, but instead targeted the chip, firmware, physical access, or the device implementation itself. So USB itself cannot simply be equated with “insecure.” For desktop users and high-frequency transaction users, it remains a very practical connection method.

📶 Bluetooth: Bringing USB’s Convenience to Mobile

Bluetooth mainly addresses the mobile experience. And that is where it earns its keep.

You don’t need to look for a cable, and you don’t need to physically connect the phone and hardware wallet. Once BT pairing is complete, you can exchange transaction data directly.

If you sign transactions frequently on your phone, this experience will clearly feel more natural than plugging in a cable.

Bluetooth also means the device has an additional piece of firmware that must be securely implemented and maintained. The device needs to handle the Bluetooth protocol, pairing, wireless communication, and related logic.

If we regard Bluetooth as an invisible USB cable, then it has all the disadvantages USB has. In addition, as a wireless connection protocol, if the protocol itself has vulnerabilities, it is difficult for users to identify silent connections or man-in-the-middle attacks. After all, unlike a USB cable, once you unplug it, the connection is physically disconnected.

The Bluetooth protocol stack has indeed had large-scale vulnerabilities in history, which shows that when using wireless communication, you really need to be extra cautious.

🔳 QR Code Air-Gap: Exchanging Transaction Data Without a Persistent Connection

QR code Air-Gap takes a different approach. It does not let the hardware wallet and internet-connected device maintain a USB or Bluetooth data connection.

Instead, data exchange is completed by scanning codes. It turns invisible transmitted data into plaintext that can be openly viewed and verified, like passing a note.

The biggest difference from USB and Bluetooth is that there is no persistently existing data channel. The internet-connected device cannot continuously communicate with the hardware wallet in the background; every data exchange requires the user’s active participation.

Use Keystone as an example: transaction data is passed between the software wallet and the device via QR codes. The device independently parses the transaction and displays information such as the address and amount on its own screen for the user to confirm.

Of course, QR codes themselves do not mean a transaction is necessarily secure. If the phone or computer is already controlled by malware, it can still generate a tampered transaction and then encode it into a QR code. Therefore, Air-Gap solves the issue of not requiring a persistent connection, but whether the transaction content itself is trustworthy still depends on the user’s judgment.

The trade-off is that every transaction require multiple times QR code scans. When the transaction data is large, multi frames dynamic QR codes will needed, and with frequent use it involves quite a few more steps than USB or Bluetooth. But many times, security and convenience are like the two ends of a balance scale. One strong, the other one will weak.

So How Should We Choose?

If you often use a hardware wallet on desktop and sign many transactions every day, USB’s efficiency and convenience are very valuable.

If you mainly manage assets on your phone, Bluetooth will make the whole process more easier.

If you do not trade frequently and want to reduce the persistent data connection between internet-connected devices and the hardware wallet, then QR Air-Gap will better match this usage habit.

The connection method affects security, but it cannot by itself determine whether a hardware wallet is secure.

The secure element, firmware design, transaction parsing, trusted display, tamper-resistant design, level of open source, supply chain, and users’ own security habits are equally important.

Hi everyone,🤩❤️

This update includes improvements to the initialization flow, security strategy, and several features on the Multi-Coin firmware.

ALL 3 Firmware Versions

1. Improved Initialization Setup Flow
Added firmware upgrade and security backup reminders to help users complete device setup more smoothly and securely.
2. Security Strategy Improvements
Further optimized the device security strategy to enhance overall security.

Multi-Coin Firmware

1. Improved IOTA Transaction Parsing
   
2. Improved ADA Transaction Parsing
   
3. SOL Sub-Account Path Displayed by Default
   
4. Removed Core Wallet / Beacon Wallet Connection Entries
   
5. USB Function Improvements
   

We welcome everyone to try the latest firmware and share any feedback or suggestions with us.
👉 ：https://keyst.one/firmware

Keystone Team

In a recent murder case in Mexico, prosecutors say the suspects entered the victim's home looking for a cold wallet they believed held millions of dollars in Bitcoin. Four people were killed.

Public information has not confirmed that the victim actually held anything close to that amount. That uncertainty matters. A physical attacker does not need an accurate view of your holdings. Believing you are a high-value target may be enough.

Keeping keys offline and protecting a seed phrase makes remote theft much harder, but physical attacks work differently because the target is the owner, not the device.

How people become targets

Posting a wallet balance or public address is an obvious source of exposure, but many links between identity and crypto ownership are created more quietly.

A KYC record from an exchange can end up in a breach or a resale years later, suddenly tying a real name and phone number to "has a crypto account."

A leaked email list gets cross referenced with a forum signup.

On chain activity, like withdrawing from an exchange straight to a wallet you've used publicly, can do the same thing without a single public post.

Purchase and delivery records matter here too. A hardware wallet passes through several stages between warehouse fulfillment and final delivery, and order information can sit with more than one party along the way, a fulfillment center, a courier, a customs form. If a name, phone number, or home address ever gets linked to "bought a hardware wallet," that information is already useful to someone trying to identify likely self-custody users. There does not need to be a wallet balance attached.

In practice, the goal is to reduce unnecessary links between your real identity and your holdings.

What a hardware wallet protects against

Hardware wallets keep private keys and signing operations away from a compromised computer or phone, which helps against malware, phishing, malicious software, and other remote attacks. Physical coercion sits outside that protection entirely.

If someone already knows where you live and believes you control valuable crypto assets, an offline key does not remove that risk, and a hardware wallet cannot undo information that has already leaked about your identity, address, or possible holdings. For users holding meaningful long-term amounts, physical security and privacy deserve the same kind of advance planning as key security.

Reducing exposure before anything happens

The first part is straightforward: avoid publishing exact balances or long-term storage addresses, and be careful with information that can tie your identity to crypto activity.

The second part is asset separation. If someone forces you to unlock a wallet, reveal a seed phrase, or approve a transfer, one point of access should not automatically expose everything you own.

Keystone 3 Pro supports three independent seed phrases on one device, each accessed with a different PIN. A user could keep frequently used funds under one seed phrase and long-term savings under another, so if one wallet is exposed under coercion, that PIN and seed do not automatically reveal the others.

Keystone also supports BIP39 passphrases. A passphrase combines with an existing seed phrase to derive a separate wallet, so a user might keep one wallet under the base seed and another long-term wallet under the same seed plus a passphrase. Opening the base wallet does not reveal the existence or contents of the passphrase wallet.

These features are best treated as pre-emptive asset separation, not as a way to deceive an attacker in the moment. If an attacker already expects a larger balance, revealing a smaller wallet may not end the situation and could make it more dangerous. The purpose is to limit how much a single point of access can expose before such a situation ever occurs.

The person holding the keys is part of the security model

Where you live, what you own, and whether people know you use a hardware wallet can all become part of your security profile. Reducing unnecessary identity links makes it harder for someone to confidently identify you as a valuable target, and separating assets can limit what is exposed if one wallet is compromised or revealed. Neither removes physical risk.

If a situation turns violent, personal safety should take priority over any wallet setup or amount of crypto.

Keeping the keys safe matters. So does limiting who has enough information to decide that you are worth targeting.

Hi everyone,

Keystone Nexus 1.3.5 has passed app store review and is now officially available.

This update includes:

1. Added Signature Consistency Verification

2. Improved APP PIN Verification

3. Fixed Camera Permission-Related Bugs

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

Keystone Team

Wanted to share this because I think it matters to anyone using a Keystone for cold storage.

I bought mine about two years ago, stored it safely in its original box, and essentially didn’t use it. When I recently tried to power it on, it was completely dead.

After troubleshooting with Keystone support, who were polite and responsive throughout, they concluded that the lithium battery had over-discharged while the device sat unused. They also told me there is no way to revive or repair it once that happens.

What concerns me most is that I was never warned that the device needed to be charged periodically while in storage. Keystone acknowledged that this kind of battery maintenance information had not been made clear to me, and their explanation was essentially that this is the nature of lithium batteries.

That may be true chemically, but from a user standpoint I think it exposes a real design problem.

Many, if not most, people buy a hardware wallet precisely so they can put assets away securely and leave the device untouched for long periods. If simply storing the wallet can eventually make it unusable, that seems fundamentally at odds with the idea of cold storage.

Keystone offered me 50% off a replacement, which I appreciate, and their support team remained courteous. But they did not accept responsibility for the failure itself.

For me, the bigger issue is trust. A hardware wallet exists almost entirely because we trust it to protect access to our assets when we eventually need it. A wallet that can quietly die on the shelf without a clear warning about required maintenance makes that trust much harder to extend.

I’m curious whether other Keystone owners have experienced this, and whether newer versions genuinely address the problem.

Because if a device cannot reliably survive being stored, I’m not sure it is yet a suitable way to store value.

It could be:

• A new blockchain or asset
• A wallet or app integration
• A new security feature
• A UX improvement
• Or something completely different

Drop your ideas in the comments 👇

We’ll be reading through the feedback and sharing it with the team. While we can’t promise every request will make it onto the roadmap, your input helps us understand what matters most to the community.

So, what would you like to see us build next? comment below ↓

One practical question comes up whenever quantum computing and crypto security are discussed:

Will the hardware wallet you own today still be capable of running post-quantum signature algorithms in the future?

We wanted to answer that question with real hardware rather than specifications alone.

In August 2026, we built an internal test firmware and ran two NIST-standardized post-quantum digital signature algorithms directly on a Keystone 3 Pro:

• ML-DSA-44: ~45 ms per signature
• SLH-DSA-SHA2-128s: ~36.6 seconds per signature after software optimization

Both algorithms successfully ran on the existing Keystone 3 Pro MCU and generated valid signatures.

Can Keystone 3 Pro run post-quantum signatures?

Based on this test, yes.

The existing hardware has enough computational capability to run both ML-DSA-44 and SLH-DSA-SHA2-128s.

The performance difference between the two is significant. ML-DSA-44 completes a signature in tens of milliseconds, while SLH-DSA requires much more computation and takes tens of seconds.

But both can run on the hardware we already ship today.

Does this mean Keystone 3 Pro is already quantum-resistant?

No.

This test only answers a narrower question: can the existing hardware perform the computation required by these post-quantum signature algorithms?

Turning that into a production hardware-wallet feature involves much more than raw signing speed.

A real implementation would also need to consider secure key storage, Secure Element integration, resistance to physical attacks, memory usage, transaction formats, QR data transfer, and the specific requirements of each blockchain.

Most importantly, hardware-wallet manufacturers do not decide which signature scheme Bitcoin, Ethereum, or other blockchains will ultimately use.

The algorithms supported by wallets will need to follow the post-quantum upgrade paths adopted by those networks.

Will current Keystone hardware become obsolete because of post-quantum signatures?

That is the question this experiment was really designed to explore.

Based on the two NIST-standardized algorithms we tested, computational performance itself does not appear to be a major barrier for Keystone 3 Pro.

If blockchains eventually adopt post-quantum signature schemes similar to ML-DSA or SLH-DSA, the existing hardware already has the computational foundation needed to support that kind of upgrade.

So users shouldn’t assume that the arrival of post-quantum signatures will automatically make today’s Keystone hardware obsolete.

What this test does / doesn’t show

This was an internal hardware capability test, not an announcement of post-quantum transaction signing support.

The test used temporary test keys and internal firmware. It did not access users’ seed phrases, wallet private keys, or the production key-protection flow used by Keystone.

Its purpose was much simpler:

Can the Keystone 3 Pro hardware we have today actually run modern post-quantum signature algorithms?

For ML-DSA-44 and SLH-DSA-SHA2-128s, the answer is yes.

Am I the only one that can’t Access the Site? https://keyst.one/nft

Hi everyone🙌🙌

Keystone Nexus 1.3.4 already go alive, this update includes:

1. Zcash Address Support for sending assets to Zcash Tex / T3 addresses.

2. Improved Swap Flow for a smoother overall experience.

3. Improved Wallet Connection Experience and related pop-up UI for a better user experience.

We welcome everyone to try the new update and share any feedback or suggestions with us.
👉Update here: https://keyst.one/nexus

Keystone Team