Hardware wallet: how offline signing works

What a hardware wallet actually solves

The advice to keep significant value off a connected device is not new: it appears in Bitcoin's own security guide, which treats offline storage as basic practice for meaningful amounts. An app wallet keeps the private key on the phone. That means your key's security is ultimately the security of the device's operating system — with every app, permission and vulnerability that exists on it.

A hardware wallet changes one single thing, and it is the most important one: the private key never leaves the physical device. There is no export, no copy into the phone's memory, no path by which software on the computer can read the secret.

Everything else in the design exists to uphold that principle.

The architecture, in two halves

The point most often misunderstood: the device does not "make" the transaction. It signs a transaction someone else makes.

• The app (interface). Builds the transaction, shows balances, talks to the network. It does not have — and cannot have — the key.
• The device (custody). Holds the seed, receives the raw transaction, displays on its own screen what will be signed, waits for physical confirmation and returns only the signature.

That separation is what blocks the most common attack against software wallets: address swapping. Malicious software on a computer can alter the destination address after you paste it. If the address appears on the device's screen, which the malware does not control, the fraud becomes visible before you confirm.

That is why the screen is not a convenience detail — it is the security component.

What the device blocks, and what it does not

It blocks well:

• Remote key extraction, because the key never travels.
• Destination or amount swapping, because what will be signed is shown on a screen beyond the compromised software's reach.
• Phone OS compromise, which no longer grants access to the secret.

It does not block:

• Social engineering. If you are convinced to physically confirm a malicious transaction, the device will sign it. It protects against software, not against persuasion.
• Broad contract approvals. Confirming an unlimited allowance on a malicious contract is an action you authorized.
• Losing the recovery phrase. The seed remains the only restoration path — and remains your responsibility.
• A device tampered with at the source. Buying from an unknown reseller reintroduces the very risk the device should remove.

Self-custody does not eliminate risk; it transfers responsibility for the key to you. A hardware wallet changes where the key lives, not who answers for it.

The VKX study

VKX is studying a device of its own, with the principle above as a non-negotiable requirement: the private key never leaves the hardware. The concept turns the app, today a connected wallet, into the interface for an offline wallet as well.

Prototype elements under evaluation:

• A microcontroller from the ESP32 or STM32 family.
• A small screen, enough to validate address and amount — the component that defeats address-swap fraud.
• Physical confirm and cancel buttons, because confirmation must be a deliberate act.
• A dedicated secure element to store the key, of the kind used in smart cards. Cryptographic modules of this type are evaluated against FIPS 140-3, NIST's standard for security requirements in cryptographic modules.

Address derivation would follow the standards that already underpin the industry: BIP-39 for the recovery phrase and BIP-32 for the key hierarchy. That matters for a practical reason: a seed generated to an open standard can be restored in another compatible wallet, and the user is not locked to the manufacturer.

This is a study, not an announced product. There is no date.

When it is worth it

• Worth it when the value stored justifies an extra step per operation, and when the horizon is holding more than moving.
• Not worth it as a daily wallet: friction that protects also gets in the way, and a wallet that annoys tends to be used unsafely.
• The usual combination is the sensible one: reserves on the physical device, day-to-day value in an app wallet.

A complementary approach, limiting damage by rule rather than by hardware, is in Smart Vault.

FAQ

Can the key be extracted from the device? The design exists to prevent that: it is neither exported nor transmitted. Physical attacks with specialized equipment are a different scenario, which is why the secure element matters.

Do I need the device to see my balance? No. Checking a balance uses only the public key. The device is needed to sign.

If I lose the device, do I lose the funds? No, if you have the recovery phrase stored. The device is the safe; the phrase is the deed.

Does a hardware wallet protect me from scams? From software, yes. From persuasion, no: if you physically confirm, it signs.

Is it for sale? No. It is a technical study, with no announced date.

Next step

If your risk today is malicious software and old approvals, the measures with immediate effect are in how to protect your digital assets. The current security architecture is at security architecture.

Disclaimer: this content is informational and educational and does not constitute investment advice.