[DIS] Mobile-Ready CKB Light Client (Pocket Node) for Android

CKB Community Fund DAO
,
1

Link to VOT page: https://dao.ckb.community/landing?method=share&thread=67494&refer_id=51416

1. Summary

This proposal requests a grant to complete and launch Pocket Node, a mobile-first light wallet for Nervos CKB that enables users to securely manage CKB directly from their Android devices. Unlike existing solutions that depend on remote RPC nodes, Pocket Node embeds the official CKB Light Client natively via Java Native Interface (JNI), giving users true self-sovereignty while maintaining mobile performance.

The wallet features secure on-device key management (private keys never leave the device), full transaction lifecycle support, QR code scanning, flexible sync modes, and a modern Material 3 UI built with Jetpack Compose.

The project has already delivered a functional wallet (v1.0.1) and seeks funding to complete mainnet readiness, implement BIP39 mnemonic support, add biometric authentication, and add more features.

Grant Amount Requested: $15,000 USD (payable in CKB)
ETA to Completion: 4 months after approval
CKB Wallet / Funding Address: To be provided

2. Project Introduction

What problem are you solving?

The Nervos CKB ecosystem currently lacks a mobile wallet solution that combines:

  1. True self-custody: Most mobile wallets rely entirely on remote RPC nodes, creating trust dependencies and potential single points of failure

  2. Embedded light client: No existing CKB mobile wallet runs the official light client directly on-device

  3. Native Mobile Experience: Current CKB wallet options are primarily web-based or desktop-focused; Pocket Node is built from the ground up as a native Android application using Jetpack Compose and Material 3, providing the responsive, intuitive experience mobile users expect.

Pocket Node addresses all three by embedding the official CKB Light Client via JNI directly into an Android application. This means users can verify their state without trusting any third-party infrastructure while enjoying a polished, native mobile experience.

Why Now?

  1. Light Client Maturity: The official CKB Light Client (RFC 44/45) has reached stability, making embedded mobile integration viable

  2. JNI Bridge Complete: We’ve successfully bridged the Rust light client to Android via JNI, proving technical feasibility

  3. Mobile-First Era: Most crypto users interact primarily through mobile devices; CKB needs competitive mobile tooling

3. Team & Roles

Jr (@Jnr6)
Role: Lead Developer
Background:

Senior mobile software developer with 4+ years of professional Android/Kotlin experience. Led mobile teams at Nexatrode (2021–2024) building disaster recovery and ML-powered language learning apps.

Most recently at MonarkTek IO (2025) shipped an AI-powered app that connects service providers to clients with on-device ML models, sentiment analysis, and social features. Experienced in embedding ML/native code directly into mobile apps, the same approach was used for this project’s JNI light client integration.

Motivation for building on CKB:
CKB’s design around verification, flexibility, and decentralization aligns strongly with the idea of empowering end-users to run verifiable clients directly on their personal devices, and I have been a member of the CKB community for 5+ years (2021).

4. Current Status

  • Research completed on the feasibility of running CKB Light Client on Android

  • Prototype implemented:

    • Light client runs on real Android devices (Arm64)

    • Connects to CKB Mainnet P2P network

    • Syncs headers and tracked scripts

    • Persists state across app restarts

  • Storage backend migrated from RocksDB to SQLite

  • Binary size and build complexity significantly reduced

  • Early testing distributed via Firebase App Distribution (open testing on Play Store soon)

  • Feedback received from early testers in the CKB community

This is a working prototype, not yet a polished production release.

Ps: Screenshot below

Planned features

  • BIP39 Mnemonic Support: Secure seed phrase generation, backup, and recovery flow.

  • Biometric Authentication: Fingerprint/face unlock with PIN/password fallback.

  • Mainnet Support: Production-ready mainnet configuration and comprehensive testing.

  • Nervos DAO Integration: Deposit/withdraw CKB, track compensation, view APY, and unlock timers.

  • Multi-Wallet Management: Create, import, and switch between multiple wallets with labels.

  • Transaction Export: Export transaction history and backup features.

  • Advanced Balance Tracking: Analytics and detailed balance visualization.

  • Address Book & Labels: Save contacts, label addresses, and add transaction notes.

5. Application Design

5.1 Functional Overview

Key Actions:

  1. Wallet Creation/Import—Generate random private key or import existing hex

  2. Balance Check — Query embedded light client for cell balance

  3. Send Transaction — Build transaction locally, sign on-device, broadcast via light client

  4. Receive — Display address with QR code for scanning

  5. Monitor — Track transaction confirmations and node sync status

On-chain vs Off-chain:

  • On-chain: All transactions, cell data, balance verification

  • Off-chain: Key storage (EncryptedSharedPreferences), UI state, user preferences

5.2 Architecture & Design

Core components:

  • CKB Light Client core (Rust)

  • SQLite storage backend

  • Android NDK / JNI bridge

  • Android app

Key CKB features used:

  • Light client protocol

  • Script-based indexing

  • Standard P2P networking

All core components are intended to be open-sourced, with clear separation between:

  • protocol logic

  • storage

  • platform-specific bindings

5.3 Design Rationale

Why embedded light client instead of remote RPC?

We chose an embedded light client because:

  1. Self-sovereignty — Users verify their state without trusting third parties

  2. Resilience — No dependency on external infrastructure

  3. Privacy — No external server sees your queries

  4. CKB Philosophy Alignment — Matches CKB’s emphasis on true ownership

Security Considerations:

  • Private keys encrypted with AES256-GCM via Android Keystore

  • Keys never transmitted; all signing happens locally

  • Even if the embedded node were compromised, funds remain safe (can only lie about state, cannot sign)

Trade-offs:

  • Higher storage requirement (5 MB for light client data based on current mainnet usage)

  • Initial sync time required (instant for new accounts, longer for accounts with existing history)

  • Battery usage during active sync

5.4 Fee Model & Sustainability

This project is infrastructure-focused and does not introduce fees directly.

Sustainability paths include:

  • Adoption by wallet teams

  • Integration into developer tooling

  • Follow-up grants for maintenance or extensions

  • Potential sponsorships from ecosystem projects

6. Key Benefits for CKB

  • Mobile decentralization: Enables users to verify CKB data directly on their phones and interact directly with the p2p network with no additional trust assumptions

  • Developer enablement: Wallet and app developers can build mobile apps without centralized RPC dependencies

  • Ecosystem growth: Unlocks new mobile-first use cases (wallets, games, P2P apps)

  • Infrastructure improvement: Demonstrates a viable path for mobile light clients and mobile-native applications on CKB

  • True Self-Custody: Demonstrates CKB’s self-sovereign principles with embedded verification

Long-term vision: Thousands of lightweight “pocket nodes” enabling self-sovereign verification for mobile users, reducing dependency on centralized infrastructure providers while providing a seamless native mobile experience.

7. Detailed Deliverables & Milestones.

The funding covers 4 months of focused delivery across four clear phases. An initial 10% down payment is received at the commencement of the grant. The app will be updated on the Google Play Store and alternative distribution channels (GitHub Releases, F-Droid) every two weeks to ensure continuous delivery and community feedback integration.

Milestone 1: Mainnet Ready & Hardware-Backed Security (Month 1) — 22.5% of grant

  • Production Configuration: Complete mainnet network support with production-grade cell dependencies and bootnode configurations.

  • BIP39 Secured by TEE: Implement BIP39 mnemonic generation with encryption keys stored in Android’s Hardware-backed Keystore (TEE/StrongBox) to ensure the seed never leaves the device’s secure enclave.

  • Biometric & Fallback: Deployment of Android BiometricPrompt for fingerprint/face unlock, with a dedicated PIN/password fall-back mechanism.

  • Verification: Comprehensive testing on mainnet with real transactions and failure-state handling (e.g., interrupted sync recovery).

  • Releases: v1.1.0 (Week 2), v1.2.0 (Week 4)

Milestone 2: Nervos DAO Protocol Integration (Month 2) — 22.5% of grant

  • DAO Transaction Builder: Develop or extend the transaction builder logic to handle specialized DAO outputs (Deposit, Withdrawal, Unlocking) currently missing from standard JNI interfaces.

  • DAO Lifecycle Management: Build the withdrawal flow handling the complex two-phase unlock process (withdraw → wait for maturity → unlock).

  • In-App Economics: Implement real-time compensation tracking and APY calculation by querying header information for maturing deposits.

  • Visualization: Build the DAO dashboard showing lock countdown timers and maturity status.

  • Testing with various deposit amounts and lock periods

  • Releases: v1.3.0 (Week 6), v1.4.0 (Week 8)

Milestone 3: Multi-Wallet and Sync Optimization (Month 3) - 22.5% of grant

  • Secure Multi-Account Storage: Build a modular storage architecture allowing users to manage, label, and switch between multiple independent key pairs.

  • SQLite Performance Tuning: Optimize the SQLite storage layer (indexing and batching) to handle increased script-filtering overhead caused by multiple concurrent wallets.

  • Advanced Analytics: Implement transaction export (CSV/JSON) and advanced balance tracking by indexing historic cell data.

  • Verification: Stress testing of the “Embedded Node” with multiple active script filters on mid-range Android hardware.

  • Releases: v1.5.0 (Week 10), v1.6.0 (Week 12)

Milestone 4: Address Book, Polish & Launch (Month 4) - 22.5% of grant

  • Security Review: Conduct an internal security audit focusing on JNI memory safety and Keystore implementation to eliminate potential vulnerabilities before public launch.

  • Identity & Contacts: Implement a local address book with custom labels and smart suggestion during the send flow.

  • App Store Excellence: Finalize UI/UX refinements based on beta feedback and optimize the Google Play Store listing (SEO, screenshots, localized descriptions).

  • Community Launch: Full documentation release (User Guide + Developer JNI Docs) and project completion report for the DAO.

  • Releases: v1.7.0 (Week 14), v2.0.0 Final (Week 16)

Post-Grant Maintenance Schedule

Following the v2.0.0 final release, a 3-month stabilization period is provided following this grant to ensure production stability.

  • All bug fixes related to features delivered in Milestones 1- 4

  • Address non-critical bugs and edge cases discovered during wider adoption

  • Performance optimization based on real-world usage patterns

  • Security patches as necessary

  • Urgent Android OS compatibility fixes

  • User support via GitHub issues and community channels

  • Emergency hotfixes for critical issues

  • Preparation of handoff documentation for long-term maintenance

  • End-of-grant report with stability metrics and recommendations

Not covered (requires future funding):

  • New feature development

  • Major architectural changes

  • Integration with new CKB protocol features

8. Budget Breakdown.

Total Request: $15,000 USD (payable in CKB)

The cost is broken down by milestone and reflects 4 months of developer work.

Milestone Amount
Grant Commencement (10%) $1,500
Milestone 1: Mainnet & Security $3,375
Milestone 2: Nervos DAO Integration $3,375
Milestone 3: Multi-Wallet and Sync Optimization $3,375
Milestone 4: Address Book, Polish & Launch $3,375
Total $15,000

10. Out-of-Scope / Future Funding Needs.

The following items are not included in this proposal and will require separate follow-up proposals:

Item Notes
iOS version Swift/SwiftUI implementation with the same feature set
Security audits External audit of cryptographic code
Feature upgrades UDT support, RGB++ support, CCC integration, CKB DID integration
Long term maintenance Bug fixes, OS compatibility updates, etc. that are outside the maintenance period mentioned above following the final release.

11. Risk & Mitigation.

Risk Mitigation
Light client stability issues Close collaboration with Nervos team; fallback to gateway mode
Security vulnerabilities Professional audit; proven libraries (CKB SDK, Android Keystore)
Google Play rejection Follow all crypto wallet guidelines; prepare alternative distribution
Resource constraints Clear milestones; scope management; community support
Low adoption Focus on UX and community engagement; integrate with ecosystem apps
CKB network changes Monitor upgrades; maintain compatibility layer

12. Closing / Call to Action

Pocket Node represents an opportunity to bring true self-sovereign CKB access to mobile users. By embedding the official light client directly into an Android app, we’re building infrastructure that aligns with CKB’s core philosophy of ownership and verification.

The project has already demonstrated technical feasibility with a working wallet. This funding will enable us to complete mainnet readiness, implement industry-standard security features (BIP39, biometrics), and conduct a thorough testing before public launch.

I believe mobile accessibility is crucial for CKB’s growth, and I’m committed to delivering a wallet that the community can be proud of.

I welcome your questions, feedback, and suggestions. Thank you for considering this proposal!

1. 标题

[DIS] 面向安卓系统的移动端就绪型CKB轻客户端（“Pocket Node”）

2. 摘要

本提案申请资助以完成并发布Pocket Node——一款专为Nervos CKB设计的移动优先轻钱包，支持用户直接通过安卓设备安全管理CKB。与依赖远程RPC节点的现有方案不同，Pocket Node通过Java本机接口（JNI）原生嵌入官方CKB轻客户端，在保持移动端性能的同时赋予用户真正的自主权。

该钱包具备设备端安全密钥管理（私钥永不离机）、完整交易生命周期支持、二维码扫描、灵活同步模式，并采用Jetpack Compose构建的现代Material 3界面。

项目已交付功能版钱包（v1.0.1），现寻求资金支持以完成主网就绪准备、实现BIP39助记词支持、添加生物识别认证及扩展更多功能。

申请资助金额：15,000美元（以CKB支付）

预计完成时间：获批后4个月

CKB钱包/资金地址：待提供

3. 项目介绍

您要解决什么问题？
Nervos CKB生态系统目前缺乏兼具以下特性的移动钱包解决方案：
真正的自主保管——多数移动钱包完全依赖远程RPC节点，形成信任依赖关系并存在潜在单点故障风险
内置轻量客户端——现有CKB移动钱包均未在设备端直接运行官方轻量客户端
原生移动体验——现有CKB钱包方案多为网页端或桌面端；Pocket Node采用Jetpack Compose与Material 3从零构建为原生安卓应用，提供移动用户期待的响应式直观体验。

Pocket Node通过JNI将官方CKB轻客户端直接嵌入Android应用，同时解决上述三大痛点。这意味着用户无需信任任何第三方基础设施即可验证自身状态，同时享受精良的原生移动体验。
为何选择此刻？

轻客户端成熟度——官方CKB轻客户端（RFC 44/45）已达稳定阶段，为嵌入式移动集成奠定基础
JNI桥接完成——我们成功通过JNI将Rust轻客户端与Android对接，验证技术可行性
移动优先时代——多数加密用户主要通过移动设备交互；CKB亟需具备竞争力的移动端工具

4. 团队与角色

Jr (@Jnr6)
角色：首席开发者
背景：
资深移动软件开发者，拥有4年以上专业Android/Kotlin开发经验。曾于Nexatrode（2021-2024）领导移动团队开发灾难恢复及机器学习驱动的语言学习应用。
近期任职于MonarkTek.IO（2025），成功发布基于AI的应用程序，通过设备端机器学习模型、情感分析及社交功能连接服务提供商与客户。擅长将机器学习/原生代码直接嵌入移动应用，此项目采用的JNI轻量级客户端集成即运用相同技术路径。
选择基于CKB构建的动机：
CKB围绕验证机制、灵活性与去中心化构建的设计理念，与赋能终端用户在个人设备上直接运行可验证客户端的愿景高度契合。本人作为CKB社区成员已逾五年（2021年至今）。

5. 当前进展

  • 已完成CKB轻客户端在Android平台运行的可行性研究

** 原型实现：**

  • 轻客户端可在真实Android设备（Arm64架构）运行

  • 连接至CKB主网P2P网络

  • 同步区块头与追踪脚本

  • 支持应用重启后状态持久化

  • 存储后端从RocksDB迁移至SQLite

  • 二进制文件体积与构建复杂度显著降低

  • 早期测试通过Firebase应用分发平台进行（即将开放Google Play商店测试通道）

  • 已收集CKB社区早期测试者反馈 ##SC内容置于此处下方

此为可运行原型，尚未达到精炼的正式发布版本。
规划功能

  • BIP39助记词支持：安全种子短语生成、备份及恢复流程。
  • 生物识别认证：指纹/面部解锁，支持PIN/密码备用方案
  • 主网支持：生产级主网配置与全面测试
  • Nervos DAO集成：存取CKB、追踪补偿、查看年化收益率及解锁计时器
  • 多钱包管理：创建、导入并通过标签切换多个钱包。
  • 交易导出：导出交易记录及备份功能。
  • 高级余额追踪：数据分析与详细余额可视化。
  • 地址簿与标签：保存联系人、标记地址及添加交易备注。

6. 应用程序设计

6.1 功能概述

核心操作：

  1. 钱包创建/导入——生成随机私钥或导入现有十六进制密钥
  2. 余额查询——通过内置轻客户端查询单元余额
  3. 发送交易——本地构建交易，设备端签名，通过轻客户端广播
  4. 接收交易——显示带二维码的地址供扫描
  5. 监控——追踪交易确认状态及节点同步状态

链上与链下：

  • 链上：所有交易、单元数据、余额验证
  • 链下：密钥存储（加密共享首选项）、界面状态、用户偏好

6.2 架构与设计

核心组件：

  • CKB轻客户端核心（Rust语言）

  • SQLite存储后端

  • Android NDK/JNI桥接

  • Android应用

核心CKB特性：

  • 轻量级客户端协议

  • 脚本化索引机制

  • 标准P2P网络协议

所有核心组件均计划开源，并严格分离：

  • 协议逻辑层

  • 存储层

  • 平台绑定层

6.3 设计依据
为何选择嵌入式轻客户端而非远程RPC？
我们选择嵌入式轻客户端基于以下原因：

  1. 自主主权——用户无需信任第三方即可验证自身状态
  2. 弹性——不依赖外部基础设施
  3. 隐私——外部服务器无法窥见您的查询
  4. 契合CKB理念——与CKB强调真实所有权的核心理念相契合
    安全考量：
  • 私钥通过Android密钥库采用AES256-GCM加密
  • 密钥永不传输；所有签名操作均在本地完成
  • 即使嵌入式节点遭入侵，资金仍安全无虞（攻击者仅能伪造状态，无法执行签名）
    权衡因素：
  • 存储需求较高（基于当前主网使用情况，轻客户端数据需5MB）
  • 初始同步耗时（新账户即时完成，有历史记录账户耗时较长）
  • 主动同步期间耗电

6.4 费用模型与可持续性
本项目聚焦基础设施建设，不直接引入费用机制。
可持续性路径包括：

  • 钱包团队的采用

  • 集成至开发者工具链

  • 后续维护或扩展的资助计划

  • 生态项目潜在赞助

7. CKB的核心优势

  • 移动去中心化：用户可在手机端直接验证CKB数据，无需额外信任假设即可直接与点对点网络交互

  • 开发者赋能：钱包及应用开发者可构建无需中心化RPC依赖的移动应用

  • 生态扩张：释放全新移动优先用例（钱包、游戏、点对点应用）

  • 基础设施优化：为CKB上的移动轻客户端及原生移动应用开辟可行路径

  • 真正自主保管：通过内置验证机制践行CKB的自主主权原则

长期愿景：数千个轻量级“口袋节点”为移动用户提供自主验证能力，减少对中心化基础设施的依赖，同时提供无缝的原生移动体验。

8. 详细交付成果与里程碑

本轮资助涵盖为期4个月的专项交付，分为四个明确阶段。项目启动时将收到10%的首付款。应用程序将每两周在Google Play商店及替代分发渠道（GitHub发布版、F-Droid）进行更新，以确保持续交付并整合社区反馈。
里程碑1：主网就绪与硬件级安全保障（第1个月）——拨款总额的22.5%

****生产环境配置：完成主网支持，包含生产级单元依赖关系及启动节点配置。

  • TEE加密的BIP39：实现BIP39助记词生成，加密密钥存储于Android硬件级密钥库（TEE/StrongBox），确保种子密钥永不离开设备安全区域。
  • 生物识别与备用方案：部署Android BiometricPrompt实现指纹/面部解锁，配备专用PIN/密码备用机制。
  • 验证测试：在主网环境下进行真实交易全面测试及异常状态处理（如中断同步恢复）。
  • 版本发布：v1.1.0（第2周），v1.2.0（第4周）

里程碑2：Nervos DAO协议集成（第2个月）——占资助总额的22.5%

  • DAO交易构建器：开发或扩展交易构建器逻辑，以处理当前标准JNI接口中缺失的专用DAO输出（存款、取款、解锁）。
  • DAO生命周期管理：构建取款流程，处理复杂的两阶段解锁过程 （提现→等待到期→解锁）。
  • 应用内经济机制：通过查询即将到期存款的头部信息，实现实时补偿追踪与年化收益率（APY）计算。
  • 可视化界面：构建显示锁仓倒计时与到期状态的DAO仪表盘。
  • 测试场景：涵盖不同存款金额与锁仓周期
  • 版本发布：v1.3.0（第6周），v1.4.0（第8周）

里程碑3：多钱包与同步优化（第3个月）——占资助总额的22.5%

  • 安全多账户存储：构建模块化存储架构，支持用户管理、标记及切换多个独立密钥对。
  • SQLite性能调优：优化SQLite存储层（索引与批处理），以应对多钱包并发运行导致的脚本过滤开销增加。
  • 高级分析功能：实现交易导出（CSV/JSON）及通过索引历史单元数据实现高级余额追踪。
  • 验证环节：在中端安卓硬件上对搭载多个活跃脚本过滤器的“嵌入式节点”进行压力测试。
  • 版本发布：v1.5.0（第10周），v1.6.0（第12周）

里程碑4：通讯录功能完善与上线（第4个月）——占资助总额的22.5%

  • 安全审查：开展内部安全审计，重点检查JNI内存安全与密钥库实现，在公开发布前消除潜在漏洞。
  • 身份与联系人：实现本地通讯录功能，支持自定义标签及发送流程中的智能建议。
  • 应用商店优化：根据测试反馈完善UI/UX设计，优化Google Play商店页面（SEO、截图、本地化描述）。
  • 社区发布：完整文档发布（用户指南+开发者JNI文档）及DAO项目完成报告。
  • 版本发布：v1.7.0（第14周），v2.0.0最终版（第16周）

项目终止后维护计划
v2.0.0最终版本发布后，本项目将提供为期3个月的稳定期以确保生产环境稳定性：

  • 修复里程碑1-4阶段所有功能相关的缺陷
  • 处理大规模应用中发现的非关键缺陷与边界案例
  • 基于实际使用模式进行性能优化
  • 必要的安全补丁
  • 紧急Android系统兼容性修复
  • 通过GitHub问题跟踪与社区渠道提供用户支持
  • 关键问题的紧急热修复
  • 长期维护的交接文档准备
  • 包含稳定性指标与建议的项目终期报告

未涵盖内容（需后续资金支持）：

  • 新功能开发
  • 重大架构变更
  • 与CKB协议新功能的集成

9. 预算明细

总申请金额： 15,000美元（以CKB支付） 成本按里程碑划分，涵盖4个月的开发工作。

里程碑 金额
资助启动（10%） 1,500美元
里程碑1：主网与安全 3,375美元
里程碑2：Nervos DAO集成 3,375美元
里程碑3：多钱包与同步优化 3,375美元
里程碑4：通讯录功能、完善与上线 3,375美元
总计 15,000美元

10. 范围外/未来资金需求

下列事项未包含在本提案中，需另行提交后续提案：

项目 备注
iOS版本 采用Swift/SwiftUI实现，功能与当前版本一致
安全审计 加密代码外部审计
功能升级 UDT支持、RGB++支持、CCC集成、CKB DID集成
长期维护 最终版本发布后超出上述维护期范围的漏洞修复、操作系统兼容性更新等。
  1. 风险与缓解措施
    |风险|缓解措施|
    | — | — |
    |轻客户端稳定性问题|与 Nervos 团队紧密协作；切换至网关模式|
    |安全漏洞|专业审计；采用经过验证的库（CKB SDK、Android Keystore）|
    |Google Play审核失败|遵循所有加密钱包指南；准备替代分发方案|
    |资源限制|明确里程碑；范围管理；社区支持|
    |采用率低|聚焦用户体验与社区互动；与生态系统应用集成|
    |CKB网络变更|监控升级；维护兼容性层|

12. 结语/行动号召

Pocket Node 为移动用户提供了真正自主掌控CKB的契机。通过将官方轻量级客户端直接嵌入安卓应用，我们正在构建与CKB核心理念——所有权与验证机制——相契合的基础设施。

该项目已通过可运行的钱包验证了技术可行性。本轮融资将助力我们完成主网就绪准备，实现行业标准安全特性（BIP39、生物识别），并在公开发布前进行全面测试。

我坚信移动端可及性对CKB发展至关重要，并致力于打造令社区引以为傲的钱包产品。

欢迎提出问题、反馈与建议。感谢您审阅本提案！

Images:

image
image697×1280 55.1 KB

image
image623×1280 113 KB

image
image668×1280 78.2 KB

image
image659×1280 45 KB

image
image738×1280 57.4 KB

37 Likes
2

Hi Jnr6,

Quick note: per Community Fund DAO norms, please add a bilingual version of the proposal (EN + CN) in the same thread, so both communities can review and discuss with the same context. Thanks.

小提醒：按 Community Fund DAO 的惯例，请在同一帖内补充中英文双语版本 （英文 + 中文），方便社区对齐信息与讨论。感谢。

Moreover, moved this proposal into the appropriate Community Fund DAO category so the discussion and tracking follow the DAO process.

此外， 已将本提案移动到 Community Fund DAO 对应分类下，方便后续按 DAO 流程集中讨论与跟踪。

3 Likes
3

Hi Jnr6, the work you’ve already done on this wallet and what you have planned for the funding you requested sounds very fair, good luck mate!

3 Likes
4

Hi @zz_tovarishch I just made the corrections.

1 Like
5

Thank you @Yeti

1 Like
6

I do appreciate your effort on making Light Client run on Android and I’ve been supporting your work for a long time, but I can’t stress enough how I dislike this pattern:

  • We reinvent the wheel with in-wallet protocols, like NervosDAO
  • Later on we evaluate how we might be compatible standard DApps, like nervdao.com

BTW this wallet will likely NOT even be able to vote in Community DAO v1.1, cause either:

  • You stick with the basically outdated SECP256K1/blake160 then you can use awful legacy binding like Neuron in CommunityDAO v1.0.
  • Otherwise, you use our golden Quantum Resistant Lock, but then for voting on Community DAO 1.1 you’ll need the CCC integration.

Conversely, in my eyes the way to go is:

  • We create a wallet that is CCC enabled, Light Client enabled, Quantum Resistant
  • Users use standard DApps (such as nervdao.com) to interact with protocols

Also, do we really need yet another wallet? For example, have you considered joining forces with Quantum Purse?

Again, I do appreciate your effort on making Light Client run on Android and I’ve been supporting your work for a long time, so please explore alternatives that ensure you are compensated for your valuable work.

Love & Peace, Phroi

11 Likes
8

Why do you consider secp256k1 outdated?

Btw it’s possible to do passkey encryption of secp256k1 keys, in this case it should be possible to vote directly and keep things user friendly.

3 Likes
9

Pretty sure we talked about this with @quake in a mail dated Jan 22, 2025.

In short, secp256k1 relies on sighash_all, which uses the same approach as Bitcoin’s pre-SegWit SIGHASH: the inputs spent amount is not included in the hash. Bitcoin fixed this by introducing BIP143, which implements a stronger hashing method.

More recently this has been addressed in Quantum Resistant Lock by adopting CKB_TX_MESSAGE_ALL.

secp256k1 is still very much safe to use, just we have better locks now, so we should try to fund wallets that adopt them.

Phroi

3 Likes
10

从我自己的角度，我会为这个提案提供给最终用户的内容简单做个总结：遵守 Material 3 设计的钱包，类似 CKBull 。支持轻客户端，所以能减少对外部设施的依赖，理论上来讲能提升资产安全性。不过一些 CKBull 已有的功能并未包含在此次提案中，例如对 .bit did 的支持或在钱包中法币入金的功能。

总的来讲，我认为这是一个值得被关注的提案。我的主要观点在于：这是第一个承诺了会开放源代码的手机钱包，光这一点就能为后来的开发者提供更多帮助。

虽然如此，我对提案的一部分内容依然抱有疑虑。

是否可以对「计划开源」的定义作更加详细的解释？我注意到开源计划并没有被包括在最终的里程碑中，这是否意味着项目源代码只会在开发完成之后公布？会是在什么时间呢？计划在什么平台上公布？以及是否会在 Google Play 通道之外提供开源编译版本，供用户验证开源代码的完整性？

在这一点上我持和 @phroi 同样的看法，考虑到我们已经有了支持 CCC 的 NervDAO，为新的钱包支持 CCC 似乎是比支持 NervosDAO 更应当被优先完成的选项。

需要说明的是，我并不反对在钱包中集成 NervosDAO 来提供更好的用户体验，只是希望能了解更多提案者选择这个优先顺序的原因。

感谢你提出提案！

From my perspective, I would briefly summarize what this proposal offers to end-users: a wallet that adheres to Material 3 design, similar to CKBull. It supports the light client, which reduces dependence on external infrastructure and, in theory, enhances asset security. However, some existing CKBull features, such as .bit DID support or in-wallet fiat-to-crypto on-ramps, are not included in this proposal.

Overall, I believe this is a proposal worth watching. My main point is: this is the first mobile wallet that has committed to being open-source. This alone will provide significant value to future developers.

That being said, I still have concerns regarding certain parts of the proposal.

Could you provide a more detailed explanation of the definition of “intended to be open-sourced”? I noticed that the open-sourcing plan is not included in the final milestones. Does this mean the source code will only be released after development is fully completed? When exactly will it be released? Which platform will be used for the release? Will you provide open-source builds outside of the Google Play Store to allow users to verify the integrity of the open-source code?

Regarding the milestones and the list of excluded items, I share the same view as @phroi. Considering we already have NervDAO supporting CCC, prioritizing CCC integration for a new wallet seems like a more logical choice than prioritizing NervosDAO integration.

To be clear, I am not against integrating NervosDAO to improve user experience; I simply hope to understand the proposer’s reasoning behind this specific order of priority.

Thank you for the proposal!

7 Likes
11

Anyway, my main point is that we really need to find ways to create Light Client enabled wallets that fit in the Ecosystem by integrating CCC.

Ideally, it would be nice if said wallets were able to share their Light Client instance with CCC enabled web DApps: this is possibly what will enable us to move from remote Full Nodes to local user-owned Light Clients.

We are missing some building blocks and there is a lot of work to do, I know, especially on the CCC side (PRs are always welcomed). That’s why in my opinion priorities as represented in this proposal may not be in the correct order.

Maybe, if I was the proposer, I would focus more on:

  • Research & collaborations with appropriate Teams (Core & CCC)
  • Creating standards & implementations that allow in-wallet Light Client to be shared safely across Web DApps
  • CCC PRs

Love & Peace, Phroi

8 Likes
12
  1. Thank you for the feedback and for recognizing the value of an open-source mobile wallet for the ecosystem. Let me address your specific concerns.

You’re absolutely right that “intended to be open-sourced” was too vague. Here’s the concrete commitment:

When: The repository will be public on GitHub from the start of Milestone 1

Where: GitHub repository ( RaheemJnr (Raheem Jr.) · GitHub )

How:

Distribution Method Purpose Timeline
GitHub (public repo) Source code, all commits visible M1 start
GitHub Releases Tagged releases with release notes Bi-weekly (v1.1.0, v1.2.0, etc.)
Google Play Store Signed production builds Biweekly updates
F-Droid Reproducible builds for verification Post-M4 (production)

Why not in the milestone originally? Fair question. I assumed it was implicit; I’ll update the proposal to add “Open-source repository on GitHub” as a deliverable in Milestone 1.

This is the same concern Phroi raised. Here’s my reasoning:

Technical Path:

M1: Core wallet security → BIP39, biometrics, mainnet
    ↓
M2: Native transaction primitives → DAO deposit/withdraw
    ↓
M3: Multi-wallet management → Multiple key pairs
    ↓
M4: UX polish → Address book, launch prep
    ↓
Future: DApp connectivity → Browser, CCC integration, external wallets

Why this order?

  1. CCC is for web browsers - It’s a TypeScript library. Integrating it into a native Kotlin app requires either:
  • WebView bridge (performance overhead)
  • Native port (6-8 weeks of reimplementation)
  1. We’re using native equivalents - The app uses CKB SDK Java + direct JNI to the Light Client, which is the native Android approach the CKB team just added support for (January 2026).
  2. Foundation before connectivity - We need stable wallet primitives before we can safely connect to external DApps or wallets.

Regarding NervDAO**:** The M2 NervosDAO integration isn’t about competing with NervDAO.

Users will still be able to access nervdao once we add a DApp browser (post-grant). Also, don’t forget portal wallet was also a UI for the DAO before we migrated to NervDAO (which is also hosted somewhere). What if there is a Cloudflare downtime (I know this is an edge case, but it is worth mentioning)? We have the option of a DAO wallet with no trust assumptions that works as long as there’s internet.

  1. Comparison to CKBull

You mentioned .bit DID and fiat on-ramps. Valid points:

.bit DID support - Planned post-grant (requires DApp connectivity first also the team presence in the ecosystem haven’t been felt in a while)
Fiat on-ramps - Likely via partnerships (Ramp, MoonPay) in the future, not in the initial scope.

I want to be clear that CCC integration and DApp connectivity are absolutely on the roadmap; they’re just post-grant because:

  1. We need stable foundation first
  2. They require significant additional research/work
  3. Technical complexity (bridging web to native)

This proposal is about building the foundation that makes all of that possible.

Does this address your concerns? I want to make sure the open-source commitment is crystal clear and that the milestone priorities make technical sense.

Best, Jr.

4 Likes
13

Hey Phroi,

Thank you for the thoughtful feedback and for supporting my work over time. Your concerns about ecosystem fragmentation and CCC integration are valid, and I want to address them.

I completely understand where you’re coming from on CCC-first, but there’s a fundamental technical issue: CCC is a TypeScript library designed for web browsers and Node.js environments.(i said the same thing to Hanssen above.) Pocket Node is a native Kotlin/Compose Android application using direct JNI bindings to the CKB Light Client (Rust).

I’m not avoiding CCC out of preference; i’m using the native equivalent that’s actually more performant and appropriate for mobile. The CKB team just added native Android JNI support specifically for this use case.

You’re absolutely right that this matters. Here’s how I plan to handle it:

Short-term (this grant):

  • Default to secp256k1/blake160 (widest compatibility)

  • Users can participate in current DAO structures

Post-grant (separate proposal):

  • Add Quantum Resistant lock script support (i and Tea have been in contact since the very first day, so it’s something we will work on later on)

  • Implement DApp browser with proper web3 injection

  • Enable CCC-based DApp connections (nervdao.com, Community DAO v1.1, etc.)

  • Research light client sharing across DApps (the exact standards work you mentioned)

This isn’t avoiding the problem. Foundation first, then advanced features.
3.

Your vision of “wallets sharing their Light Client instance with CCC-enabled web DApps” is exactly where this leads:

Phase 1 (this grant): Prove mobile light client viability

  • Get the embedded light client stable and performant on Android

  • Build core wallet primitives

  • Establish open-source patterns

Phase 2 (future): Enable ecosystem connectivity

  • DApp browser with web3 injection

  • Expose light client instance to web DApps via secure bridge

  • Collaborate with CCC team on mobile standards

  • Contribute native Android patterns back to ecosystem

We need Phase 1 before Phase 2 can exist.

2 Likes
14

Personally, although I think NervDAO is an excellent tool, if the stated goal of @Jnr6 is to create a wallet that minimises dependencies, which is the purpose of embedding the light client into a mobile-native application, then at least for core functions (I feel NervosDAO deposits/withdrawals count as such) I would not want to rely on a hosted frontend for that interaction.

2 Likes
15

Losing iCKB in the process, but sure iCKB is not a core function yet :rofl:

No such technical issue, let’s clear it up:

  • Not asking for developing a native Android wallet in CCC :cross_mark:
  • Asking for a standard that allows users to use Mobile/Desktop Wallets (Signer & Light Client) in CCC-enabled websites :white_check_mark: (Rough idea for a Solution: authenticated web sockets)

Side Note: if done correctly, I would see such proposal as far more valuable than another wallet, as it would lay the foundations to make native Mobile/Desktop Wallets actually useful. Later on, built on top of that standard, Pocket Node.

@Jnr6 I understand your points and respect your craftsmanship.

Let’s agree to disagree on priorities,
Phroi

PS: I would have given this very same feedback to Quantum Purse, just @Tung_Pham never needed a CommunityDAO vote for funding development.

6 Likes
16

@phroi & everyone, just a remind that I welcome all feedbacks on the quantumpurse repo for a better product. In fact, many feedbacks from many people have been addressed and solved!

9 Likes
17

Thank you for the suggestion @Tung_Pham, I really appreciate your availability:

I have no more questions on this proposal, you have my full support!! :muscle:

Love & Peace, Phroi

4 Likes
18

What Jnr6 is building sounds good to me and it sounds like something CKB wants and needs, but I’m glad your here to ask the hard questions Phroi because for the average community member like me, we don’t see these possible underlying issues, so I’m sure your input is very much appreciated by everyone, even by the person your questioning.

5 Likes
19

Thank you Phroi, I really appreciate your comments and I see where you’re coming from; although it may not seem like that now but we in the end we will converge to the same end goal.

Thank you Phroi.

3 Likes
20

Nice work sir, Best of luck for the future. :heart:

3 Likes
21

Thank you @Raja

2 Likes