The Apple Pay Parallel
Apple Pay is the easiest way to explain the Secure Enclave because most people already trust it with money.
When you double-click the side button on an Apple Watch and pay at a terminal, the watch is not asking a remote server whether you meant it. A local hardware boundary is involved in the decision. Apple documents that Apple Pay uses both the Secure Element and the Secure Enclave: the Secure Element holds payment applets and payment account material, while the Secure Enclave manages authentication and secure intent before a transaction is allowed to proceed.
That distinction matters. The Secure Enclave is not where every secret goes. In Apple Pay, the Secure Element and the Secure Enclave have different jobs. The Secure Element is the payment credential environment. The Secure Enclave is the local authority that confirms the wearer is present, authenticated, and deliberately approving the transaction.
Cryptograph uses the same Secure Enclave boundary for a different application. Apple Pay authorizes card payments. Cryptograph authorizes wallet signing.
What Apple Pay proves
Apple Pay has trained billions of ordinary transactions around a simple act: the user confirms intent on a personal Apple device, and value moves only after that local confirmation is accepted.
In its published architecture, Apple describes a coordinated system. The Secure Element stores and runs payment applets. The NFC controller routes contactless traffic. The Secure Enclave handles user authentication and secure intent, including the watch-side side-button gesture. For payment authorization, Apple says a payment can proceed only after the Secure Element receives authorization from the Secure Enclave.
That is the useful parallel for wallets. Apple Pay and Cryptograph use different storage layouts for different assets. Both systems make value movement depend on a hardware-isolated local decision.
With Apple Pay, that decision says: this wearer meant to pay with this card.
With Cryptograph, that decision says: this wearer saw this transaction on the watch and approved these bytes for signing.
The authorization boundary is the shared property.
What the Secure Enclave contributes
Apple’s Platform Security guide describes the Secure Enclave as a dedicated subsystem, isolated from the main processor, with its own secure boot chain, protected memory, random number generation, and cryptographic engines. It is designed for operations where the main application processor should not be the final trust boundary.
The details matter because wallet security is usually lost in the space between a promise and a mechanism. “Hardware-backed” is vague. “Secured by the Secure Enclave” is specific only if the sentence also explains what the Secure Enclave is actually doing.
In Cryptograph, the Secure Enclave owns one P-256 ECDH key used to protect the wallet mnemonic at rest. The mnemonic exists. It is generated on the watch and stored in the watch Keychain as encrypted data. The encryption layer uses ChaCha20-Poly1305 with key material derived through the Secure Enclave-owned key. The Secure Enclave key is non-extractable. The encrypted mnemonic is useless without that local hardware boundary.
The chain signing keys are different again. Bitcoin, Ethereum, Solana, and the other chain keys are derived from the mnemonic at signing time in watch memory. They are used to produce the requested signature, then cleared. They are not stored in the Secure Enclave. They are not stored on the iPhone. The iPhone has no mnemonic, no Secure Enclave wallet key, and no chain signing key.
This is why the lock framing matters. The Secure Enclave gates access to the material that can derive the wallet. It is not where the mnemonic is kept, and it is not where every chain key resides. The architecture is stronger when described precisely.
The Apple Pay difference
Apple Pay and Cryptograph should not be collapsed into one architecture.
Apple Pay is a payment network product. It provisions Device Account Numbers, payment applets, and transaction cryptograms. Apple documents those Device Account Numbers as managed by Apple Pay servers and stored in the Secure Element. A card transaction can include a one-time payment cryptogram computed by the payment applet. The issuer or payment network verifies it.
Cryptograph is a self-custody wallet. There is no card issuer verifying a cryptogram on the other side. There is no payment network account token. The watch produces blockchain signatures that public networks can verify directly. If the wrong transaction is signed, the chain will accept the signature as valid.
That makes the watch display central. Apple Pay needs a local authorization boundary before a payment credential is used. Cryptograph needs that too, and then it needs something Apple Pay does not: the watch must decode the transaction request and display the consequential fields before approval is available.
For a wallet, user intent is not just “I meant to pay.” It is “I meant to send this asset, on this chain, to this recipient, under these fees, with these contract effects.” The approval surface has to carry the details because the signature is final.
What the phone is allowed to do
Cryptograph gives the iPhone useful work, not trusted work.
The phone shows the portfolio. It composes unsigned transactions. It manages WalletConnect sessions, fetches network data, estimates fees, resolves names, and broadcasts signed transactions. Those jobs need screen space, bandwidth, and a responsive interface.
The phone does not hold signing material. A compromised phone can try to prepare a malicious request and send it to the watch. It cannot produce the signature itself.
The watch is where the approval becomes a signature. The watch receives the request, decodes the bytes it is about to sign, displays the relevant fields, and refuses requests whose consequential details cannot be shown. That is the wallet version of the Apple Pay boundary: value movement requires local confirmation on the device that owns the hardware gate.
There is a practical reason this belongs on the watch. A watch is usually on the body, locked by wrist detection and passcode policy, and present at the moment of approval. The user does not need to retrieve a separate signing object from a drawer. The signing surface is already there, and the Secure Enclave boundary is already part of the device.
What is specific to wallets
Cryptograph adds wallet-specific machinery above the Secure Enclave.
It uses a BIP-39 mnemonic because blockchain wallets need deterministic recovery and BIP-32 derivation across chains. That mnemonic is not handed to the user as a word list during normal onboarding. Recovery is handled through two distinct options: a Recovery Sheet, which is an encrypted QR code printed on paper, and Photo Backup, which hides encrypted recovery data inside ordinary JPEG photos. They are separate methods. Both preserve the important property that the user is not typing a word list into a random computer.
It supports multiple networks, each with its own signing rules and transaction formats. That means the watch cannot simply show “approve” and rely on the phone’s summary. The watch must understand enough of each request to show what matters. A token transfer, an allowance, a delegation, a Solana instruction, and a Zcash flow do not carry the same risk fields.
It also treats the phone as part of the threat model. The phone is allowed to be useful and even compromised. The boundary is drawn so that compromise does not become signing authority.
Apple Pay does not need those wallet-specific layers. It has its own network, provisioning, credential, and cryptogram model. Cryptograph needs mnemonic protection, deterministic key derivation, chain-specific parsing, and display-bound approval.
The shared lesson is simpler than the implementation. Keep the valuable decision inside a local hardware boundary, and make the user action specific enough to mean something.
The line worth keeping
“Secured by the Secure Enclave, the same coprocessor that secures Apple Pay” is a useful sentence because it points at a real hardware primitive people already trust.
The careful version is this: Apple Pay uses the Secure Enclave to authorize payment credentials held in the Secure Element. Cryptograph uses the Secure Enclave to secure the wallet mnemonic on the watch and to keep signing authority behind a local hardware gate. Apple Pay moves card value after a secure local authorization. Cryptograph signs blockchain transactions after the watch displays and approves the bytes being signed.
The same coprocessor is applied to a different asset, under the same standard for the moment that matters: value should not move until the device on your body confirms that you meant it.
Cryptograph is available now on the App Store.
The Cryptograph Team