Straight answers.

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.

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.

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.

Never in plain form, anywhere. Your Nostr key and your Bitcoin seed are stored as AES-256 ciphertext, and the keys that decrypt them live inside the NXP SE051 secure element — where they cannot be read out by you, by us, or by anyone who opens the device. The secure element releases a decryption only inside a session authenticated by your PIN. A raw dump of the device's flash yields ciphertext and public data, nothing more.

Two PINs guard two levels: the daily PIN opens Nostr and watch-only Bitcoin; a separate spend PIN — entered on the device's buttons only, with no network path that accepts it — is required to sign a Bitcoin transaction. Wrong attempts trip a hardware counter with escalating lockouts; after ten, the PIN locks permanently and your recovery phrase is the way back in. Full architecture here.

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 the ESP32: the key is unwrapped inside a PIN session, exists in working memory for milliseconds, and is wiped after use.

That window is the honest trade-off of this design, and it's why the rest of the platform matters: Secure Boot so only our signed firmware runs, flash encryption burned into fuses, no third-party code on the device, and signing policy enforced by the firmware itself. Moving Schnorr fully inside a secure element is a roadmap goal bounded by what silicon vendors ship — the moment a suitable part exists, this architecture is built to adopt it.

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 — every Bitcoin spend requires manual approval and its own PIN on the device, 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. The approval hardware is in your hand, not on the network.

Pairing — and it doesn't happen over the network at all. Your browser displays a QR code and the device scans it 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, API access is restricted to local and private addresses, and the only sensitive action reachable over the network at all is a daily unlock — spending, PIN changes, seed display and factory reset exist only on the device's physical buttons. Even a fully compromised computer can only ask.

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.

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 spend PIN. If what's on the screen isn't what you intended, you decline and nothing is signed.

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. 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.

You choose, at setup. Secure element uses the SE051's certified true random number generator: instant, no effort, and you are trusting the certificate. 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.

A third path is in development: the device draws one 16×16 grid from the secure element and another from the camera sensor, shows you both, and XORs them into the board it hashes. You can redo that arithmetic yourself in the seed verifier — it is a working tool today, and the firmware that produces those two grids is not in a shipping release yet.

That second 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.

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 secure element does not answer, the device stops and shows you an error rather than substituting something weaker. 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 public, 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.

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.

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.

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.

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.

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.

Every unit leaves 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 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. Development units don't carry the flash-encryption layer, but your key material is ciphertext under the secure element's keys regardless — a dev unit's flash dump still yields nothing.

Updates are 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 are published so what you install can be checked independently. Full update-chain details ship with the security documentation at release.

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.

PSBT over animated QR (the UR standard). Validated round-trip against Sparrow and BlueWallet on mainnet — real transactions, real broadcast. 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.

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.

Your device keeps working. The client is served from the hardware itself — no app store, no cloud, nothing of ours in the loop. 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.

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.