Summary
Pocket Node is a self-custody CKB wallet that runs a full Rust light client on the device with no gateway server: the phone verifies the chain itself, holds keys locally, and builds and broadcasts transactions peer to peer. Over the last grant we shipped all four Android milestones, and the app is live at v1.8.
This proposal brings the same wallet to iOS: iPhone, iPad, and Macs (with Apple Silicon). There is no self-custody CKB light-client wallet on iOS today, so this closes a real gap in CKB’s mobile reach.
This proposal also makes Pocket Node usable by the wider ecosystem: we adds an in-app dApp browser with CCC-compatible signer, so CCC-enabled websites such as the iCKB app and other ecosystem dapps can use Pocket Node for identity and signatures. This follows the direction of the discussion in issues Pocket Node #430, Quantum Purse #119, and Neuron #3438, and it is a capability the Android app does not have today.
Project introduction
Pocket Node is already live and in daily use on Android, so it needs little introduction here. In short, it is a self-custody CKB wallet that puts a real node in the user’s pocket: the phone verifies the chain itself and holds the keys, with no server in the middle, so the wallet keeps working on its own even if our infrastructure disappears.
Across the Android grant, we delivered mainnet readiness and hardware-backed security, full Nervos DAO integration on device, multi-wallet with HD sub-accounts, transaction export, an address book, and a public launch, plus a large amount of reliability and security hardening driven by real user reports. The complete milestone-to-release mapping is in our grant completion report.
- Repository: GitHub - RaheemJnr/pocket-node: A native Android CKB (Nervos) wallet that runs an embedded light client directly on the device via JNI — full sovereignty, no remote servers. · GitHub
- Website: pocket-node.com
- Current release: v1.8.x, live on Android
Team and roles
Jr ( @Jnr6 ) is the lead developer and sole builder. Senior mobile engineer with several years of professional mobile experience, previously leading mobile teams, and a CKB community member. Jr designed, built, and shipped Pocket Node on Android end to end across all four milestones. The iOS build is the same one-person effort. The Android delivery record is the evidence that this scope is achievable solo on the stated milestones.
Current status
- What carries over: the protocol logic, the DAO math, the sync-mode model, the threat model, the UX and copy. These are designed and proven on Android, so this is not a from-scratch product.
- What has to be built: the entire SwiftUI application, iOS key storage against Keychain and Secure Enclave, the UniFFI bridge, and the CCC signer, which doens’t exist.
- What has to be rewritten: the CKB Java SDK is for JVM. Replacing it with multiplatform cryptography without breaking android.
Technical approach
One Rust core, one shared core, two native shells.
- Light client: the existing Rust light client, compiled for iOS and exposed to Swift through a UniFFI bridge. Same engine as Android, same P2P verification, same on-device storage.
- Shared core: the wallet’s business logic, including transaction building and signing, is shared between both apps rather than rewritten, so the security-critical code lives in one place, is written once, and will be audited once. The parts that are currently Android-specific are moved onto cross-platform equivalents as part of this work.
- iOS shell: I set out from the beginning to give a great mobile experience, so we will build a native SwiftUI app for the UI with hardware-backed key storage that mirrors the Android security design and Face ID or Touch ID with a PIN fallback.
- Platforms: iPhone, iPad, and Mac (Apple Silicon). Because the UI is SwiftUI, the same views target macOS natively, so Mac is a first-class build with platform-specific polish rather than only an iPad-on-Mac compatibility build.
- CCC identity and signer: an in-app dApp browser with an injected CCC-compatible signer. CCC-enabled websites get identity and signatures only; the embedded light client stays internal to the wallet, and keys never leave the device. Every signature goes through a wallet-rendered approval screen that decodes the transaction before the user confirms.
Key benefits for CKB
- Fills the mobile ecosystem gap. iOS users currently have no self-custody, server-free CKB light-client wallet. This is not another entry in a saturated category; it is the first of its kind on the platform.
- Extends CKB’s reach to the entire iPhone, iPad, and Apple Silicon Mac user base with a wallet that already exists and works on Android. The large-screen layout work will also be implemented on the Android app alongside the iOS, bringing proper tablet support with it.
- Reinforces ecosystem resilience. Core functions, including Nervos DAO deposits and withdrawals, run on-device against the embedded light client, with no reliance on a hosted frontend.
- Opens CKB dApps to mobile. The final milestone makes Pocket Node an identity and signer for CCC-enabled websites through an in-app dApp browser, so ecosystem dApps such as iCKB and other dApps become usable from the wallet,dApps keep their own light client, Pocket Node provides identity and signatures.
Deliverables and milestones
Full parity with Android v1.8 (or whatever version the android version is then), plus the CCC signer, delivered across five monthly milestones. The most important work will be done first, so any possible bugs will be caught as we go on.
Milestone 1: Shared core, iOS bridge, app skeleton
- Stand up the Multiplatform module and begin moving business logic into shared code without breaking the shipping Android app.
- Replace the CKB Java SDK with multiplatform cryptography; port molecule encoding and address handling to shared code.
- Build the Rust light client for iOS and wire the UniFFI bridge: init, start, stop, and a working query callable from Swift.
- SwiftUI app skeleton with navigation, theme, and the light client running on device.
- Acceptance: the iOS app builds, embeds the light client, and completes a testnet query end to end, while the shared core still compiles for Android unchanged.
Milestone 2: Keys, security, onboarding, receive
- iOS key storage in Keychain with Secure Enclave access control, mirroring the Android hardware-binding threat model.
- Face ID and Touch ID with a PIN fallback and lockout.
- BIP39 generation and import, backup and verification flow, onboarding in SwiftUI.
- Receive screen with address and QR.
- Acceptance: create and import a wallet on a real device, keys hardware-protected, biometric unlock working, and a real testnet receive address shown.
Milestone 3: Send, sync, and activity (the usable wallet)
- Sync engine and sync-mode model wired through the shared core.
- Send flow with cell selection, fee, on-device build and sign, and broadcast; SwiftUI send screen with validation.
- Activity history with pagination; QR scanner.
- Acceptance: a real mainnet send and receive complete on device, history and sync work, and the first TestFlight beta is live.
Milestone 4: Nervos DAO, multi-wallet, and feature parity
- Nervos DAO deposit, withdraw (both phases), and compensation tracking, reusing the shared DAO logic.
- Multi-wallet create, switch, rename, delete, and HD sub-accounts from one mnemonic.
- Background catch-up via the iOS background task scheduler, with notifications, on the foreground-first model described above.
- Address book, CSV export, settings parity, and localization parity (English, Spanish, Russian, Chinese).
- Acceptance: a DAO deposit and withdraw complete on mainnet, multiple wallets and sub-accounts work, and a feature-complete parity TestFlight beta is out, including the address book and localization.
Milestone 5: App Store launch and CCC identity and signer
- Universal iPad layout polish and a native macOS (Apple Silicon) build.
- Large-screen (tablet) layout support brought back to the Android app.
- App Store submission, review, and production launch.
- CCC identity and signer, following the direction in Pocket Node #430, Quantum Purse #119, and Neuron #3438: dApps keep their own light client, and the wallet provides identity and signatures.
- In-app dApp browser with an injected CCC-compatible signer: connect, signTransaction, and signMessage, with per-origin consent and wallet/account selection, since Pocket Node is multi-wallet.
- Signature approval screen that decodes the transaction inside the wallet, resolves inputs through the light client’s proof-checked fetch to verify amounts and the exact fee, and shows what leaves the user’s cells and where the outputs go, gated by Face ID, Touch ID, or PIN. Keys never leave the device.
- The signing and decoding core lives in the shared module, so the Android app gains the same capability on its normal release cadence (delivered there as a fast follow, not payment-gated here).
- Acceptance: the app is live on the App Store for iPhone and iPad with full Android parity (or whatever version Android is on by then), and a real transaction on a live CCC-enabled dApp (for example the iCKB web app) is connected, decoded, approved, and signed end to end inside Pocket Node on iOS, with the signature returned to the dApp and the transaction confirmed on chain. The native macOS build and the Android tablet layouts are targeted within this milestone. The App Store review and the signer are independent workstreams within this milestone: if Apple’s final approval is still pending at month end due to review queue timing alone, sign-off proceeds on the submitted build plus the completed signer, with the listing going live as soon as Apple clears it.
Budget breakdown
Total: $18,000 USD, payable in CKB, over five months.
| Payment | When | Amount | Share |
|---|---|---|---|
| Commencement | Kickoff | $2,500 | 13.9% |
| Milestone 1 | Month 1 | $3,100 | 17.2% |
| Milestone 2 | Month 2 | $3,100 | 17.2% |
| Milestone 3 | Month 3 | $3,100 | 17.2% |
| Milestone 4 | Month 4 | $3,100 | 17.2% |
| Milestone 5 | Month 5 | $3,100 | 17.2% |
Part of the initial payment funds the physical devices required to start development on iOS (an iPhone and an iPad for on-device testing of Secure Enclave, biometrics, camera, and background behaviour, none of which the simulator can validate) and the Apple Developer Program enrolment.
Out of scope and future funding
Named here so the roadmap is clear and this proposal stays honest about its boundaries:
- A single combined external security audit once both the Android and iOS codebases are complete, so one engagement covers both platforms and the shared core together. This is deliberately not funded in this grant; it belongs after iOS reaches parity.
- Quantum-resistant lock support: After getting mobile platform parity, exploring how to allow users to choose what lock to use when signing their transaction (I don’t know what shape this will take yet, but proper research will be done and communicated in due time).
- A cross-wallet CCC signer standard and cross-device transport. This proposal ships Pocket Node’s own in-app CCC signer (Milestone 5). Letting a desktop dApp talk to the phone wallet, and standardizing one signer protocol across wallets, needs agreement on transport and session security with the other wallet teams. Per the direction in the linked community discussions, dApps keep their own light client and wallets provide identity and signatures. I will pursue the standard as dedicated follow-on work together with Quantum Purse, Neuron, and the CCC maintainers. Hanseen has a plan to build this standard later.
- Deeper ecosystem integrations, connecting Pocket Node natively to other CKB projects and protocols as they mature, such as native iCKB rendering beyond the CCC dApp compatibility delivered here, Fiber, and other community tech being built.
- Fiat on-ramp and off-ramp, if and when it fits the self-custody model (I’m being optimistic here).
Risk and mitigation
- Timeline. Full parity plus the signer, solo, in five months is ambitious. Mitigation: the riskiest structural work (shared-core extraction and the Rust bridge) is in Milestone 1, so slippage is visible at the first milestone; feature parity completes in Milestone 4, leaving the final month focused on the launch and the signer; and those two are independent workstreams within Milestone 5, so a slow Apple review cannot stall the signer, nor the reverse.
- Remote signing surface. A website asking a wallet to sign is the most sensitive new surface in this proposal. Mitigation: the funded slice is the in-app browser only, so there is no relay, no network transport; the wallet decodes and displays every transaction itself before signing; signing stays behind biometric or PIN; and this surface is explicitly part of the future combined security audit.
- App Store review. Self-custody wallets are permitted, but review can be strict. Mitigation: clear self-custody framing with no on-ramp or off-ramp claims, correct encryption-compliance declaration, and time budgeted for a review round or two in Milestone 5.
- Background sync. iOS cannot sync a light client continuously in the background. Mitigation: a foreground-first model with best-effort background catch-up, communicated honestly in the app, consistent with how the Android background-sync work already sets expectations.
- Shared-core extraction touching Android. Moving logic into a shared module affects a shipping app. Mitigation: extract incrementally with the Android build kept green at every step, verified before each milestone sign-off.
Open source and distribution
The iOS app is MIT licensed and open source from the start of Milestone 1, in the same public repository, with tagged releases per milestone, matching the Android commitment. iOS distribution is through the App Store and TestFlight, but the full source and tagged releases remain public, and builds are reproducible from source where the toolchain allows.
Closing
Pocket Node proved on Android that a phone can be its own CKB node. iOS is the natural next step: the same self-custody, server-free experience for the large share of users the ecosystem cannot reach today. I welcome the community’s feedback and questions.
Also, if you’re wondering why the android app isn’t on the playstore yet, it’s largely due to the fact that, I had to upload it under an organization account, which requires some process/paper-work from my end, it took some time but it’s now under review from google.
