Project: RGB++ Resume
GitHub: GitHub - Ticoworld/rgbpp-resume: Recover interrupted RGB++ transfers. · GitHub
Funding requested: $2,000 USD equivalent
Timeline: 4 weeks from an agreed start date after approval
1. Project overview
RGB++ Resume is an open-source library that helps developers recover interrupted RGB++ transfers.
An RGB++ transfer can involve an external Bitcoin wallet, a Bitcoin transaction and a final transaction on CKB. If an app closes or loses a network reply halfway through, it may no longer know what happened. Starting the transfer again is not necessarily safe.
RGB++ Resume is intended to help the app save the original transfer, recover it after a restart, and check what happened before taking another action.
I have already tested an early version on Android and Testnet. I am applying for Spark support to turn that private prototype into a reusable npm package, finish the Android recovery flow and release an example that other developers can try.
2. Team profile
Applicant: Timothy Orichi (Ticoworld)
Role: Independent developer and maintainer
GitHub: Ticoworld (Timothy Chinecherem) · GitHub
Discord: Ticoworld
Email: [email protected]
Related projects: FiberLatch and Waymark
I will be responsible for development, testing, documentation and weekly written progress updates. I can respond to committee questions through Nervos Talk and Discord.
3. The problem
Imagine someone starts an RGB++ token transfer and is sent to UniSat to sign it. The app closes before the process is finished. Or a transaction is accepted by the network, but the app never receives the reply.
When the app opens again, it needs to answer a simple question: Did the original transfer go through, or is it still waiting?
Existing CCC/RGB++ tools handle transaction creation and other blockchain operations. An app still needs a reliable way to remember its own progress across wallet handoffs, restarts and lost replies. RGB++ Resume focuses on that missing application-side recovery work.
I have not yet confirmed demand from an independent developer using the library. Having another developer try it is part of this grant plan.
4. The solution
With RGB++ Resume, an app will be able to:
- Save the original transfer before opening the external wallet.
- Restore that transfer after the app restarts.
- Check any signed or submitted transaction it already knows about.
- Continue safely, or wait and check again if the network result is unclear.
flowchart TD
A["Start an RGB++ transfer"] --> B["Save the original transfer"]
B --> C["Wallet signing and network steps"]
C --> D{"App closes or a reply is lost?"}
D -->|No| E["Continue normally"]
D -->|Yes| F["Restore the saved transfer"]
F --> G{"Do we know what happened?"}
G -->|Yes| H["Continue the original transfer or show its result"]
G -->|Not yet| I["Keep it saved and check again; no blind retry"]
This is not a new wallet or a replacement for the RGB++ SDK. It is a recovery tool that developers can connect to their existing applications.
5. Technical approach and limits
The first release will be a JavaScript npm library with TypeScript types and a small React Native Android example. It will reuse the recovery code and checks I have already developed.
The main new work is making recovery reliable across three points: returning from UniSat, submitting Bitcoin transactions, and completing the CKB side of the transfer. The Android app must be able to save its progress and recover without requiring a separate Node program to finish the CKB transaction.
Developers will connect the library to their own storage, wallet and existing CCC/RGB++ tools through documented adapters. The npm package will not include the experimental CCC archives used by the prototype. The Android example will need a documented, appropriately licensed way to obtain compatible upstream dependencies; resolving that is an early project task.
First-release scope: Bitcoin Testnet3 and CKB testnet; one supported xUDT transfer with one source, one recipient and change; UniSat signing using a native SegWit (P2WPKH) account; and one active transfer at a time. Developers must supply the public key for their selected wallet address. The tested environment is React Native 0.83.10 with Hermes on an Android 16 emulator.
Mainnet, iOS, other wallets, multiple simultaneous transfers and automatic background recovery are not part of this grant. This release is a developer-facing Testnet tool, not a production security certification.
6. Four-week plan
| Week | What I will deliver | How it will be checked |
|---|---|---|
| 1 — Reusable package | Extract the existing recovery code into an installable package; document the API, storage and upstream adapter setup. | A fresh project can install it, use its public functions and run its tests without my private workspace. |
| 2 — Wallet recovery | Finish Android recovery of wallet requests, saved signatures and interrupted writes. | Restart tests show that late or repeated wallet replies cannot start a second transfer. |
| 3 — CKB completion | Let Android save and finish the CKB transaction itself; handle lost submission replies; run the missing wallet-return and CKB-response-loss tests. | Tests and recorded Testnet evidence show recovery of the original transfer without blind resubmission or a separate Node completion driver. |
| 4 — Release and outside testing | Finish the Android example, setup guide, short demo, npm 0.1.0 release, independent developer test and public completion report. |
Another developer can install the library and try the documented flow; test results and known limits are published. |
The earlier estimate for this remaining work is 86–114 engineering hours, approximately 22–29 hours a week over four weeks. This depends on having a workable upstream dependency path and reliable Testnet services. If a major blocker appears, I will report it and discuss the scope or schedule with the committee rather than quietly remove essential recovery checks.
7. Funding request and breakdown
Total requested: $2,000 USD equivalent.
| Use of funds | Amount | What it supports |
|---|---|---|
| Reusable npm package and public API | $350 | Package extraction, clean installation and documented interfaces. |
| Android wallet and restart recovery | $450 | Wallet handoff, interrupted saves and safe handling of repeated replies. |
| CKB completion and failure recovery | $650 | Durable Android completion, lost-response recovery and the most important failure tests. |
| Android example, verification and release | $450 | Reproducible setup, end-to-end tests, documentation, demo, npm release and necessary fixes. |
| Independent developer evaluation | $100 | Support for a separate developer’s installation and feedback effort. |
| Total | $2,000 | $1,900 development/release work and $100 outside evaluation. |
These are proposed allocations for the new work, not past expenses or payments for the prototype that is already complete.
I am requesting above the standard $1,000 level because this involves more than packaging code. The library has to preserve one transfer correctly across an external wallet, Bitcoin submission and CKB completion. Each step has its own interruption cases, and unsafe retries must be prevented. The remaining Android integration, fault tests and independent release are the main reasons for the larger request.
There is no budget for new hardware, a hosted backend or a paid security audit. Actual spending and any material budget changes will be reported to the committee. The evaluation allowance is for participation, not a favorable review.
8. Deliverables and how to verify them
By the end of the grant, I intend to provide:
| Deliverable | What reviewers can check |
|---|---|
Open-source rgbpp-resume npm package (0.1.0) |
Install it in a fresh project, run its documented tests and confirm that it does not require private files or bundled experimental CCC archives. |
| Android reference example | Follow a public setup guide with a separate Testnet account and observe the original transfer being restored after an app restart. |
| Recovery failure tests | Simulate interrupted saves, repeated wallet replies and lost Bitcoin/CKB network responses. The expected result is recovery or a clear uncertain state, not an automatic second transfer. |
| Short demo and Testnet evidence | Watch the restart/recovery flow and inspect transaction references and recorded test outcomes. |
| Independent evaluation and completion report | Read a separate developer’s actual installation results, remaining limitations and a report of grant work and funding use. |
The finished repository will include simple commands to install and test the package from a clean checkout. Offline tests will not require funded wallets. The separate Android reproduction guide will specify the emulator, wallet and Testnet setup. The existing public repository does not have these commands or the library source yet; they are deliverables of this proposal.
A new Testnet transfer will be used for the missing live recovery checks. I will not replay the already completed historical transfer. If a required live test fails, I will document the result and discuss a correction before claiming the release is complete.
9. What is already done, and what Spark would fund
Already completed before this application:
- A private prototype that saves and verifies transfer information, preserves a signed Bitcoin transaction and handles uncertain Bitcoin broadcast results.
- 6 October 2026: an Android emulator experiment using real UniSat signing. It recovered saved state across app restarts, handled a deliberately lost Bitcoin broadcast reply, and reached a completed xUDT transfer on CKB. The CKB completion step ran in a separate Node program, not in the Android app.
- 14 October 2026: fresh dependency-installation and adapter tests passed. A controlled React Native/Hermes test reproduced the saved CKB completion data, without sending a new transaction.
- The public GitHub repository, which currently contains only the project introduction, MIT license and
.gitignore.
Historical proof of settlement: Bitcoin Testnet transaction and CKB testnet transaction 0xeac6f3296af6e1a4eb7c11c756cc68e4515b628406e5cff59add8c3a03903981. The transactions show historical settlement; the restart and response-loss behavior comes from the recorded experiment, not from the chain links alone.
Spark would fund: turning that existing work into an installable public library, completing Android-owned CKB recovery, proving the remaining interruption cases, releasing the example and having another developer evaluate it.
None of the earlier experiments are being presented as new grant-funded work.
10. Why this matters for CKB
RGB++ transfers connect Bitcoin-side ownership with asset state on CKB. Completing a transfer safely depends on keeping the transaction information that was originally prepared and committed to, rather than rebuilding a different transfer after an interruption.
RGB++ Resume aims to make that recovery work reusable for developers building on RGB++ and CKB, while continuing to use the existing CCC/RGB++ tools for blockchain operations.
The first goal is a small, working and independently testable developer release. I will publish the final results, including limitations and any failed tests, and use outside feedback to decide whether further support is justified.