[DIS] Quantir Risk Intelligence for CKB Ecosystem and Cross-Chain Monitoring

[Quantir]

Quantir proposes to build a CKB-aware risk intelligence and monitoring layer for the Nervos ecosystem. The system will monitor selected public CKB ecosystem activity, detect abnormal behavior, compute normalized risk signals, and deliver explainable alerts for developers, ecosystem operators, dashboards, and community monitoring workflows.

Quantir is an existing DeFi and on-chain risk monitoring platform with live collectors, transaction monitoring, risk scoring, alert delivery, API/WebSocket interfaces, and explainability services. This proposal adapts the existing Quantir architecture to CKB-specific ecosystem signals rather than building a monitoring system from scratch.

Requested budget: $30,000 equivalent in CKB.
Estimated duration: 10 weeks.
Payment structure: milestone-based.

Project Motivation
CKB is a flexible and interoperable Layer 1 with a unique Cell model, xUDT/token capabilities, cross-chain potential, Bitcoin-related infrastructure, payment-channel development, and a growing application ecosystem. This flexibility is valuable, but it also makes ecosystem monitoring harder.

Developers and operators can inspect raw activity through explorers, dashboards, and individual tools, but there is no unified layer that turns ecosystem activity into structured, explainable risk signals. Important conditions such as unusual token flows, bridge-related stress, abnormal contract or cell activity, liquidity pressure, payment-channel anomalies, or DAO fund-flow risks may be noticed only after they become obvious.

Quantir aims to provide earlier and clearer visibility by converting fragmented public signals into normalized scores, alerts, and explanations.

Proposal Overview
Quantir will build a CKB-specific monitoring module focused on public ecosystem signals. The system will collect and normalize selected CKB activity, detect abnormal patterns, score risk conditions, and generate alerts that can be consumed by dashboards, bots, APIs, or ecosystem monitoring tools.

The proposed module will focus on:

CKB ecosystem activity monitoring.
xUDT/token-flow anomaly detection.
Bridge and cross-chain activity monitoring.
CKB DeFi and liquidity-risk signals.
Abnormal contract/cell activity detection.
DAO/community fund activity monitoring.
Fiber/payment-channel risk signals where public data is available.
API/WebSocket-ready alert outputs.
Human-readable explanations for risk events.
Validation examples and technical documentation.

This work will not modify CKB consensus, CKB-VM, core protocol code, or wallet infrastructure. It will operate as an external monitoring and intelligence layer using public or reviewable ecosystem signals.

Technical Approach
The implementation will reuse Quantir’s existing multi-service architecture and adapt it to the Nervos ecosystem.

Core components:

Data ingestion layer
Collects selected public CKB ecosystem signals, including token activity, contract/cell behavior, DAO-related activity, DeFi signals, bridge-related events, and other supported public data sources.

Signal normalization layer
Transforms raw activity into comparable risk features such as flow intensity, concentration, repeated address patterns, abnormal activity spikes, liquidity changes, and risk-score deltas.

Risk scoring layer
Computes normalized risk scores and score changes for monitored entities.

Strategy layer
Detects abnormal activity patterns and triggers alert conditions.

Explanation layer
Generates human-readable explanations describing why an alert was triggered, what evidence supports it, and what changed.

Delivery layer
Outputs structured alert payloads suitable for APIs, WebSocket streams, dashboards, and bots.

Example alert output:

Alert category: xUDT flow anomaly
Severity: medium
Risk score: 71
Reason codes: sudden transfer spike, repeated address pattern, abnormal concentration
Evidence: transaction hashes, token identifier, addresses, timestamps
Explanation: “This token activity was flagged because transfer frequency increased sharply while repeated address patterns and concentrated flows appeared within the same monitoring window.”

Deliverables
CKB-specific monitoring scope and architecture document.
Public signal taxonomy for CKB ecosystem risk.
Structured alert schema.
CKB-aware ingestion prototype.
Risk scoring and anomaly detection logic.
Explainable alert generation.
API/WebSocket-ready output format.
Reference consumer or integration example.
At least 5 alert categories.
At least 10 sample alert scenarios.
Setup guide and testing documentation.
Final validation report.

Key Performance Indicators
At least 5 CKB-specific risk categories documented.
At least 10 sample alert scenarios produced.
Working prototype that generates structured CKB ecosystem alerts.
Alerts include severity, score, reason codes, evidence, and explanation.
Reference consumer can read or display alert outputs.
Documentation allows reviewers or developers to understand and test the prototype.
At least 3 validation examples completed.
Final report delivered to the Nervos community.

Milestones and Timeline
Total duration: 10 weeks.

Milestone 1: Scope, CKB Signal Taxonomy, and Architecture
Timeline: Weeks 1-2
Funding requested: $6,000 equivalent in CKB

Deliverables:
CKB-specific monitoring scope.
Public data-source mapping.
Risk category taxonomy.
Initial alert schema.
Technical architecture document.
Implementation plan.

Success criteria:
At least 5 risk categories are defined.
Initial alert schema is complete.
Data-source assumptions and technical scope are documented.

Milestone 2: Ingestion Prototype and Normalized Risk Signals
Timeline: Weeks 3-5
Funding requested: $9,000 equivalent in CKB

Deliverables:
CKB-aware ingestion prototype.
Normalized signal generation.
Initial scoring logic.
Sample alert generation.
Basic test coverage for core signal processing.

Success criteria:
Prototype can process selected public CKB ecosystem signals.
Structured alerts are generated from sample or public data.
At least 5 alert categories are implemented in sample form.

Milestone 3: Explainable Alerts and Integration Outputs
Timeline: Weeks 6-8
Funding requested: $8,000 equivalent in CKB

Deliverables:
Explanation logic for alert events.
API/WebSocket-ready alert format.
Reference consumer or integration example.
Sample documentation for external consumers.

Success criteria:
Alerts contain severity, score, evidence, reason codes, and explanation.
Reference integration can consume alert outputs.
Documentation explains how ecosystem tools can use the outputs.

Milestone 4: Validation, Documentation, and Final Delivery
Timeline: Weeks 9-10
Funding requested: $7,000 equivalent in CKB

Deliverables:
At least 3 validation examples.
At least 10 sample alert scenarios.
Final setup guide.
Testing guide.
Final technical report.
Public or reviewable repository with schemas, prototype code, examples, and documentation.

Success criteria:
Reviewers can inspect or run the prototype.
All milestone deliverables are documented.
Final report summarizes results, limitations, and recommended next steps.

Budget
Total funding requested: $30,000 equivalent in CKB.

Budget breakdown:

Engineering and CKB-specific integration: $12,000
Risk signal design and scoring logic: $5,000
API/WebSocket-ready outputs and reference integration: $4,000
Validation, testing, and documentation: $4,000
Infrastructure, data access, storage, and monitoring: $3,000
Grant reporting and contingency: $2,000

Payment structure: milestone-based.
Suggested initial payment: 20% of total budget, with the remaining amount distributed after milestone review.

Team
The project will be delivered by the Quantir core team.

Ilya Berdar — Senior Blockchain Developer / Project Lead
Responsible for technical architecture, CKB integration scope, risk engine adaptation, grant communication, and final delivery.

Andriy Boichuk — Senior Software Developer
Responsible for backend services, data ingestion, infrastructure, normalization logic, tests, and deployment workflows.

Alex Grishenko — Senior Software Developer
Responsible for alert schemas, explanation outputs, reference integration, documentation, validation examples, and product implementation.

Relevant Links
Quantir landing page: https://landing.quantirintelligence.com/
Quantir app: https://app.quantirintelligence.com/
Quantir GitHub repository: https://github.com/quantirintelligence/quantir-risk-engine

Long-Term Plan
If the pilot is successful, Quantir can expand CKB ecosystem monitoring to additional applications, bridges, tokens, DAO fund flows, DeFi systems, and payment-channel infrastructure. The long-term goal is to provide an explainable risk intelligence layer that helps the Nervos ecosystem improve visibility, resilience, and integration readiness.

Additional Notes
Quantir’s differentiator is that it combines monitoring, scoring, explainability, and alert delivery in one workflow. It does not only show charts or raw events; it translates ecosystem behavior into actionable, interpretable, machine-readable outputs.

This proposal is implementation-focused and designed to deliver reusable monitoring infrastructure for the Nervos ecosystem.

[toastmanAu]

I see you’re an existing risk platform. Your repo mentions you’re focused on uniswap and balancer monitoring which are not relevant on Nervos currently. Could you provide links to your existing implementations and outline other networks you’re currently attempting to integrate with. I couldn’t find them via google search and could only find your other enquiries from the last 2 weeks about grants on other blockchains.

[Ckroamer]

How do you identify RISKs you listed for CKB network? I guess there exists huge gap between UTXO-based blockchain and the Account-based ones, because I see your main experience is put on EVM-based blockchains, I hope you understand the difficulty of integration on CKB.

[Quantir]

The current public repository largely reflects an early stage of development, where the main focus was on Uniswap and basic balancing. At this point, the system has evolved significantly and goes beyond the scope of a single network or a specific DEX.

The architecture is now built around a protocol + network model, which allows us to scale the solution to different ecosystems without being tightly tied to a specific implementation (e.g., Uniswap). We are already working on integrating multiple networks (including L2) and expanding the set of data sources and risk factors.

Some of our current work has not yet been published, as it is under active development and is being used in MVP/closed beta testing.

We plan to update the public repositories soon so that they better reflect the current state of the system and support for multi-network architecture.

If you are interested in specific integrations or architectural solutions, we would be happy to discuss them in more detail.

[Quantir]

At the current stage, Quantir supports three main EVM networks: Ethereum, Base, and Arbitrum. These networks give us a strong initial foundation for protocol monitoring, liquidity analysis, smart contract activity, token flows, whale behavior, and transaction-level risk signals.

At the same time, we are actively working on integrating CKB. We are doing this intentionally, not as a generic “add one more chain” step, but because we want the architecture to support fundamentally different network models from the beginning.

For our platform, this is important because Quantir is focused on predictive risk analytics, not only historical dashboards. If we design the system only around EVM assumptions, it becomes harder to support ecosystems where the data model, state representation, and transaction semantics are different. CKB is valuable for us exactly because it forces the architecture to become more flexible at the collector, normalization, and risk-feature layers.

The main challenge is that CKB cannot be handled with the same logic we use for EVM chains. On EVM, we can rely heavily on contracts, events, logs, token transfers, pool activity, admin methods, and standardized interfaces. With CKB, we need a dedicated integration layer that understands its cell-based model, script logic, capacity movements, state transitions, and ecosystem-specific liquidity/activity patterns.

Another challenge is cost and prioritization. Expanding across every EVM chain at this stage is expensive and not always strategically useful. Instead, we are focusing on Ethereum, Base, and Arbitrum as the EVM core, while also integrating CKB to make sure the platform is architecturally ready for non-EVM ecosystems.

So the goal is not just “CKB support” as a checkbox. The goal is to make Quantir capable of comparing risk across different blockchain architectures while keeping the high-level risk categories consistent: liquidity risk, concentration risk, protocol health, abnormal activity, dependency risk, and early-warning predictive signals.

From our perspective, DeFi execution is shifting away from simple CEX/DEX comparison and isolated swap monitoring toward solver, intent, routing, and cross-chain execution layers. We already see this with models like UniswapX, CoW Protocol, 1inch Fusion/Fusion+, and the broader ERC-7683 direction, where users express the desired outcome and solvers, fillers, or resolvers compete to execute it across liquidity sources and chains.

For Quantir, this means risk analytics cannot be limited only to standard EVM pool monitoring. If execution moves into intent-based and cross-chain routing systems, then predictive risk analysis also has to understand where liquidity, settlement, routing, and execution risk may appear across different network architectures.

[Ckroamer]

Can you showcase some concrete examples about monitoring on CKB? like how do you monitor suspicious xUDT events, I’m curious about your detailed treatments.

[Quantir]

On CKB we’re mostly interested in behavioral and flow-based monitoring rather than only simple address tracking.

For xUDT specifically, suspicious activity can be detected through several layers:

abnormal mint/burn patterns;
sudden liquidity migration between RGB++ / DEX environments;
large holder concentration shifts;
coordinated transfer bursts across newly created addresses;
bridge-related anomalies between EVM / CKB environments;
repeated cell fragmentation/consolidation behavior that differs from normal user activity.

We also analyze:

transaction graph structure;
velocity changes;
wallet clustering;
admin/operator activity;
liquidity shock events;
abnormal approval or settlement flows.

Since CKB uses a cell-based architecture, monitoring logic differs significantly from standard EVM event indexing.
We’re currently adapting our risk-engine architecture to support:

cell-level state interpretation;
xUDT movement analysis;
intent/solver routing flows;
cross-chain liquidity intelligence.

The goal is not only alerting, but predictive risk scoring and behavioral anomaly detection across the ecosystem.