We build custom hardware wallet cards on NXP JCOP 4.5 P71 secure elements —supporting any blockchain protocol including non-standard cryptographic primitives that no standard smart card API supports.
Private key security is the fundamental unsolved problem of consumer blockchain adoption.Software wallets, browser extensions, and mobile apps all store private keys in environments thatare accessible to the operating system, other applications, and remote attackers. A compromiseddevice means compromised funds — and there is no recovery path.
Hardware wallets solve this by isolating private key material inside a tamper-resistant secureelement that cannot be read by the host system, even if the host is fully compromised. The NXPJCOP 4.5 P71 achieves EAL6+ Common Criteria certification — the highest level commerciallyavailable — meaning independent evaluators have verified that extracting key material iscomputationally and physically infeasible.
For blockchain projects that want to offer their users genuine security guarantees — not justsoftware-level isolation — integrating a certified secure element is not optional. It is the onlyengineering path to a product you can honestly describe as a hardware wallet.
Common Criteria certified secure element
Private keys extracted from production hardware
Flagship blockchain protocol implementations delivered
Cryptnox’s Card-Wallet-as-a-Service (C-WAAS) programme gives blockchain enterprises acomplete white-label hardware wallet solution built on the same NXP JCOP 4.5 P71 secure elementplatform that powers our own retail product line. You receive a finished, certified hardware walletcard bearing your brand — without the multi-year development timeline of building secure elementfirmware from scratch.
Every white-label card ships with our production-tested wallet applet pre-loaded and personalisedto your specifications. The card supports NFC tap-to-sign with iOS and Android, meaning yourusers can sign transactions by tapping their card to their phone — no USB cables, no dongles, nocompanion hardware required.
For blockchain protocols that require cryptographic primitives beyond the standard JavaCard API —including the RedDSA/Pallas signature scheme used by Zcash Orchard, or BLS12-381 used byEthereum 2.0 validators — we implement these via NXP SecureBox native C and integrate themseamlessly into your white-label card’s applet.
Custom branding and visual design on the physical card
Pre-loaded wallet applet supporting required blockchain protocols
NFC tap-to-sign with iOS and Android mobile phones
BIP-32/39/44 hierarchical deterministic key derivation
SDK integration with your existing mobile application
Standard JavaCard APIs expose a fixed set of cryptographic operations — ECDSA, RSA, AES, and ahandful of standard hash functions. This covers Bitcoin, most EVM chains, and Solana. But manyblockchain protocols require signature schemes, hash functions, or elliptic curve operations that theJavaCard API simply does not include, and cannot be implemented efficiently in JavaCard bytecodealone.
NXP’s SecureBox facility allows us to deploy native C code that runs directly on the P71’s ARMCortex-M33 core, inside the secure element’s trust boundary. This means we can implement anycryptographic primitive — including those designed specifically for zero-knowledge proof systems,like the Pallas curve scalar multiplication required by Zcash Orchard’s RedDSA, or the pairingoperations required by BLS12-381.
We have shipped production SecureBox implementations for three distinct blockchain protocolfamilies, with verified on-chain transaction results. Below are technical highlights from eachengagement.
256ms
signing time
✓
verified on-chain transaction
Pallas curve scalar multiplication implemented via SecureBox native C.
Ethereum 2.0 / Filecoin / Chia
1.8s
fastest signing path
45%
performance improvement over baseline
Constant-time execution throughout.
Exotic Hashes
· Keccak-256
· BLAKE2b
· BLAKE2s
· Poseidon-Stark252
· Poseidon-Mina
Every protocol below has been implemented, tested with official test vectors, and verified onproduction hardware. Where a protocol requires a SecureBox native C implementation — such asthe exotic curves and hash functions used by zero-knowledge proof systems — we have alreadydone that work and can integrate it into your custom card engagement.
Bitcoin, Ethereum, all EVM chains
Zcash Orchard shielded transactions
Ethereum 2.0, Filecoin, Chia
Ethereum address derivation, EIP-712
Zcash protocol hashing
StarkNet
Mina Protocol
Solana, Cardano and more
The dominant hardware wallet form factor — a USB device with a screen and buttons — wasdesigned for a desktop world where users manage crypto from a PC. The NFC card form factor wasdesigned for a mobile-first world where users sign transactions from their phone. The hardwaresecurity guarantees are identical; the user experience is categorically different.
For enterprises building consumer-facing blockchain products, the card form factor offers anadditional commercial advantage: the physical card is a branding surface. A white-label hardwarewallet card can carry your logo, your colours, and your product identity in the same way a paymentcard does — reinforcing brand trust every time the user reaches for their wallet.
| Feature | USB Hardware Wallet | NFC Card Wallet |
|---|---|---|
| Size | Separate device | Fits in your wallet |
| Battery | Requires charging | No battery needed |
| Connectivity | USB cable | NFC tap |
| Durability | Screen can break | No moving parts |
| Cost at scale | Higher per unit | Lower per unit |
| Mobile use | Needs adapter | Native NFC tap |
Yes, in most cases. Our feasibility evaluation process is designed to answer this question definitively before you commit to an engagement. We review thecryptographic specification of your signature scheme, assess whether it can be implemented within the P71’s computational constraints using SecureBox native C,and provide a written feasibility report with performance projections. If your protocol uses a standard elliptic curve — even a less common one — or a hash functionthat can be described mathematically, we can almost certainly implement it. The main constraint is computational time on the P71’s ARM Cortex-M33: some veryexpensive pairing operations may not achieve acceptable signing latency. We will tell you this upfront.
Minimum order quantities vary depending on the level of customisation required. For cards using an existing supported protocol with standard branding, we can workwith quantities as low as 500 units. For cards requiring a new SecureBox cryptographic implementation — where Cryptnox engineers write and validate new firmware— the development work is amortised across the initial production run, so minimum quantities are higher. We discuss MOQs and pricing structure during the initialconsultation call, once we understand your technical requirements and deployment timeline.
We provide a native mobile SDK for both iOS and Android that handles all NFC communication with the card, including the secure channel establishment, APDUcommand sequencing, and response parsing. Your application calls high-level methods — “sign this transaction payload”, “derive this address”, “verify this PIN” —and the SDK handles the low-level card communication. The SDK is delivered as a source-available library that your mobile engineering team can integrate andextend. We also provide integration documentation, a reference implementation, and engineering support during your integration sprint.
Tell us about your blockchain protocol and we will evaluate feasibility and build it on certified secure hardware.
