What I could verify The correct name appears to be Favilla KEY, with the official domain favillakey.io. The product is presented as a Perth-developed hardware signer for Nostr identity, Bitcoin transaction signing, encrypted Nostr messages, remote Nostr signing through NIP-46, and future identity/login functions. The website describes the operator as Favilla Pty Ltd and says the device is designed and assembled in Perth, Western Australia. It is still presented as being in development, with an early production model planned for 2026. Who appears to be behind it The publicly identifiable person found in earlier research was Joshua Coverley of the Perth area. Public material suggested Favilla may currently be a founder-led or very small operation rather than a large, funded hardware company. The following remained unverified from free public material: • directors or shareholders of Favilla Pty Ltd • exact ABN or ACN • funding rounds • staff beyond the apparent founder • office, factory or manufacturing facility • retail or distribution partners The hardware design The published architecture is more specific than a typical concept page. Main processor The device reportedly uses an ESP32-S3. This is a small computer chip with Wi-Fi, USB and enough processing power to run a local web interface, handle QR codes and create cryptographic signatures. Espressif provides security features such as Secure Boot and flash encryption. For a final product, Favilla would need to prove these are correctly and permanently enabled on shipping units. Secure element Favilla says it uses an NXP SE051 secure element. This is a real commercial security chip designed to protect cryptographic secrets and control access to them. However, certification of the security chip does not automatically mean the complete Favilla product has the same certification. The complete product also depends on its firmware, circuit board, update system, PIN handling and manufacturing process. Where the private keys really live This is the most important technical detail. The simplified marketing idea is that the private key is protected by the secure element. The more detailed architecture indicates that the secure element does not perform the full Nostr Schnorr signature itself. Instead: 1. The encrypted private key is stored. 2. The user enters a PIN. 3. The secure element checks the PIN and permits access to a wrapping or decryption key. 4. The ESP32 decrypts the Nostr private key into normal processor memory. 5. The ESP32 creates the signature. 6. The firmware attempts to erase the key from memory. This means the private key is protected while stored, but it may briefly exist in the ordinary memory of the ESP32 while signing. That can still be reasonably secure, but it makes firmware security, Secure Boot, memory wiping, update security and network isolation extremely important. Bitcoin key arrangement The published description says the Bitcoin seed is stored as encrypted data in ESP32 flash. The secure element controls the AES key needed to unlock it after a correct PIN. Favilla claims support for: • BIP32 wallets • BIP39 seed phrases • multiple accounts • PSBT transaction signing • QR-based air-gapped operation • Sparrow and BlueWallet compatibility These claims appeared to be developer claims rather than independently verified test results. Nostr functions The proposed Nostr implementation includes: • NIP-01 event signing • NIP-44 encrypted messages • NIP-46 remote signer or bunker mode • NIP-47 / Nostr Wallet Connect for zaps • NIP-17 gift-wrapped direct messages • future login using Nostr identity Local operation The device reportedly serves its own browser-based app over the local network. Phone or computer browser ↓ local Wi-Fi ↓ Favilla KEY web server + signer This avoids depending on an app store, browser extension or permanent company cloud service. Remote operation When left online, the device may accept encrypted signing requests through Nostr relays using NIP-46. That creates two distinct security modes: • QR mode: can operate without a live network connection • Wi-Fi mode: more convenient, but increases attack surface The screen and approval system A hardware screen and physical buttons are useful because the user can inspect what is being signed without trusting the browser alone. For this to provide real protection, the device should clearly display: • Nostr event type and content • recipient public key • zap amount • Bitcoin destination addresses • total amount • change output • fee • network Motion-lock feature Favilla says the device can detect movement after being left still, clear the working key and require the PIN again. That may help if somebody grabs an unlocked device, but it does not protect against malicious firmware, a copied key, physical tampering or an attacker who uses the device without moving it. CIPHER game CIPHER is described as a built-in game involving hash-style gameplay, signed scores and possible satoshi prizes. This does not appear to be real competitive Bitcoin mining. An ESP32 cannot compete with modern Bitcoin mining ASICs. The game may be interesting as a feature, but adding a game to the same firmware as a Bitcoin and identity signer increases complexity and attack surface. Open-source status The site has referred to open firmware and reproducible builds, but no clearly public firmware repository, hardware schematics, PCB files, bill of materials or reproducible-build process had been located during the earlier research. Until those are publicly available and independently checked, the product should be treated as unaudited. Claims that appear technically plausible • ESP32-S3 as the main processor • NXP SE051 as a secure element • QR PSBT exchange • NIP-46 remote signing • self-hosted browser interface • encrypted seed storage • motion-triggered locking • local Perth design and assembly Claims that remained unverified • signing speed • complete RAM wiping • brute-force lockout strength • production eFuse configuration • disabled debug access • reproducible builds • supply-chain security • secure update design • resistance to physical attacks • independent wallet interoperability • battery life • production readiness • delivery date • manufacturing capacity Biggest security risks 1. Wi-Fi and local web server A device handling Wi-Fi, web requests, Nostr relay traffic, QR codes and private keys has a wider attack surface than a simple offline wallet. 2. Private key in ordinary memory The Nostr private key may briefly exist in ESP32 RAM during signing. If malicious code gained control of the processor, it might capture that key. 3. Too many features in one trusted device Combining a Bitcoin wallet, Nostr signer, encrypted messaging, Wi-Fi server and game increases code size and complexity. 4. Recovery The company needs to clearly explain whether a lost device can restore both the Bitcoin wallet and the same Nostr identity, and whether the Nostr key can be exported or imported. 5. Browser and local-network security A local browser app must defend against malicious websites, DNS rebinding, cross-site requests, weak sessions, nearby network attackers and unauthorized access from other devices on the same LAN. Overall assessment No evidence was found proving the project is a scam. There were signs consistent with a real prototype: • photographs of physical devices • specific hardware components • a detailed architecture • acknowledgement that Nostr signing occurs on the ESP32 • a publicly associated person • an early-access rather than mature retail presentation However, there was not enough evidence to treat it as a proven security product: • no independent audit • no verified public source repository • no independent teardown • no shipping history • no broad user reviews • no published security disclosure program • no verified company details tied conclusively to the site Current classification A plausible early Perth hardware project with an interesting Nostr-first design, but not yet mature or independently verified enough for storing substantial Bitcoin or an irreplaceable digital identity. What it should provide before users trust it with serious value 1. Verifiable company registration and named directors 2. Public firmware and browser-app source 3. Reproducible build instructions 4. Signed firmware release hashes 5. Security architecture and recovery documentation 6. Exact secure-element configuration 7. Proof Secure Boot and flash encryption are enabled 8. Disabled JTAG and unsafe boot modes 9. Signed and rollback-protected updates 10. Independent security review 11. Vulnerability disclosure policy 12. A simpler offline-only or Bitcoin-only firmware mode 13. Clear on-device transaction verification 14. Independent teardown of a production unit