Frequently asked

Straight answers.

Including to the hard questions — the ones independent reviewers and security researchers ask. Where something isn't proven yet, we say so.

The project

Is this a real product or a concept page?

A real, working prototype. The photos on this site are of physical devices signing real Nostr events and real Bitcoin transactions on mainnet. It is not yet a shipping product — we're refining toward a first production run, and the early-access list takes no money: no deposits, no pre-orders, just an email.

Favilla KEY is built by Favilla Pty Ltd, an Australian company registered in Perth, Western Australia, founded by Joshua Coverley. Company registration details are published on this page's footer and verifiable against the Australian Business Register.

When can I buy one, and what does it cost?

The first production run is planned for 2026 and will be small. Pricing will be announced before anything goes on sale. The early-access list gets first allocation and the announcement first — and costs nothing to join.

Should I trust this with serious value today?

Don't trust. Verify. We hold ourselves to the same ethos Bitcoin runs on. Favilla KEY is going open source — the firmware and the client, with reproducible builds and signed release hashes, so you can compile the code, hash the result, and prove your device runs exactly what's published. A vulnerability disclosure policy comes with it.

Until then, what's on the table is working hardware, a documented architecture, and precise claims about where every key lives — every one of them written to be checked against the code the day it's public.

Security model

Where do my keys actually live?

Never in plain form, anywhere. Your Nostr key and your Bitcoin seed are stored as AES-256 ciphertext, wrapped twice: the outer key lives inside the NXP SE051 secure element, the inner key inside a separate isolated signing processor with no radios — and neither can be read out by you, by us, or by anyone who opens the device. The wrapped Nostr key is kept inside the secure element and released only to the signing processor, only while your PIN has unlocked it; the wrapped seed sits in flash and is unwrapped only by the signing processor, only in Bitcoin mode. A raw dump of the device's flash yields ciphertext and public data, nothing more.

Two PINs guard two modes, chosen at power-on: the Nostr PIN opens identity, messages and the client, with no Bitcoin surface at all; the BTC PIN — entered on the device's buttons only, with no network path that accepts it — opens Bitcoin signing, with no radio. Wrong attempts trip a hardware counter with escalating delays; after nine on the device the PIN locks, and the way back in is to wipe the device and restore from your recovery phrase. Over the network you get three attempts before remote unlock is disabled until you unlock on the device. Full architecture here.

Does the secure element sign Nostr events itself?

No, and we're precise about this where others blur it. The SE051 has no native BIP-340 Schnorr capability — no commercially available secure element we know of does. So the signature is computed on a second, isolated processor: a deliberately simple chip with no radios and no network stack that holds the key, accepts a 32-byte hash in a fixed-length command, and returns a signature. It has no command that returns the key. The Wi-Fi chip never holds it — a remote compromise of the connected side finds nothing to steal.

The honest residual is that whoever controls the connected chip can ask the signer to sign, within your on-device policy, for as long as they hold that access — and a physical power cycle removes them. Moving Schnorr fully inside a certified secure element is still a roadmap goal bounded by what silicon vendors ship; the moment a suitable part exists, this architecture is built to adopt it. How the isolated signer works.

Isn't WiFi a huge attack surface for a signing device?

A connected signer has a wider surface than an offline-only one — that's physics, not spin. Our answer is that you choose the surface:

Fully airgapped: Bitcoin signing works over QR codes alone. No WiFi, no cables, nothing to attack over a network.

Connected: when you use WiFi for the client and remote signing, the things that matter stay gated regardless — Bitcoin lives in a separate mode that never brings a radio up, every spend requires manual approval and its own PIN on the device, your keys sit on a signing processor the Wi-Fi chip cannot read, browser sessions are cryptographically paired and authenticated, and unpaired requests are rejected. A compromised network can annoy you; it can't approve a transaction on your behalf, and it can't take your key. The approval hardware is in your hand, not on the network.

What stops another device on my network from talking to my KEY?

Pairing — and the secret part of it doesn't happen over the network at all. Your phone scans the device's QR to reach it, then your browser displays a QR code and the device scans that with its camera: the pairing secret crosses the room as light. Both sides then compute a six-digit code from the negotiated session key, both screens show it, and pairing completes only when you confirm the match on the device. Anyone interfering ends up with mismatched codes.

After that, every sensitive request is individually encrypted and authenticated, with replay protection built in. Unpaired requests are rejected; the only thing a paired session can unlock is Nostr mode, with three attempts before remote unlock is disabled; and Bitcoin signing, PIN changes, seed display and factory reset exist only on the device's physical buttons. Even a fully compromised computer can only ask.

What if someone grabs the device while it's unlocked?

It defends itself. Left still while unlocked, the device arms its motion lock — the moment it's picked up, it wipes the working key from memory and demands the PIN again. No timeout to configure, no button to remember.

Honest limits: motion lock protects against the snatch-and-run. It is not a defence against malicious firmware or a sophisticated physical attacker with time and equipment — those are what Secure Boot, flash encryption, and the SE051's tamper resistance are for, and no vendor should tell you any single feature is the whole story.

What does the screen show before a Bitcoin transaction is signed?

The transaction, on hardware you trust: destination address, amount, and fee, displayed on the device's own screen before you approve — a display no browser, extension, or malware can draw over. Approval is physical buttons plus the BTC PIN. If what's on the screen isn't what you intended, you decline and nothing is signed. For a multisig wallet, the device signs only against the descriptor you registered on it.

Isn't packing a wallet, a signer, messaging, a web server and a game into one device asking for trouble?

Complexity is a real cost and we won't pretend otherwise. Three things keep it honest:

The invariants don't bend. No matter what else runs on the device, Bitcoin spending requires manual, on-device approval and a separate PIN, in a mode where no radio is ever on. CIPHER, the client, and messaging have no path around that — the signing policy is enforced in firmware, on the device, not in anything that talks to it.

Nothing else runs on it. No app store, no third-party code, no extensions. One codebase, from us, signed. The complexity that kills wallets is usually other people's code; there is none here.

You can ignore the features. Use it as a pure airgap Bitcoin signer over QR and never turn the radio on. The extra capability costs you nothing you didn't opt into.

Recovery & backup

Where does the randomness for my seed come from — and can I check it?

You choose, at setup. Two chips draws one 16×16 grid from the SE051's certified true random number generator and another from the camera sensor, shows you both, and XORs them into the board it hashes — so a flaw or a backdoor in either chip would have to beat the other one too. You can redo that arithmetic yourself in the seed verifier. Dice lets you roll a standard d6 about 99 times; the device derives your seed from a published function of those rolls, with no device secret mixed in.

The dice option exists so you don't have to take our word for anything. Because the construction is public and takes nothing from the device, you can run it yourself on an offline machine — printf '3141...' | sha256sum — and confirm the phrase the KEY showed you is the one your rolls dictate. If the firmware had lied, the hashes would not match.

The two paths are deliberately exclusive. We built a version that mixed the secure element into the dice roll and then removed it: the moment a device secret enters, you can no longer reproduce the result, which destroys the only reason to roll dice in the first place.

Could the same thing that happened to Coldcard happen here?

The honest answer is that the shape of that failure is possible on any device, including ours. Coldcard's firmware quietly used a software generator instead of its hardware chip for five years. The output looked perfect, every test passed, and nobody could tell from outside.

What we have done about it: seed generation fails closed — if the camera layer falls below its pass line, or both layers come back flat, the device stops and shows you an error rather than substituting something weaker. The seed is drawn from two independent chips XORed together and both grids are shown to you, so the Coldcard failure — one sealed source silently replaced — would have to happen in two places at once and still show you plausible grids. We removed the silent fallbacks we found elsewhere in our own code during a review prompted by that disclosure. Our seed construction is a single audited function with pinned test vectors, tested on a host machine, not just on the device. And the source is published with the first release, so the claim on this page can be checked against the code.

What none of that gives you is proof. Only the dice path does — and that is why it is there, not as a novelty for the paranoid, but as the answer to a question this industry has now had to face.

If I lose the device, do I lose my Bitcoin and my Nostr identity?

No — one recovery phrase restores both. At setup the device generates a standard BIP-39 phrase (12 or 24 words). Your Nostr identity derives from it via NIP-06 and your Bitcoin wallet via BIP-84 — so the phrase you write down once recovers your entire identity and your funds on a replacement KEY. Your Bitcoin also restores into any standard BIP-39/BIP-84 wallet, hardware or software. You are never locked into us.

Two things to keep with the words. If you use a BIP-39 passphrase — baked in at setup, or entered at each Bitcoin session — the words alone will not open that wallet: the words plus the passphrase are the backup, and the fingerprint the device shows you tells you which wallet you are in. If you use the KEY in a multisig, keep the wallet descriptor too (the device exports it as a QR): a multisig restore needs the descriptor and the other cosigners, on any device.

You can also bring an existing Nostr identity with you: importing an nsec you already own is supported — the device then runs as a Nostr-only signer, since an nsec alone carries no Bitcoin seed.

Can I export my Nostr key back out of the device?

Your recovery phrase is the export — your Nostr key derives from it (NIP-06), so the phrase in your possession means your identity is portable to anything that speaks the standard. What the device never does is hand key material to a connected computer: day-to-day, keys stay sealed and only signatures leave.

Openness & verification

Where's the source code?

The firmware and client are built to be published, with reproducible builds so you can compile from source, hash the result, and check it matches what's running on your device. Because the client is served from the firmware, verifying the firmware verifies the app too.

The public repository lands with the first release. Until it's public and independently checked, treat the product as unaudited — we do.

Has it been independently audited?

Not yet. Independent review is part of the path to release, alongside the public repository and a published vulnerability disclosure policy with a security contact. We'd rather ship later with those in place than sooner without them — a security product that asks to be taken on faith isn't one.

Are Secure Boot and flash encryption actually enabled? Is debug access disabled?

On production units, yes — and we are explicit that the units that exist today are not production units. Every production unit will leave manufacturing with Secure Boot V2 permanently enabled — the device will only run firmware signed by Favilla's RSA-3072 production keys, with the key digests burned into one-time eFuses and enforced by the boot ROM from the first instruction, every boot, for life. The air-gapped provisioning station refuses any board that isn't factory-virgin. Physical USB access doesn't help an attacker load modified firmware.

Production units additionally ship with hardware flash encryption: XTS-AES under a key unique to each unit, burned into eFuses that can never be read out — by anyone, including us. No single key exists whose compromise would expose more than one device. The isolated signing processor gets its own irreversible debug lock. These fuses are one-way, so they are burned when the firmware is final; prototype and development units don't carry them yet, but your key material is ciphertext under the secure element's and the signing processor's keys regardless — a dev unit's flash dump still yields nothing.

How do firmware updates work?

Updates will be signed, and under Secure Boot V2 the chip refuses to run anything else — an attacker can't push firmware onto your device without our signing key. Release hashes will be published so what you install can be checked independently. The signed field-update path is part of the production work, and the full update-chain details ship with the security documentation at release.

Nostr & compatibility

Do you support NIP-04 messages?

For reading, yes — you can decrypt legacy NIP-04 conversations, so old message history isn't lost. For sending, NIP-04 is opt-in only: every DM the device sends defaults to NIP-44 v2 encryption, and modern conversations ride NIP-17 gift-wrap end to end. We won't silently downgrade your privacy for compatibility, but we won't strand your history either.

Which Bitcoin wallets does the airgap mode work with?

PSBT over animated QR (the UR standard). Validated round-trip against Sparrow and BlueWallet on mainnet — real transactions, real broadcast, single-sig and multisig vaults built in both. Anything speaking standard PSBT + UR QR should interoperate; those two are the ones we've personally driven end to end and will vouch for today. The compatibility list grows as we validate more.

How is this different from the DIY signers, like the LNbits one?

Credit where due — the LNbits Nostr Signing Device and the DIY community started this category, and if you love flashing your own boards, they're great. We took a different bet: a finished product. A certified secure element instead of bare flash storage, a machined enclosure, a client served from the device, encrypted messaging, a Bitcoin wallet, and hardware you can hand to someone who's never used a terminal.

What happens if Favilla disappears tomorrow?

Your device keeps working. The client is served from the hardware itself — no app store, no cloud. By default it publishes through a relay we run, which fans your notes out to public relays, and the remote client is hosted on this site; both are replaceable from the device's settings, and if our relay goes dark the client falls through to public relays on its own. Airgap Bitcoin signing needs no network at all. Your Bitcoin seed restores into any standard wallet, your Nostr key is portable, and the source will be public. We built it so you don't need us — that's not a bug in the business model, it's the product.

CIPHER

Is CIPHER actually mining Bitcoin?

No — and anyone telling you a pocket device can mine competitive Bitcoin is selling something. CIPHER is a skill game themed on mining: you hunt hashes on the device, difficulty climbs with your score, the same dynamic Bitcoin has at the protocol level. Your best runs are signed by your device so scores can't be faked, and top scores enter a weekly draw for real sats — funded by us as a prize pool, not conjured from thin air. It's a game that pays out, not a miner. The full guide is here.

Still have questions?

Join the early-access list and ask us directly — we answer.

Get early access →