Why the iPhone Holds No Keys
Cryptograph runs on two devices: an iPhone that shows the portfolio, prepares transactions, and broadcasts them, and an Apple Watch that holds the keys and signs. The reasonable question, on first encounter, is why the work is split this way. A modern iPhone already has a Secure Enclave and a biometric sensor. Why is the watch doing the signing, and what is left for the phone to do?
The short answer is that the watch is the wallet and the phone is the interface that helps you use it. The longer answer is that nothing on the phone can sign for funds, and the rest of this post is about that absence and why it matters.
What the phone does
The iPhone is the operations layer. Concretely:
- Portfolio display. Balances, prices, sparklines, the NFT grid, transaction history. The phone has the screen and the cellular bandwidth to render these comfortably.
- Transaction composition. When you tap Send, the iPhone is what you type into. It resolves ENS names, fetches gas estimates, queries token decimals, and assembles the unsigned transaction object.
- WalletConnect session management. dApp pairings, session expiries, request queueing, the entire WalletConnect v2 stack runs on the phone.
- Network proxy. The watch does not have an independent cellular plan. The phone is the watch’s path to the chain: RPC reads, balance lookups, transaction broadcast.
- Signing-request forwarding. Anything that needs a signature, whether a self-initiated transfer or a dApp request, gets packaged on the phone and handed to the watch over Apple’s WatchConnectivity framework.
That is the phone’s role, end to end. Compose, display, forward, broadcast.
What the phone deliberately does not do
Here is what is provably absent from the iPhone side of the app:
- No mnemonic. The BIP-39 seed phrase is generated on the watch, encrypted with ChaCha20-Poly1305 using a key the watch’s Secure Enclave owns, and stored in the watch’s Keychain. The iPhone never receives it. There is no encrypted copy on the phone, no temporary cache, no backup blob, no plaintext word list at any moment.
- No Secure Enclave wallet key. The watch’s Secure Enclave holds one P-256 ECDH key whose only job is to unwrap the mnemonic on the watch. There is no equivalent key on the iPhone’s Secure Enclave. The phone’s SE is not provisioned with any wallet material.
- No chain signing keys. Bitcoin, Ethereum, Solana, and every other chain’s private keys are derived from the mnemonic in the watch’s memory at sign time, used once to produce a signature, and zeroed when the sign completes. They exist for milliseconds at a time, and never appear on the phone in any form.
- No signing capability. There is no codepath on the iPhone that produces a transaction signature. The Rust signing core is present in the watch binary; the phone binary does not link it for wallet-key use.
The iPhone holds plenty of other things. Cached balances, NFT thumbnails, recent recipients, WalletConnect session state. None of it can move a single token.
What this means under attack
Pick the worst-case smartphone compromise you can imagine. A zero-click iMessage exploit. A malicious configuration profile installed during a fake captive-portal login. A supply-chain compromise in a popular third-party app the user has granted Photos or Files access to. In every case, the attacker now has the phone.
What the attacker can do is read the public state. They can see balances, addresses, transaction history, recent recipient lists. They can compose any transaction they want and send it down the WatchConnectivity pipe to the watch as a signing request. What they cannot do is sign. The signing key does not exist on the device they have compromised. To produce a signature, the request has to arrive on the watch’s screen, the wearer has to read it, and the wearer has to tap Approve.
This is the difference between a wallet and a wallet front-end. The typical software wallet on a phone is both at once: the screen that asks for the approval and the process that produces the signature share an address space. A compromise of that process can produce signatures without the screen ever being involved. Cryptograph splits those two roles onto separate devices, and places the screen and the signing process together on the wrist. Neither of them lives on the phone.
The typical wallet-plus-hardware-signer pattern
The arrangement most security-conscious users have arrived at over the past several years looks like this: a software wallet (running as a browser extension or a desktop app) maintains session state, holds extension permissions, and connects, when a signature is needed, to a paired USB or Bluetooth signing device. The hardware device produces the signature. The software wallet broadcasts it.
That arrangement places the trust boundary between the software wallet’s host machine and the signing device. As long as the signing device is intact and the user reads the screen carefully, the keys are safe. The architectural cost is that the software wallet itself has standing capabilities. It holds extension state. It is permitted to talk to dApps. It is the layer being attacked when an attacker compromises the user’s browser or replaces a wallet extension’s served JavaScript at the CDN.
Cryptograph applies the same wallet-plus-hardware-signer pattern to a form factor where the host machine and the signing device are both on the user’s body. The watch is the signing device, the phone is the host, and the trust boundary between them is identical to the boundary in the desktop-plus-USB-signer case. The geometry is different, while the structure is the same.
There is one structural difference worth naming: dApp sessions are short-lived and rendered on the watch before each signing decision. The phone is not maintaining a long-lived custodial posture toward dApps in the way a browser extension does. It is forwarding requests, and the watch is deciding.
The honest constraint, and the answer to it
There is one thing the iPhone does that a compromised iPhone can subvert: transaction composition. When the phone assembles an unsigned transaction (token address, recipient, amount, contract calldata) it has, in principle, the ability to lie about any of those fields. A fully compromised iPhone could prepare a transaction that says Send 50 USDC to your friend in the iPhone UI but actually contains, in the raw bytes, Send 50,000 USDC to an attacker address.
This is a real concern. It is also the exact concern that drove the Bybit / Safe{Wallet} compromise in February 2025, in which hardware wallets signed delegatecall payloads that did not match what the host UI claimed they were signing. The lesson from that incident is that a signer whose only check is did the user press the button is signing whatever the host tells it to sign.
Cryptograph’s answer is that the watch decodes the raw transaction itself, from the raw bytes the phone forwarded, and renders the decoded result on the watch screen. The fields you see (token, amount, recipient, contract, function being called) are produced by the watch’s parse of the bytes the watch is about to sign. They are not relayed from the phone. The display source and the signing source are the same bytes inside the watch. If the phone composed a misleading transaction, the watch shows what the bytes actually say, and you see the discrepancy.
Approvals are treated the same way. An ERC-20 approve() call is decoded on the watch into spender, token, and amount. Unlimited approvals (MAX_UINT256 or the Permit2 equivalent) are flagged prominently. Approvals to spender addresses outside the verified contract registry get a second warning. The phone cannot present a “smart contract interaction” with opaque calldata, because the calldata is decoded by the watch before you are asked to sign.
So the iPhone, if compromised, can lie about what it is asking the watch to do, and the watch will tell you what it has actually been asked to do. You read the watch’s account before you sign.
In short
The iPhone holds no signing material. A compromised iPhone can read your balances, surface your address, and try to convince you to approve a transaction you would not otherwise approve. It cannot produce a signature. The request it sends across to the watch is decoded by the watch before you decide.
That division is what makes the architecture honest about what is being protected and where. The keys live on the watch, secured by the Secure Enclave, and the phone is the screen with cellular reach that helps you use it.
Cryptograph is available now on the App Store.
The Cryptograph Team