Hello xingtianchunyan,
Thank you for checking in.
The project is still progressing. More time has been needed for mainnet data collection and analysis to ensure we have enough meaningful data before reporting the results.
The work is ongoing, and I’ll share a detailed progress update as soon as we have collected enough data.
Thank you for your patience and continued support
Best,
Fadhil
Hello @mulinya,
In our previous communication, we learned that the team was making every effort to advance the collection and analysis of mainnet data, and hoped to ensure that sufficient meaningful data had been obtained before reporting the results. The committee fully understands and appreciates your commitment to the rigor of the project’s outcomes.
However, it has been eight days since your last reply. Perhaps cleaning the mainnet data or accumulating samples has taken longer than expected. As of now, we still have not received any formal update on the progress of data collection. We fully understand that “good things come to those who wait,” but to ensure that the project has not stalled, periodic progress updates are equally important. Even simply telling the community how much data has been collected and what obstacles have been encountered would be valuable.
According to the “Completion Policy” under Section 3.3 of our “Spark Program: Microgrant Initiative,” in the following extreme circumstances, the committee will have no choice but to terminate the project and suspend the disbursement of any further funding in order to act responsibly toward the public resources of the entire community:
Given that some time has passed since our last update, and to help the community understand the project’s true health, we are following up one final time this week: if we still do not receive a formal response from you by the end of this Sunday (2026-09-13)—whether it is an analysis of the interim data collected so far or a clear explanation of the data collection progress—the project will unfortunately be terminated in accordance with procedure, and the remaining financial support will be discontinued accordingly.
If you encounter genuinely insurmountable technical difficulties or node synchronization issues during mainnet data collection, or if you need to adjust the scope of the data analysis, please do not hesitate to reply at any time. The Committee is willing to maintain communication and provide continued support, but this must be based on proactive engagement and regular communication.
We sincerely look forward to hearing from you. Wishing you all the best!
Sincerely,
xingtian
On behalf of the Spark Program Committee
cc @zz_tovarishch , @Hanssen , @yixiu
Hi xingtianchunyan,
Following the feedback from the last review, I went back through the project carefully and did some reiterations.
The review resulted in a significant change in direction.
The earlier human/bot classification approach has been removed from the active system. The current V2 focuses instead on observable CKB-native wallet behaviour, without trying to infer whether a wallet belongs to a human, bot, exchange, institution, or other identity.
The current flow is:
The analysis now looks at CKB-specific evidence including transaction timing, Cell/input/output topology, Cell lifecycle, previous outputs, scripts, capacities, transaction templates, typed-Cell evidence, and lineage.
I have also implemented the live analysis path.
A valid CKB mainnet address that was not present in the frozen research dataset successfully completed:
The resulting V2 profile exposes nine feature families:
Temporal, Periodicity, Topology, Lifecycle, Templates, Scripts, Typed Assets, Capacity, and Lineage.
It also evaluates 12 descriptive behaviour rules. These are intentionally descriptive signals rather than identity classifications, and the API exposes evidence/support states so that insufficient evidence is not presented as an observed behaviour.
A significant part of this work has also been understanding the limitations of collecting this evidence from CKB Explorer.
API rate limiting slowed large-scale collection and made some wallet observations significantly more expensive to collect.
Uneven transaction histories meant some wallets contained rich activity within the observation window while others contained very little evidence. This is one reason the new system explicitly represents SUPPORTED, PARTIAL, INSUFFICIENT_EVIDENCE, and UNRESOLVED states rather than forcing every wallet into a classification.
Incomplete API fields also required additional handling, particularly around Cell/script information and previous outputs. Where evidence cannot be resolved, the pipeline preserves that limitation rather than treating missing information as zero.
Finally, network latency and long-running Explorer requests affected some collection runs. The current live implementation works, but a higher-volume wallet has timed out during testing, so I am still treating high-activity wallet analysis as an area that needs further hardening.
The frozen research dataset currently contains:
The frozen observation window is:
2026-08-01T00:00:00Z → 2026-09-01T00:00:00Z
The research artifacts are reproducible and hash-protected, and the current offline verification finishes with:
FINAL_RESEARCH_OFFLINE_VERIFICATION_OK
Current automated verification includes 37 passing classifier tests and 54 research verifier tests (53 passed, 1 skipped, 0 failed), alongside passing Registry build/contract checks.
I don’t want to present this as completed yet.
The corrected V2 implementation is now at a point where I would like the committee/community to review and test the direction before I proceed with the remaining hardening work.
At the moment it can be tested locally from the repository. A reviewer can run the Registry and Classifier services, submit a CKB mainnet address in live mode, inspect the evidence/support states, nine feature families and 12 behaviour rules, and retrieve the persisted analysis.
Repository:
Dataset:
The next steps I currently have are improving high-activity/multi-page collection, adding stronger automated live integration testing, hardening the API against repeated/expensive requests, and then deploying a public test endpoint.
Given the concerns raised during the previous review, I would really appreciate feedback on the corrected methodology and current implementation before I proceed with those final steps.
If there are specific addresses, behaviours, edge cases, or CKB patterns you would like me to test against, I’m happy to include those in the next validation round.
