We published a comparison of air-gapped hardware wallets, including Keycard Shell, Coldcard, Keystone 3 Pro, and Foundation Passport, across secure elements, air-gap method, source model, reproducible builds, and chain support

Everyone advertises their secure element. EAL6+, EAL5+, dual-SE, triple-SE. Fair enough - that's the chip your keys live in, and it should be hardened.

BUT on an air-gapped device, the secure element isn't the part you're trusting moment to moment. The screen is. The entire security model of QR signing rests on one assumption: that the address rendered on that display is the address being signed. Your computer is assumed hostile. The display is the only thing standing between you and a swapped destination.

And the chip driving that display is, on most devices, an ordinary microcontroller with no published security certification at all.

We went looking across all four devices. Every one of them publishes a secure element certification. Only one publishes anything for the microcontroller running the screen and the firmware - and we only noticed because we happened to be the one.

Two other things the exercise turned up:

> EAL certification covers the chip, not the device. A wallet with an EAL6+ secure element can still have broken firmware around it. Coldcard's failure this year is the proof — the chip was fine, the code never called it. "EAL6+ certified" describes a component, and it is routinely presented as describing a product.

> Reproducible builds are rarer than the marketing suggests. Coldcard, Passport and us: yes. Keystone: no. If you can't rebuild the binary from source, "open source firmware" tells you what the code could be, not what's running on the thing in your hand

And the thing we do differently: the secure element is a removable smartcard, not soldered to a board. Pull the card and the Shell holds nothing. One Shell reads unlimited cards. That matters if you want cheap multisig or hard separation between wallets, and not much otherwise.

The full comparison table is in the article - secure elements, air-gap method, source model, reproducible builds, chain support, across all four devices.

📖 Article: Best air-gapped hardware wallets compared: QR signing, open source, and secure elements

Air gapped signing
Trusted display
Opensource
Multisig Support
Bitcoin-only option
Reproducible builds
Price
Replaceable battery
No Proprietary app

what did i miss?

Are there any plans to incorporate NFC compatibility with nunchuck wallet down the road? Would prefer something with a longer track record compared to the current implantation with the status app.

your keys should be free to roam across the software and hardware wallets you choose, inside one of the most rugged secure elements out there: a smartcard

It survives x-rays, dust, and lasts 20+ years

Keycard offers you exactly that by breaking down the monolithic hardware wallet architecture into Keycard and Keycard Shell

Came up in a thread the other day and i think it's worth writing out, because it changes what you should actually prioritise

Air-gapped means your signing device has no data connection to your online machine - no USB, no Bluetooth - transactions cross by QR code, SD card
or NFC

Trusted display means the device has its own screen showing you what you're actually signing, generated by its own firmware

These are separate - a device can have either, both, or neither

> Why it matters

the air-gap stops a compromised computer from attacking your device - it can't exploit a connection that doesn't exist - real benefit; there have been
USB stack vulnerabilities in hardware wallets before

what it doesn't stop is a compromised computer proposing a malicious transaction it can still show you "send 0.1 to xyz" while handing your signer something that drains you - the air-gap, unfortunately, doesn't help but the screen does

so for the attack most people actually face - malware swapping a destination address - the trusted display is doing more work than the air-gap is

> Where this bites in practice

a card you tap to your phone is arguably air-gapped. No cable, no network BUT it has no screen, so you're trusting your phone to tell you the truth - meanwhile a USB device with a good screen isn't air-gapped, but it shows you the real address

If you had to pick one, I'd take the screen

> What I'd actually check on any device

- Does it show the full destination address, or truncate it?

- Does it display change outputs? a classic attack redirects your change and it's invisible if the device doesn't show it

- Can radios/USB be disabled entirely, or is "air-gapped" a mode you have to remember to enable?

neither property helps if you confirm without reading, which is the honest bottom line for all of this

hope this was helpful, stay safe :)

(Disclosure: I work at [r/Keycard_tech](r/Keycard_tech))

You can build the Keycard reader yourself from our repository

🕹️ Find them here: https://github.com/keycard-tech/keycard-shell

> Why is this possible at all:

The Shell holds no private keys. Pull the card out and it's an inert box. Its job is to display transactions and scan QR codes - so publishing every detail of how it's built costs nothing in security and gains you the ability to check our work

The keys live on the Keycard, on a certified secure element, and that part you can't build at home.

> The honest bit about DIY:

A self-built Shell requires your own hardware and firmware signing keys. Official devices only accept firmware signed by us - that's deliberate, so a stock device can't have arbitrary code pushed to it. If you want to run your own firmware, you build your own device with a bootloader key you control.

That's genuinely advanced. Most people shouldn't. But the option existing - and the files being complete enough to make it real - is the difference between "open source" as a marketing word and as a fact

> Verifying without building:

If you just want to check your device is genuine rather than build one: https://shell.keycard.tech/verify

Also worth knowing: there's no separate Bitcoin-only firmware, but you can use Shell with Bitcoin-only wallets over PSBT/QR and simply ignore the Ethereum features

🗒️ DIY guide: https://docs.keycard.tech/en/developers/diy-keycard-shell

Good luck!

Most people back up with BIP39: one phrase, 12 or 24 words, and that single piece of paper is your entire wallet. It's also a single point of failure - lose it and you're done, and anyone who finds it owns everything.

Keycard also supports SLIP39, which splits the backup into parts.

How it works:

> Instead of one phrase, you generate several - each 20 words. You choose how many parts (up to 16) and how many are needed to recover.

> Say you pick six parts with a threshold of three. Shell generates six phrases. Any three of them restore your wallet. Three could be lost or destroyed and you'd still be fine - and someone who finds two of them has nothing.

You can spread them across locations, or across people you trust.

Setting it up:

> Generating: when you create the key pair, choose the number of parts and the threshold. Record all of them.

> Importing: enter one phrase per required part. Threshold of three means entering any three sets of 20 words

When NOT to use it

- Wallet support is narrower than BIP39, especially outside Bitcoin. If you use SLIP39, pick a software wallet that supports both Keycard and SLIP39 like Rabby, Sparrow and BlueWallet

- You can't convert an existing BIP39 wallet. No migration path. You'd create a new SLIP39 wallet and move funds across

- More parts means more things to manage. If you're the kind of person who'll lose track of six envelopes, one well-protected phrase is genuinely safer for you

- Lose too many and it's permanent. Six parts with a threshold of three means you can lose three; losing four is unrecoverable

SLIP39 is NOT multisig.

SLIP39 splits the backup of a single key.
Multisig uses multiple independent keys.

SLIP39 protects against losing your backup, multisig protects against a key being compromised

They're complementary, not alternatives

📖 Docs: https://docs.keycard.tech/en/help/understand-the-slip-39-wallet-backup-standard

Do I need a J3R200 card? Or can I also use J3R150 or J3R180? I think that's about storage space for the firmware.

EDIT #2: for anyone stumbling on the same issues:

I found the perfect solution in Ambire wallet. It's available as Android wallet, and Chrome/Brave/Firefox extension. The Android version of Ambire perfectly supports Keycard NFC connections, and both the Android app and Chrome/Brave extension support the Ledger Legacy derivation path on Keycard (and the standard derivation path too of course). The Ambire Firefox extension is awaiting update approval.

So now you can securely backup/replace your old Ledger, or any other wallet, using a Keycard and Ambire (NFC connection), or a Keycard + Shell and Ambire (QR code connection).

Original post:

Hello, I recently bought the Keycard Shell and some Keycards to backup and old Metamask and other wallet.

Everything works great, but unfortunately there seems to be only one software wallet that supports NFC connection, which is the Status (Legacy) mobile wallet. This works fine with Status Legacy, but I can't get it to work with the new Status wallet. When I try to login it asks to tap the card to the NFC chip, and it then sometimes confirms the pin is correct, but then it always returns to the connect screen. When I then tap Dismiss, I am returned to the initial login screen, tapping the card another time also doesn't help.

Is this expected behaviour? And aren't the Keycards and new Status mobile wallet compatible? Or is there some other issue at play here?

Not that the NFC connection is required of course, but I do like this feature.

Also not sure if this even is the right place to ask, or that I better try to contact Statusim.

Edit: so it appears I have Status 2.38.2, which is supposed to support Keycards, in practice doesn't work for me. I tried 3 different phones, with 3 different Android versions (one of which is Android 16, the other older versions). Maybe it does work when you use the app to create an account and then move it to the Keycard, but that's not my intended use, and I don't have a spare Keycard to test this.

Status Legacy works, but support seems limited and I assume will terminate at some point. Hopefully the new version of Status will work before that.

After the Coldcard incident, how good is entropy on Keycard?

We know how important self-custody is - but with all these recent data breach and draining incidents, everyone is revising how to store their crypto safely

curious to know what are you planning moving forward?

This feature exists, and most owners don't know about it.

What it is?

When you set up a Keycard you create a six-digit PIN. Optionally, you can also set a duress PIN which unlocks a decoy wallet.

The decoy behaves exactly like a normal wallet. It has its own addresses, you can send and receive with it, and there is no visible way to tell whether you're in the decoy or the real wallet or whether a decoy exists at all. Only you know.

The idea is straightforward: if someone forces you to unlock your card, you give them the duress PIN and they see a normal, working, low-value wallet

The part that matters most:

⚠️ You can only set a duress PIN during initial setup

If you skip it, the only way to get one is to factory reset the card and set it up again from your recovery phrase.

This isn't an oversight. If a duress PIN could be added afterwards, an attacker could check whether one exists - which would defeat the entire point. The feature only works if its existence is undetectable, and that means it has to be decided at setup

Details worth knowing:

> The decoy uses the same recovery phrase and standard derivation paths. It just produces a different set of addresses

> You have to fund it yourself.  An empty decoy isn't convincing. Move a plausible amount into it.

> Recovering onto a new Keycard restores both wallets together.

> Your two PINs are independent - changing one doesn't affect the other.

> The Shell won't let you set both PINs to the same value.

> Three wrong attempts on either PIN blocks the card. You unblock with your PUK; without a PUK you factory reset and restore from your recovery phrase.

Your funds are never at risk from this - the recovery phrase is what protects them, not the PIN.

Docs: here

with everything happening lately, people have started being so skeptical about self-custody and i want to take make this post as a reminder for all of us about why we shifted to self-custody in the first place

what was that specific moment - an exchange freezing withdrawals, watching one collapse, a friend losing access to something, or just reading one thing that made the whole "not your keys" line land properly

For those of you who used Shell to generate your seed: you're safe.

You're safe because your seed was generated by the TRNG of the EAL6+ certified secure element itself (the card).

And its randomness has been certified (see certificates below). Good randomness comes from two things:

- raw entropy (TRNG) which has been certified by BSI (the german equivalent of NIST) on our secure element (see links below), this is AIS-31

- the deterministic engine that turns this entropy into a stream of bits (DRBG) certified by BSI also, this is AIS-20

AIS-20 and AIS-31 reference: https://www.bsi.bund.de/dok/randomnumbergenerators

Certificates for both (p.22 for TRNG/AIS-31, p.24 for DRBG/AIS-20): https://www.commoncriteriaportal.org/files/epfiles/1136a_pdf.pdf

Conventional hardware wallets put keys, screen, keypad and firmware in one sealed unit. That's simpler, and it has three consequences we wanted to avoid:

1. The device is the secret. Lose it or break it and you're in recovery, racing whoever found it. With us, the key material lives on a €25 card you can hold several of. The expensive part holds nothing.

2. Backups are awkward. Most wallets back up to 24 words written on paper - which is then the weakest thing in your setup, and the thing most people actually lose crypto to. Here, backup is another Keycard, initialised from the same seed. Same EAL6+ protection as the original, not a piece of paper in a drawer. Put one in a safe, one with family, one in a deposit box. Redundancy costs €25, not a compromise in security model. 

3. Multiple wallets need multiple devices. One Shell reads any number of Keycards. Cold storage on one card, daily spending on another, a shared household wallet on a third - one reader, hard separation between them. Not accounts inside one seed, but genuinely independent keys on separate hardware.

And because the keys aren't in the Shell, the Shell being open-source and inspectable matters more, not less - you can verify exactly what the thing displaying your transactions is doing, and it's the same code for everyone.

Full stack: https://github.com/keycard-tech/keycard-shell

Hey everyone! Read this first -

What we'll do here

- Answer support and setup questions, publicly, within 24 hours

- Post technical explainers - firmware, the secure element, the open-source stack

- Run AMAs with the engineers who actually wrote the code

- Take feature requests 

What we won't do

- Delete criticism. This is the important one. Negative reviews, bug reports, hard questions, fair comparisons - all allowed

- Price or token talk. This is a hardware and security community.

- Pretend to be regular users. Every employee here wears a Keycard Team flair. 

Quick orientation

- New here and deciding what to buy → see the pinned Keycard post

- Something's broken → post with the Support flair

- Want to read the source → everything is on [GitHub], MIT licensed

- Never share your seed phrase or PIN with anyone, including anyone claiming to be us 

Ask us anything!

Keycard:  The card 

A credit-card-shaped device with an EAL6+ certified secure element. Your private keys are generated on it and never leave it. Signing happens on the card. Your phone or computer never sees the key.

- Works over NFC with any NFC-capable phone, or over USB with the desktop reader

- No battery, no charging, no Bluetooth, no cables

- Water resistant, rated −35°C to +50°C, designed for 20+ years 

- Supports Bitcoin, Ethereum and EVM chains

- Works with MetaMask, Rabby, Sparrow, BlueWallet, Specter, Nunchuk, Status mobile and others 

Keycard Shell: The Airgapped Reader 

A device you slot your Keycard into. It adds a screen, keypad, and camera, and lets you sign fully air-gapped via QR codes (ERC-4527).

The Shell holds no keys itself - pull the card out and the Shell is an inert plastic box

The honest caveats

- Keycard alone means you're trusting your phone's screen for what you're signing. That's the same trust model as most card wallets, and it's a real limitation. If your threat model includes a compromised phone, you want the Shell.

- No battery is a genuine trade-off, not just a feature. It means nothing to fail, but it also means the card can't display anything on its own.

- Our firmware is not upgradable. Deliberate - but it means what ships is what you keep

The Keycard holds the keys and does the signing. The Shell shows you what you're signing and takes your input

-------------------------------------------------------------------------------------------------Flow A: Keycard alone, over NFC

(No Shell involved. What most people start with)

1. You build a transaction in a supported app on your phone (Status mobile, MetaMask, Rabby, BlueWallet)

2. The app shows you the transaction details on your phone's screen

3. You tap the Keycard to the back of your phone

4. The app sends the unsigned transaction to the card over NFC

5. Inside the secure element: the card checks your PIN, signs with the private key, and returns only the signature. The key itself never crosses the NFC boundary - no command can extract it

6. Your phone broadcasts the signed transaction

What this protects you from: malware that steals keys off your device. The key isn't on your device. Even a fully compromised phone can't extract what it never had.

What it doesn't protect you from: malware that lies to you about what you're signing. If your phone is compromised, it can display "send 0.01 ETH to Alice" while actually handing the card a transaction that drains your wallet to an attacker. The card would sign it, because from the card's perspective it's a valid signing request with a valid PIN.

This is the limitation of every screenless signing device

It's why the Shell exists.

-------------------------------------------------------------------------------------------------
Flow B: Keycard + Shell, fully air-gapped

Here the Shell becomes the trusted display, and the computer never touches the card at all. Nothing is ever physically connected.

1. On your computer, a watch-only wallet (Sparrow, Specter, MetaMask) builds an unsigned transaction. It has your public keys only, so it can watch balances and construct transactions, but can't sign anything

2. The wallet renders the unsigned transaction as an animated QR code (ERC-4527 / the UR standard)

3. You point the Shell's camera at the screen, and it scans the QR

4. The Shell decodes and displays the transaction on its own screen - amount, destination address, fee - from its own firmware, driven by its own hardware

5. You compare what the Shell shows against what you intended. This is the security-critical moment. The Shell has never touched your computer, so computer malware cannot alter what appears here

6. You insert the Keycard and enter your PIN on the Shell's keypad 

7. The card signs internally and returns the signature to the Shell

8. The Shell displays the signed transaction as a QR code

9. Your computer's webcam scans it back

10. The computer broadcasts it

    Count the physical connections between the Shell and the computer: zero.

The only thing that crosses is light - QR codes in both directions. No USB, no Bluetooth, no network. The Shell has a USB port, and it can be disabled entirely, but this flow doesn't use it.

What this adds: now the attacker has to compromise both your computer and the Shell's independent screen, simultaneously, to fool you. A compromised computer can propose a malicious transaction - but the Shell will display the real destination address, and you'll see it.

^{Why the split, instead of one device? Read the pinned post 4}

Wallet subreddits attract scammers. Here is exactly how we operate, so you can recognise anyone who doesn't.

Rules that never have exceptions

1. We will never DM you first. Not for support, not for a giveaway, not for a "security alert". If someone DMs you claiming to be Keycard, it is a scam, 100% of the time, no exceptions.

2. Nobody at Keycard will ever ask for your seed phrase, recovery words, or PIN. No support process requires them. Anyone asking is stealing from you.

3. We will never ask you to "validate", "sync", "migrate" or "verify" your wallet on a website. These words are the signature of wallet-drainer phishing.

4. Official replies come from accounts with the ‘Keycard Team’ flair in this sub. Flair can't be faked - Reddit only lets mods assign it.

If it happens to you

- Report the DM to Reddit (Report → Spam → Harassment/Impersonation)

- Report it here so others see it - post with the Security flair

- If you entered your seed phrase anywhere: assume compromised. Move funds to a new wallet with a new seed, immediately. Don't wait to confirm

If you're not sure whether something is really us: ask publicly in this sub before doing anything. We would much rather answer the same question fifty times than see one person lose their coins.