Spark Program | CKB Wallet Behaviour Intelligence

mulinya · June 3, 2026, 7:27pm

Project Name

CKB Wallet Behaviour Intelligence

Team

GitHub: FadhilMulinya
Role: Product engineer with experience building blockchain infrastructure, indexing systems, backend services, and developer tooling
Telegram: mulinyaaa
Email: [email protected]

Project Description

Problem

CKB provides transparent and rich on-chain data through its Cell-based architecture, but there is currently no open-source tooling that converts raw transaction data into actionable behavioral intelligence.

Developers can easily access transaction histories through explorers and APIs, but understanding how a wallet behaves still requires significant custom analysis and infrastructure.

Questions such as:

Is this wallet behaving like an individual user?
Does this wallet exhibit highly automated activity?
Is this wallet likely operating as an exchange-controlled wallet?
Does this wallet demonstrate unusual transaction behavior compared to typical network participants?

cannot currently be answered through a simple API or reusable ecosystem tool.

As the CKB ecosystem grows, analytics platforms, wallet providers, security tooling, explorers, and future infrastructure services can benefit from richer wallet context rather than relying solely on raw transaction records.

This project is not focused on detecting low-cost Sybil attacks. CKB’s Cell model and state occupation costs already increase the cost of mass wallet creation. Instead, the project focuses on behavioral analysis and wallet classification, providing ecosystem developers with reusable analytics infrastructure built specifically for CKB.

Solution

We propose an open wallet behaviour dataset, feature extraction framework, and baseline classification API for the CKB ecosystem..

The system will analyze wallet transaction histories using machine learning and behavioral feature extraction.

The initial version will focus on:

Transaction timing patterns
Transaction frequency patterns
Wallet interaction graph relationships
Cell usage and transaction flow characteristics

Using these features, the system will generate:

Human-like behavior score
Automated behavior score
Exchange-like behavior score
Confidence metrics

Developers will be able to submit a CKB wallet address through an API and receive a behavioral classification result.

The goal of this Spark Program project is to deliver a working prototype that demonstrates how behavioral analytics can enrich wallet intelligence across the CKB ecosystem.

Expected Deliverables

1. Open Source Repository

A public GitHub repository containing:

CKB data extraction pipeline
Feature engineering pipeline
Model training code
API implementation
Deployment instructions
Technical documentation

2. Wallet Classification API

A public REST API capable of:

Accepting a CKB wallet address
Returning wallet classification results
Returning confidence scores

3. Initial Wallet Dataset

A curated dataset containing approximately:

500 human-like wallets
500 automated and/or exchange-like wallets

The dataset will be publicly available and serve as one of the first open wallet behaviour datasets built specifically for the CKB ecosystem.

4. Documentation

Documentation covering:

API usage
Deployment instructions
Model methodology
Feature definitions
Evaluation results

5. Public Demonstration

Public API endpoint
Demonstration video
Project completion report

6. Formal Analysis Report

A formal report containing:

Model accuracy metrics
Precision, Recall and F1 Score
Confusion Matrix
Dataset size statistics
Label distribution statistics
API verification methods
Open-source repository links
Findings and limitations

How To Verify

The project can be verified without requiring code review.

Dataset Verification

Reviewers can:

Download the published dataset
Verify dataset size
Verify label distribution
Inspect feature definitions

Feature Pipeline Verification

Reviewers can:

Run the feature extraction pipeline
Generate behavioural features from CKB wallet data
Reproduce the dataset generation process

API Verification

Reviewers can:

Submit a CKB wallet address to the API
Receive classification results
Verify model outputs against published documentation

Model Verification

Reviewers can:

Train the baseline model using the published dataset
Reproduce evaluation metrics
Validate reported results

Repository Verification

Community members can:

Access the public GitHub repository
Review documentation
Reproduce data extraction and training workflows

Analysis Report Verification

Reviewers can verify:

Accuracy
Precision
Recall
F1 Score
Confusion Matrix
Dataset statistics

through the published report and repository artifacts..

Example integration: A Randomn wallet Provider

**

Required Funding

Developer Time

Phase	Hours	Description
Data extraction and feature engineering	30 hrs	CKB-CCC integration, Explorer API integration, transaction ingestion pipeline, feature engineering
Model development and evaluation	30 hrs	Dataset preparation, model training, model evaluation, classification pipeline
API implementation	25 hrs	REST API development, model serving integration
Documentation and open-source release	15 hrs	QA testing, deployment, documentation, demo preparation and final reporting
Total Developer Time	100 hrs	Approximately 4 weeks of development

Infrastructure & Deployment Costs

Item	Unit Cost	Quantity	Subtotal (USD)
VPS hosting (API, model inference server)	$12/month	2 months	$24
Database	$20/month	2 months	$40
Domain name for public API and demo	~$12/year	1	$12
Infrastructure & Deployment Subtotal			$76

These costs support the public deployment of the Wallet Analytics & Classification API, model serving, dataset storage, monitoring, testing, and demonstration infrastructure required for the Spark Program deliverables.

Effective Hourly Rate

Metric	Value
Total developer hours	100 hrs
Developer budget	$700
Effective hourly rate	$7.00/hr

Total Developer Compensation

Item	Amount
Infrastructure & deployment costs	$76
Dataset preparation & validation	$124
Developer time	$700
Total grant requested	$900

The requested funding supports approximately 100 hours of development work covering blockchain integration, wallet data extraction, feature engineering, machine learning implementation, API development, testing, deployment, documentation, and public demonstration delivery.

Estimated Completion Time

4 weeks total

Weeks 1–3: active development (data pipeline, feature engineering, dataset construction, model training)
Week 4: documentation, open-source release, and formal reporting

Clear To-Do List

Week 1

Integrate CKB-CCC
Integrate Explorer API
Build transaction ingestion pipeline

Week 2

Implement feature extraction pipeline
Create wallet labeling workflow
Build initial dataset

Week 3

Complete labeled dataset
Train classification model
Evaluate model performance
Generate benchmark metrics (Accuracy, Precision, Recall, F1 Score, Confusion Matrix)

Week 4

Publish dataset
Publish feature extraction pipeline
Publish model training code
Publish API code
Release open-source repository
Publish technical documentation
Publish formal analysis report containing:
Accuracy
Precision
Recall
F1 Score
Confusion Matrix
Dataset statistics
Label distribution
Repository links
Publish project completion report

Relevance to the CKB Ecosystem

Meeting Actual Needs in the CKB Ecosystem

The project provides a reusable wallet analytics layer that can benefit:

Wallet providers
Blockchain explorers
Analytics platforms
Security monitoring tools
Future infrastructure services

Today, teams that require wallet behavior analysis must build their own infrastructure and classification logic from scratch.

This project provides an open-source foundation that can be reused and extended by ecosystem participants, reducing duplicated effort while encouraging experimentation with behavioral analytics on CKB.

The project also contributes an initial labeled wallet dataset and wallet classification API that can serve as a starting point for future ecosystem tooling.

Utilizing CKB’s Technical Architecture

The project leverages CKB’s transparent transaction model and Cell-based architecture to extract behavioral signals that are difficult to obtain from simple account balances alone.

Using transaction flows, Cell consumption patterns, transaction timing, and wallet interaction relationships, the system demonstrates how machine learning can be applied to CKB-specific data structures to generate useful wallet insights.

Future Work

The current Spark Program scope focuses exclusively on:

Wallet dataset construction
Feature extraction pipeline development
Baseline model training
Open-source release

Future work, including advanced model finetuning, ecosystem integrations, dashboard expansion, partner onboarding, and larger-scale dataset growth, will be pursued through a future Community Fund DAO proposal after successful completion of the Spark milestone.

This showcases a practical analytics use case built directly on top of CKB’s unique architecture and provides a foundation for future wallet intelligence and ecosystem analytics tools.

xingtianchunyan · June 6, 2026, 12:22am

Hi @mulinya，欢迎你在 Spark Program 提案！

以下是我在提交委员会审核前的一些个人看法，供你参考，不代表委员会立场。
通读提案后，我梳理了以下几点可能影响委员会评审的问题，建议你在正式评审前做针对性调整：

1. 提案结构顺序混乱，可读性较差。

当前提案的章节顺序：概述 → 已完成工作（里程碑+预算） → 问题陈述 → 解决方案 → 工作流程 → 技术实现 → 界面设计 → 预算 → 团队

这明显不符合 Spark Program 申请模板的标准格式，请务必将相关内容整理后置于同一章节。

2. 缺少独立的“交付物”和“如何验证”章节。

目前提案没有独立且完整的 Deliverables（交付物）和 How to Verify（验证方式）章节；社区和委员会成员目前都很难直观了解该项目的交付物有哪些，以及无从了解如何直接有效地以非代码审查的方式验证你的工作。

建议：综合前两个问题，按照 Spark Program Mini-Grant 模板重新组织章节。

3. 预算额度 $1,500 超出纯技术类项目 $1,000 标准上限。

根据 Spark Program 资助方案，常规项目资助上限为 $1,000，特殊项目经委员会审议后可提高至 $2,000。目前你的提案申请 $1,500，但没有说明为什么这个纯技术类项目需要突破 $1,000 的标准线。

建议：将预算调整至 $1,000 以内；

4. 提案未回应"CKB 上是否存在女巫攻击问题"这一核心前提。

提案在"问题陈述"部分假设了"空投平台难以过滤女巫钱包"和"DEX 难以识别人类与机器人"等场景。但需要指出的是：CKB 是一条以记录重要数据为目的的链，任何个体在使用 CKB 保存重要数据时都需支付对应的 Cell 占用成本（State Rent）。这与那些依赖低成本的账户模型的公链有本质区别——在 CKB 上，"批量创建低成本钱包"本身就需要持续支付存储成本，天然提高了女巫攻击的门槛。除非"女巫钱包"有破坏 Fiber Network 中交易链路的能力，否则在 CKB 生态中，"区分人类与非人类钱包"这一需求的真实性和紧迫性似乎有待论证。

建议：在问题陈述中明确说明，为什么 CKB 生态需要这个工具——你的目标用户是谁（钱包开发商？DEX？审计团队？），他们在什么具体场景下面临"无法识别人类 vs 机器人"的痛点？这个痛点是否值得通过外部工具来解决，而非通过现有数据即可简单判断？

以上就是我梳理的几个关键问题，供你参考。在你调整后我会提请委员会尽快进入正式评审，相信修改后的提案会让评审过程顺畅很多。

期待你的更新版本。
祝好，
行天

mulinya · June 15, 2026, 8:26am

Hi @xingtianchunyan,

Thank you again for the detailed feedback and guidance.

I have now reorganized and resubmitted the proposal according to the Spark Program Mini-Grant template. In the updated version, I have:

Restructured the entire proposal to follow the correct Spark format
Added clearer and more testable “How to Verify” sections
Adjusted the budget to strictly comply with the $1,000 cap, with a transparent breakdown between infrastructure, dataset preparation, and developer time
Refined the Problem Statement and CKB relevance section to better reflect real ecosystem needs and clearly define target users and use cases within CKB
Removed ambiguity around Sybil framing and focused the scope on wallet behavior analytics and classification

The revised proposal is intentionally scoped as a lightweight, verifiable prototype that can be delivered within the 6-week timeline, with clear outputs including an API, dashboard, dataset, and open-source repository.

Please let me know if there are any remaining gaps before formal committee review. I’m happy to refine further if needed.

Best regards,
Fadhil

xingtianchunyan · June 19, 2026, 4:25pm

Hi @mulinya ,

Thank you for your continued contributions and quick responses to the Spark Program. After review by the Spark Program Committee, your proposal is currently classified as Pending.

The committee has noted your efforts in restructuring, supplementing the How to Verify section, and clarifying the problem statement. The committee recognizes the technical direction and CKB ecosystem value of this project—wallet behavior analysis can indeed provide value to the CKB ecosystem in the future.

However, the committee’s assessment of the value of the weekly tasks in the To-Do List differs from the current proposal. The following are specific comments:

The primary reason is as follows:

The work planned for Weeks 4 and 5 does not add significant value to the core asset; it is recommended to focus on the initial data work

The committee believes that the project’s core assets are the annotated dataset and the feature extraction pipeline, rather than finetuning infrastructure or partner integrations. Therefore:

Focus on the work in the first 3 weeks, remove the work planned for Week 4 and Week 5

Week 4 (model finetuning / expanding the feature set): offers limited value to the core dataset asset and is recommended to be postponed to a DAO proposal after the conclusion of Spark
Week 5 (Partner integration / Dashboard refinement): This belongs to ecosystem expansion work and exceeds Spark’s objective of validating the core hypothesis.

Keep the core data work for Weeks 1–3 (data extraction pipelines, feature engineering, initial dataset construction, baseline model training) and the Week 6 wrap-up open-source work.

After cutting Weeks 4 and 5, remove the labor and infrastructure costs corresponding to those two weeks, reducing the total budget from $1,500 to $900.

Open sourcing the dataset, feature-extraction code, classification model, and API code was already part of your Week 6 plan—please proceed accordingly. The open annotated dataset will become the CKB ecosystem’s first public wallet behavior dataset.

Complete a formal analysis report

After the Spark funding ends, you must submit a formal analysis report that includes:

Specific model performance metrics on the test set (accuracy, F1 score, confusion matrix)
Dataset size and label distribution statistics
API documentation and verification methods
Link to the open-source repository

Suggest applying to the DAO for a larger proposal after Spark concludes

The project’s full vision—finetuning infrastructure, broad ecosystem integrations, and large-scale labeled dataset expansion—goes beyond the scope of the Spark Program. Spark supports verifiable tool-like MVPs and the construction of core data assets. After Spark concludes, you can apply to the Community Fund DAO for larger funding to advance the full ecosystem integration vision.

Next steps

Please revise the proposal according to the feedback above (cut weeks 4 and 5, reduce the budget to $900, focus on weeks 1–3 data work + week 6 for open-source wrap-up), mention the updates in this thread by @-ing me, and the committee will complete the review as soon as the adjustments are confirmed.

Best,
xingtian
On behalf of the Spark Program Committee

mulinya · June 24, 2026, 12:32am

Hi @xingtianchunyan,

Thank you for the thorough review and clear direction. I have gone through all the committee’s points and updated the proposal accordingly – the scope, budget, and deliverables now reflect exactly what was requested.

One additional note: the web dashboard has been removed from this Spark scope and will be picked up in a future DAO proposal alongside the broader ecosystem work.

The revised proposal is ready for committee review whenever you are. If any further alignments are needed before the review is finalized, I am happy to make additional adjustments.

Best regards,
Fadhil

xingtianchunyan · July 4, 2026, 6:03am

Hi @mulinya,

We are pleased to inform you that the Spark Program Committee has approved the CKB Wallet Behaviour Intelligence proposal, with a funding amount of 900 USD (100% paid in CKB, 1 CKB = 0.000950 USD, 947,369 CKB).

The committee believes that an open wallet behavior dataset, feature extraction framework, and baseline classification API can help foster a healthier development of the ecosystem in the future.

Here are the next steps:

Funding & Wallet Address

The total grant is 900 USD (for the current cycle Spark grants are paid 100% in CKB).
- The first installment (20%) equivalent to 189,474 CKB will be disbursed as soon as possible.
- Please provide the CKB wallet address to receive the funds.
- The remaining 80% is flexible: it can be requested during weekly syncs as needed or claimed upon project completion.
Weekly Sync

We would like to establish a regular weekly synchronization mechanism, with two options:
- Text-based updates in this post, with progress updates at a fixed time each week and committee feedback in reply.
- Or a brief video call.
  Please let us know your preference and a convenient time.
Proposal Content Lock
- Once a proposal is approved, we will lock the current version of the proposal post as the reference baseline for subsequent delivery and acceptance. This is standard procedure for all approved Spark projects. If adjustments are needed during development, they can be discussed and documented during the weekly syncs.

Congratulations again, and we look forward to working together!

I also apologize for wasting your valuable time. Due to unstable VPN connectivity recently, I was unable to release this announcement in a timely manner. I hope for your understanding and forgiveness.

Best,
xingtian
On behalf of Spark Program Committee

mulinya · July 6, 2026, 2:17pm

Hello xingtianchunyan,

Thank you to you and the Spark Program Committee for approving the proposal. I appreciate the opportunity to contribute to the CKB ecosystem.

My CKB wallet address is:

ckb1qyqvkel34xpgrdtja8fddy93fgkp6lduy90q2u385q

For the weekly syncs, I prefer text-based updates in this thread. I’ll post updates every Saturday at 6:30 PM UTC.

The proposal lock and funding process work for me. I also understand the delay no worries.

Looking forward to working together.

Best,
Fadhil

xingtianchunyan · July 7, 2026, 9:06am

Hi @mulinya ,

The first installment has been disbursed.

Transaction Hash: 0x3bbaecf1b871643edb1fd635c399cf502cfad1ae22fe89851859cf01a380aa16

Please confirm once received.

Looking forward to your first progress update.

Best,
xingtian
On behalf of the Spark Program Committee

mulinya · July 7, 2026, 11:08am

Hello @xingtianchunyan

I have received , Thank you.

Best,
Fadhil

mulinya · July 12, 2026, 8:55pm

Hi @ xingtianchunyan,

What’s done in week 1:

Initial commit pushed: GitHub - FadhilMulinya/ckb-intel · GitHub
Ingestion pipeline: give it a CKB address → it resolves the lock script hash (via CCC), pulls the transaction history from the CKB Explorer API (paginated), filters by a configurable time window, normalizes it into a canonical transaction schema, and upserts wallets + transactions into MongoDB.
Versioned REST API (Fastify, /api/v1) with ingestion, wallet lookup, paginated transaction history, and health/preflight endpoints.
The full project structure and layered architecture controllers->services ->repositories/clients is documented in the README.

The attached diagram shows the high-level end-to-end system flow.

Run it Locally:

git clone https://github.com/FadhilMulinya/ckb-intel
cd ckb-intel
npm install
cp .env.example .env   # needs a local MongoDB running
npm run dev

Then ingest an address via the POST /api/v1/ingest endpoint (body: a JSON list of addresses), and read the results back from GET /api/v1/wallets/{address}/transactions - it returns the wallet’s clean, normalized transaction history as JSON. The exact commands are in the Quickstart section of the README.

Next up: feature engineering on top of the normalized history - turning raw transactions into behavioural signals for wallet labeling and classification.

xingtianchunyan · July 25, 2026, 9:59am

Hi @mulinya ,

The committee has noted that there has been a period without progress updates recently.

Since these projects are still ongoing, timely progress reports help the committee and the community track development.

If there are obstacles or a need to delay, please communicate openly so we can understand the situation and provide assistance where possible.

We look forward to your prompt response.

Best,
xingtian
On behalf of the Spark Program Committee

mulinya · July 25, 2026, 4:10pm

Hello xingtianchunyan,

Apologies for the miscommunication and for missing the recent progress update due to unavoidable circumstances.

I have been primarily focused on data collection. Since open bot wallets datasets on CKB arent available I built a local CKB bot transaction simulator that generates ground-truth labeled behavioral data on a local CKB devnet. The simulator communicates directly with the CKB JSON-RPC using a lightweight Python transaction-construction package that i built, implements transaction signing in pure Python, runs concurrent bot simulations, and records every confirmed transaction into a labeled dataset for downstream behavioral analysis and model training.

This work currently lives in a separate repository as supporting infrastructure and will be merged into the main Wallet Behaviour Intelligence (GitHub - FadhilMulinya/ckb-intel · GitHub) upon completion as part of the community deliverables.

The generated datasets are available here:

https://github.com/FadhilMulinya/intel-synthetic/tree/main/data

So far, I’ve completed simulations with 300 bots and 500 bots , generating approximately 180,000+ devnet transactions. A detailed analysis of this dataset will be included in next week’s update.

The model will be trained using a combination of CKB mainnet, testnet, and devnet data. In parallel, I have been collecting human wallet data from mainnet and testnet by scapping the respective networks using some python scripts. However, most publicly discoverable wallets are exchange or service wallets rather than representative individual users but still looking for various ways to get sufficient data.

Work related to training the machine learning model has already commenced, and I’ll provide a detailed update on the training pipeline, feature engineering, and initial evaluation results in next week’s progress report.

Once again, I apologize for the miscommunication. If anything affects the reporting schedule in the future, I’ll make sure to communicate it promptly. Thank you for your patience and understanding.

xingtianchunyan · July 30, 2026, 2:18am

Hi @mulinya ,

The committee has reviewed your recent progress and direction, and we need to issue a formal warning regarding the current approach.

1. The bot-simulation approach must stop immediately.

The committee’s position is clear: building your own bots and then analyzing their behavior is meaningless for the goals of this grant. This path produces synthetic, self-referential data that does not reflect real-world wallet behavior on the CKB mainnet. If the project continues in this direction, the committee will be forced to terminate it.

2. Required pivot: shift to real mainnet analysis.

Instead of bot simulation, the project must pivot to analyzing actual mainnet data using the neural network methodology you have developed. Even without bot-generated data, your work can still be highly valuable if it produces:

A high-quality labeled dataset (gold standard) derived from real CKB mainnet transactions.
Clear documentation of the behavioral dimensions and analytical weights used in your neural network model, so that future projects can inherit and build upon your methodology.

The committee values the analytical framework you have built. What we need is for that framework to be applied to real on-chain data, not synthetic bot activity. The dimensions, weights, and labeling methodology you develop from mainnet analysis will become a reusable foundation for the ecosystem — and that is where the true value of this grant lies.

Please confirm your understanding of this direction change and provide a revised plan within the next update. The committee will review your response before deciding on next steps.

Best,
xingtian
On behalf of the Spark Program Committee

mulinya · July 30, 2026, 6:40am

Hi xingtianchunyan,

Thank you for the clarification and feedback.

I understand the committee’s concerns and will pivot the approach accordingly. Going forward, the focus will be on analyzing real CKB mainnet data to build the labeled dataset, behavioral features, and classification framework.

I’ll share the revised implementation and progress in the next weekly update.

Thank you for the guidance.

Regards ,
Mulinya

mulinya · August 3, 2026, 2:49am

Hi xingtianchunyan,
Following up with the completed pivot and full analysis report: ckb-intel/REPORT.md at main · FadhilMulinya/ckb-intel · GitHub
Summary of where things stand:

Data & pivot: All synthetic/bot-simulator code and data paths have been fully removed. The pipeline now runs exclusively on real CKB mainnet data and we used 251 labeled wallets in the current training run (91 human-like, 160 bot-like), pulled directly via the mainnet Explorer API.

Labels: Initially generated via a heuristic (is_special flag + lifetime tx count), then manually verified across the full 251-wallet trained set .Every label individually and manually reviewed against the wallet’s actual transaction history. Zero disagreements found between the heuristic and manual review.

Model - important correction: Your last message referenced “the neural network methodology” .
I want to flag directly that the deployed and evaluated model is a Random Forest, not a neural network. It was selected after cross-validating against Logistic Regression, Gradient Boosting, and SVM-RBF (full comparison table in §4.1 of the report); Random Forest won cleanly (95.2% CV accuracy, 0.986 ROC-AUC) and gives directly interpretable per-feature importance scores, which lines up with what you flagged as the grant’s core reusable value .The documented behavioral dimensions and weights (§5). If a neural architecture is specifically required rather than just implied, let me know and I’ll revisit ,but wanted to raise this now rather than let it stand uncorrected.

Architecture also slightly pivoted: the project is now split into two independently deployable services rather than one combined system . A Python classifier-service that does all the modeling (fetch history → extract features → classify), and a Node registry-service that resolves wallet identity and stores whatever label the classifier hands back, with no modeling logic of its own. Each runs standalone (Node has zero dependency on Python being up at all) and each publishes a live, interactive API reference atGET /api/v1/docs on both services .So anyone can invoke an endpoint directly and see exactly what’s there without reading code first. Full rationale for the split is documented in the repo README §6 GitHub - FadhilMulinya/ckb-intel · GitHub.

Results: 95.24% accuracy / 96.30% F1 on a held-out test split never touched during model selection. I also checked the model isn’t just exploiting wallets with very short transaction histories (§4.2) , accuracy holds at 93.75%+ even on wallets with 21+ transactions.

What’s not yet done: the model and API currently run locally only , there is no public endpoint, hosting, or demo video yet. Also worth flagging: of the four proposed behavioral dimensions (timing, frequency, wallet interaction graph, cell usage), timing and graph features are fully implemented and are in fact the strongest signals in the model (see §5); frequency is folded into timing rather than standalone, and cell usage currently covers transaction-flow shape but not cell-kind classification (SUDT/NFT/DAO, live/dead lifecycle).

Ask: Before I move on to public hosting and a demo, I want to confirm this aligns fully with what the committee expects at this stage . The real-mainnet pivot, the label verification approach, the two-service architecture, and the model choice in particular, given the earlier NN reference. If it’s aligned, I’ll proceed straight to hosting the model and servers and putting together the public demo. If anything needs revising first , or reconsidering the model architecture . Let me know and I’ll address it before moving forward.

Thanks for the guidance up to this point.

Best,
Fadhil

zz_tovarishch · August 4, 2026, 8:22am

Hi Fadhil,

Thanks for the detailed update.

We need to resolve two questions about the labels before the Committee can rely on the reported 95.24% accuracy. These questions concern what the target labels mean and how they were checked.

1. Basis for the heuristic labels

The current fetch_real_data.py rule labels an address as bot_like when is_special == true or its lifetime transaction count is at least 1,000. It labels an address as human_like when the transaction count is between 1 and 50 and is_special == false. Addresses between those thresholds are excluded.

In the CKB Explorer implementation, is_special means that the address appears in the Explorer’s configured special_addresses list. The field does not seem to identify a confirmed automated address. (If you have more information, please feel free to point it out.)

Please provide the following:

The reason is_special is used as a proxy for bot-like behavior.
The basis for the thresholds of 50 and 1,000 transactions. This could include prior research, CKB-specific knowledge, known-identity examples, or preliminary analysis.
A breakdown of the 160 bot_like addresses showing how many were selected by is_special alone, the transaction threshold alone, or both.
The actual command used for each data-collection run that contributed to the committed dataset, including any non-default parameters, the commit hash, collection date and block range, and any manual additions or removals. The repository documents the current default command but does not record the run-level provenance of the final 264-address dataset.
A label-construction sensitivity analysis using alternative values, such as bot_min_tx values of 500, 1,000, and 2,000, and human_max_tx values of 20, 50, and 100.

For each threshold setting, please report the sample size, class balance, address overlap, label changes, and retrained model metrics. Please describe this as a sensitivity or robustness analysis of the label-construction rule.

2. Records from the manual verification

The report says that all 251 training addresses were manually reviewed and that the manual judgments agreed with every heuristic label. We need the records behind that statement.

Please provide:

The annotation guidelines and the criteria used for human_like, bot_like, and cases that could not be determined.
A per-address review table containing the address, initial heuristic label, final manual label, and the evidence or reason for the manual judgment.
The number and background of the annotators, and whether they could see the heuristic labels before making their judgments.
If more than one annotator participated, whether they reviewed the addresses independently, how disagreements were resolved, and any inter-annotator agreement results.
If one annotator conducted a non-blind review, please describe the process that way and revise references to independent verification or gold-standard labeling.

The repository also contains conflicting descriptions. REPORT.md says that all labels were manually verified, while train_eval.py, the classifier README, and eval_results.json describe them as “heuristic proxy labels, not verified ground truth.” Please state which description is accurate and update the repository so that all files use the same wording.

If the manual review records were not retained, please say so rather than reconstructing them retrospectively as contemporaneous evidence. In that case, the report should describe the labels as heuristic proxies. The 95.24% result should then be presented as accuracy against those proxy labels, without treating it as verified accuracy in identifying human and automated wallet ownership.

The Committee can continue reviewing the architecture and deployment work while these questions are addressed.

Best,
HZ

mulinya · August 10, 2026, 3:06pm

Hi zz_tovarishch,

Firstly I apologise for the time it took to respond .I wanted to complete the full rerun (transaction-count analysis and sensitivity analysis) and submit everything together, rather than send a half-baked response and follow up piecemeal.

I do appreciate the Committee’s scrutiny here and it has made the methodology and limitations of the current baseline substantially clearer than the original report did.

Correction to an earlier draft of this response, previously I stated “all 250 addresses have is_special = false.” That’s not accurate. Checking the actual retained data: is_special was never populated for the vast majority of addresses .

Only 13 of the 264 committed addresses have any retained value for it at all, and those are all null/unset, not confirmed false. There is no confirmed observation of is_special = true anywhere in the retained data, but “never observed true” and “confirmed false” are different claims, and I don’t want to overstate this.

1. Basis for the heuristic labels

is_special

The initial assumption behind is_special was that it could indicate an address performing automated or special-purpose activity that might behave differently from a normally operated human wallet.

More importantly: the code itself never lets is_special produce a bot_like label in the first place. It only appears as an exclusion condition on the human_like path (and not is_special).
So regardless of its actual values, it structurally cannot be the “alone” or “both” driver of any bot_like label under the current rule.

For the current dataset:

is_special alone: 0
Transaction-count threshold alone: 160
Both: 0

All 160 bot_like addresses were selected through the transaction-count threshold. I removed is_special from the labeling logic .This is because both it is not contributing to the current dataset and because it was never structurally able to.

Threshold basis

Current heuristic thresholds:

human_like: 1-50 lifetime transactions
bot_like: >=1,000 lifetime transactions
Addresses between these ranges: excluded

These are initial heuristic choices, not based on a formal CKB-specific study, known-identity dataset, or established research source. They’re being used as initial proxy-label boundaries, and the sensitivity analysis (§4) is the test of how robust the resulting labels and model are to changes in them.

2. Data collection and sampling

Command used:

python3 fetch_real_data.py --n-blocks 500 --max-per-pool 40 --max-tx-per-address 300 --out-dir data/real

Note: - - max-per-pool 40 caps each bucket at 40 addresses per invocation, enforced across runs via the resumable checkpoint .A single run of this exact command can’t produce the committed 160/104 split.
The command was run multiple times (resuming from checkpoint each time) to reach that total.
I don’t have the per-run parameter history to say how many invocations or whether --max-per-pool was ever changed. Flagging this rather than implying the single command above fully explains the dataset size.

Transaction-history lookback is capped at 200,000 transactions per address (–skip-tx-count-above, default), to reduce Explorer timeouts.
Returned transaction history is capped at 300 per wallet (–max-tx-per-address).
The classification query (/addresses/{address}) returns the lifetime transaction count as a single number, but the history endpoint used for feature extraction returns only a sample, capped at that 300.

This means:

Human-like wallets with <=50 lifetime transactions have their complete history represented within the 300-tx cap.
Bot-like wallets with >=1,000 lifetime transactions have only up to 300 transactions represented out of a much larger history.

We missed including the full transaction-count distribution and related statistics in the first training round .That round focused on extracting samples and training the baseline model, and this was overlooked. It’s being corrected in the current round: lifetime transaction counts, threshold distributions, class composition, label changes, and the sensitivity analysis are now included (§4).

3. Run-level provenance

The original data collection did not record run-level provenance . The commit hash, collection date, exact block range are not recorded, and I’m not reconstructing or estimating them retrospectively.

One clarification worth adding: The current version of fetch_real_data.py already contains a log_run_provenance() function that writes exactly this (timestamp, args, block range, git commit hash) to data/real/run_log.jsonl on every run, unconditionally.
Since no such file exists anywhere in the repo, either this logging was added to the script after the original collection ran, or it was present and the resulting log simply wasn’t committed.
I don’t have a way to determine which from what’s in the repo now, but it’s worth resolving .
If it’s the latter, the log may still be recoverable locally even though it isn’t in git.

No manual additions or removals were made to the dataset during the initial collection process. For the current rerun, collection parameters and provenance are being recorded explicitly (into run_log.jsonl) so the dataset going forward has a reproducible record.

4. Sensitivity / robustness analysis - complete

This is now done. Full results are committed to the repo as label_sensitivity_analysis.xlsx: ckb-intel/label_sensitivity_analysis.xlsx at main · FadhilMulinya/ckb-intel · GitHub (source: sensitivity_results.json, produced by sensitivity_analysis.py, which reuses train_eval.py’s model-selection/evaluation code directly rather than reimplementing it, so results are directly comparable to eval_results.json). Please see the linked spreadsheet directly for the full breakdown.

All 9 combinations of bot_min_tx in {500, 1,000, 2,000} x human_max_tx in {20, 50, 100} trained successfully.
Random Forest was selected in every case; held-out accuracy stayed in the 95.2%-100% range throughout.

bot_min_tx	human_max_tx	n_bot	n_human	held-out acc	changed vs. current
500	20	160	66	98.3%	25
500	50	160	86	95.2%	5
500	100	160	91	95.2%	0
1000	20	160	66	98.3%	25
1000	50	160	86	95.2%	5
1000	100	160	91	95.2%	0
2000	20	90	66	100%	95
2000	50	90	86	95.5%	75
2000	100	90	91	95.7%	70

Findings

Human-side labels drift over time, bot-side labels don’t.
At the current thresholds (1,000/50). Re-deriving labels from freshly-fetched lifetime tx_count drops 5 of the 91 originally-trained human_like addresses to excluded (none moved to bot_like).
This is expected: tx_count only grows over time, so an address just under 50 at original collection can drift past it before a re-check. bot_like shows zero drift at any bot_min_tx >= 1,000 . Mechanically guaranteed, since an address that already cleared 1,000 can’t fall back below it.
Raising bot_min_tx to 2,000 is a valid, meaningful test, only 90 of the original 160 bot_like addresses (56%) still clear a doubled threshold.
Caveat .
The bot_min_tx = 500 rows are not evidence of robustness to a looser bot threshold. This analysis can only relabel addresses already in the 264-address committed pool, and every currently-labeled bot_like address in that pool already has tx_count >= 1,000 by construction.
Testing bot_min_tx = 500 against this same pool necessarily returns the identical 160 addresses . It can’t reveal whether an address with true lifetime tx_count in [500, 999) exists in the wider population, since such an address would have originally landed in the excluded gap and never been fetched.
The sweep is only informative for raising thresholds above the originals, not lowering them. The spreadsheet flags this explicitly (orange rows + note) so it isn’t misread as a robustness result.
Known gap: the script currently outputs aggregate counts only, not the identity of the 5 drifted addresses. If the per-address review table (7) needs them named, the script needs a small patch to emit that list - not a re-run.

This is being presented explicitly as a sensitivity/robustness analysis of the label-construction rule, with the scope limitation above stated as part of the result, not left implicit.

5. Annotation guidelines and criteria

The current review uses the same heuristic framework used to construct the proxy labels (1-50 = human_like, >=1,000 = bot_like, excluded in between).
Wallet transaction history is then inspected to determine whether observed activity is broadly consistent with the assigned heuristic category.
There is no separate formal ground-truth definition of “human” or “bot,” and no formal “could not be determined” category - addresses outside the selected ranges are excluded rather than assigned an uncertain class.
This matches the code exactly: classify_address returns None for out-of-range addresses, and None-bucket addresses are never fetched or added to a pool.

6. Manual review and annotators

Two people: myself and wakoTheDev · GitHub, Paul wako is an experienced AI/ML engineer also contributing to this project.
We reviewed addresses separately, examining transaction histories against the heuristic categories.
Heuristic labels were visible during review , this is not a blind annotation process. Reviews were conducted separately but are not independent gold-standard annotations, since we both worked within the same heuristic framework.
No disagreements were formally recorded, no formal disagreement-resolution procedure was applied, and no inter-annotator agreement statistic was calculated, because this was not conducted as a formal independent annotation study.

7. Per-address review records

The original per-address annotation records were not retained as a contemporaneous dataset, and I’m not presenting a reconstruction as though it existed during the original review.
Ask: We can produce a new, structured per-address review table (address, initial heuristic label, manual review result, transaction-history evidence/reason) if explicitly required as part of the rerun .

8. Repository wording and the 95.24% result

The accurate description is: heuristic proxy labels, not verified ground truth. REPORT.md’s statement that all labels were manually verified is not accurate and is inconsistent with train_eval.py, the classifier README, and eval_results.json, all of which already use the correct language. I have corrected REPORT.md (§2.2, §2.3 compliance table, §7) to match.

The reported 95.24% accuracy is accuracy against the heuristic proxy labels , it is not verified accuracy for identifying human vs. automated wallet ownership. The manual wallet review is being treated as supporting inspection of transaction histories, not formal ground-truth verification.

9. Sampling limitations

Two, not one:

Transaction-window asymmetry. Human-like wallets (<=50 lifetime tx) have their complete history captured within the 300-tx return cap.
Bot-like wallets (>=1,000 lifetime tx) only ever have up to 300 transactions represented out of a much larger history.
Timing/interval features for bot-like wallets are therefore computed from a partial window, not full lifetime behavior.
Label decay over time (new - surfaced by the sensitivity analysis, §4): because tx_count only grows, the human_like/excluded boundary is not stable even at fixed thresholds.
A re-check today already shows ~5.5% of the trained human_like class (5/91) has drifted out of range since original collection.
Any future dataset refresh should expect a similar decay rate specifically in the human_like class, and the report should describe “91 human_like addresses” as a snapshot as of the original collection date, not a static property of those addresses going forward.

Both limitations are being explicitly considered when interpreting current model results and incorporated into the revised analysis.

The transaction-count analysis, sensitivity analysis, and per-address review table were not included in the first training round .A clear omission on our side, made when these provenance requirements weren’t yet defined.

This response and the attached files correct that gap. I appreciate the Committee’s scrutiny here. It has made the methodology and limitations of the current baseline substantially clearer than the original report did.

Best,
Fadhil

zz_tovarishch · August 13, 2026, 8:47am

Hi @mulinya,

The committee reviewed your latest update. The methodology contains a fatal weakness. The static threshold using transaction volume is an invalid boundary for human and bot activity. User transaction counts naturally grow over time and cross this boundary. This approach lacks meaning for blockchain behavior analysis.

Valuable machine learning must focus on dynamic behavioral patterns and asset flow characteristics. The system needs to mine complex structures like loop transactions, fixed high-frequency intervals, and fund distribution networks. The current data extraction limits prevent the observation of these temporal network features.

We provide one final opportunity to pivot the project direction. The next update should present a model using meaningful behavioral features. If the project cannot deliver feature engineering built on rational on-chain behaviors, the committee will close this grant application.

Best regards,

Spark Program Committee
cc @Hanssen @yixiu.ckbfans.bit @xingtianchunyan