<p><img src="https://user-images.githubusercontent.com/57335825/101614484-dc27cf80-39c1-11eb-9555-e7598b59c083.png" alt="NebulaGraph v1.2.0 release note" /></p>
<p>NebulaGraph v1.2.0 has just released. In this version, the <code>FIND PATH</code> feature has been enhanced; the <code>DELETE</code> function has been optimized. Also, we have fixed some bugs.</p>
<h2 id="post-new-features">New Features</h2>
<ul>
<li><code>FIND PATH</code> support to find paths with or without regard to direction.  And also support to exclude loops in paths. <a href="https://github.com/vesoft-inc/nebula/pull/2398">https://github.com/vesoft-inc/nebula/pull/2398</a></li>
<li>Add ARM64 support to NebulaGraph.<a href="https://github.com/vesoft-inc/nebula/pull/2392">https://github.com/vesoft-inc/nebula/pull/2392</a></li>
<li>Add auto_remove_invalid_space option to indicate whether to remove data from a deleted graph space when restarting the services. <a href="https://github.com/vesoft-inc/nebula/pull/2375">https://github.com/vesoft-inc/nebula/pull/2375</a>, <a href="https://github.com/vesoft-inc/nebula-docs/pull/196">https://github.com/vesoft-inc/nebula-docs/pull/196</a></li>
</ul>
<h2 id="post-improvements">Improvements</h2>
<ul>
<li>Improve the <code>DELETE</code> edges performance. <a href="https://github.com/vesoft-inc/nebula/pull/2404">https://github.com/vesoft-inc/nebula/pull/2404</a></li>
</ul>
<h2 id="post-bugfix">Bugfix</h2>
<ul>
<li>Fix the issue that <code>FETCH PROP ON</code> timestamp properties returns an <code>int64</code> value. <a href="https://github.com/vesoft-inc/nebula/pull/2389">https://github.com/vesoft-inc/nebula/pull/2389</a></li>
<li>Fix the issue that <code>GO m TO n STEPS</code> may lead to OOM errors. <a href="https://github.com/vesoft-inc/nebula/pull/2386">https://github.com/vesoft-inc/nebula/pull/2386</a></li>
<li>Fix the issue that <code>FETCH PROP ON *</code> might return the wrong results when the tag on the vertex has no properties. <a href="https://github.com/vesoft-inc/nebula/pull/2359">https://github.com/vesoft-inc/nebula/pull/2359</a></li>
</ul>
<h2 id="post-upgrade-steps">Upgrade Steps</h2>
<ul>
<li>Stop all Nebula services<ul>
<li>Execute <code>scripts/nebula.service stop all</code> on each machine</li>
<li>Execute <code>scripts/nebula.service status  all</code> to ensure that all processes have exited</li></ul></li>
<li>Install the new RPM package on each machine per your system environment<ul>
<li>Get the package：<a href="https://github.com/vesoft-inc/nebula/releases/tag/v1.2.0">https://github.com/vesoft-inc/nebula/releases/tag/v1.2.0</a></li>
<li>Install the package</li></ul></li>
<li>Start Nebula<ul>
<li>Execute <code>scripts/nebula.service start all</code> on each machine</li>
<li>Execute <code>scripts/nebula.service status all</code> to ensure that all processes have started properly</li></ul></li>
</ul>
<p>Note: If you are currently using NebulaGraph v1.0.0-RC3 or a previous version, please re-load your data after upgrading to v1.2.0.</p>
<p>Here is the GitHub repo of NebulaGraph: <a href="https://github.com/vesoft-inc/nebula">https://github.com/vesoft-inc/nebula</a>. Please feel free to try the latest version. If you encounter any problem, please ask on our Discussions: <a href="https://github.com/vesoft-inc/nebula/discussions">https://github.com/vesoft-inc/nebula/discussions</a></p>

NebulaGraph v1.2.0 has just released. In this version, the `FIND PATH` feature has been enhanced; the `DELETE` function has been optimized. Also, we have fixed some bugs.

Features

System-testing

Dev-log

Performance

Use-cases

Community

Deployment

Tools

Query-language

Graph-computing

Tech-talk

Release-notes

Architecture

News

Source-code

Success-stories

Knowledge-graph

NebulaGraph v1.2.0 Release Note

Benchmarking the Mainstream Open Source Distributed Graph Databases at Meituan: NebulaGraph vs Dgraph vs JanusGraph

Graph Database vs Relational Database: What to Choose?

Difference Between Relational and Non Relational Database

Use cases of graph databases in real-time recommendation

In today’s hyper-connected digital world, ensuring system resilience is an important business necessity. For platforms like BOSS Zhipin, Asian leading job-matching app with millions of monthly active users, even minutes of downtime can erode user trust and impact revenue. The platform relies on a complex web of services, hosts, databases, and network infrastructure. Yet, like many fast-scaling companies, BOSS Zhipin faced a challenge: **traditional monitoring tools were failing to keep up with the complexity of their architecture.**

Enter [NebulaGraph](https://www.nebula-graph.io/), the open-source, distributed graph database that’s helping BOSS Zhipin transform reactive firefighting into proactive, intelligent operations.

# The Operational Challenges Behind Rapid Growth
BOSS Zhipin revolutionized online recruitment with its “direct hiring” model — enabling real-time communication between job seekers and recruiters. But behind the seamless user experience lies a sprawling, multi-team, polyglot tech stack with intricate service dependencies.

As the platform scaled, their O&M team hit a breaking point:
* Data Silos: Metrics, logs, traces, and events lived in separate tools, making correlation nearly impossible.
* High MTTR: Root cause analysis (RCA) relied on tribal knowledge, leading to long mean time to recovery (MTTR) and engineer burnout.

In short, they were diagnosing system-wide outages with fragmented, secondhand information — a recipe for instability.

# Why Graph? Because Systems Are Graphs
The team realized that modern cloud-native systems are fundamentally graphs — services calling services, containers running on hosts, databases tied to networks. Trying to model this with tables or trees was like mapping a neural network with spreadsheets.

They needed a database that could:
* Handle billions of nodes and edges (services, instances, dependencies)
* Support real-time, complex traversals (e.g., “Find all upstream services affected by this DB latency”)
* Scale horizontally and remain highly available
* Allow flexible schema evolution as the system grows

**Technology Selection**
| Dimension               | Neo4j                                                                 | NebulaGraph                                                                                     | Impact on Root Cause Localization                                                                 |
|-------------------------|-----------------------------------------------------------------------|--------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------|
| **Data Model**          | Supports flexible property graph models                             | Also supports property graphs, with customizable properties, labels, and edge types; the model better aligns with actual business structures | Both can meet modeling requirements. However, NebulaGraph provides clearer management of labels and edge types, making it more suitable for maintaining large-scale business graphs. |
| **Performance & Scalability** | Single-node/cluster edition, suitable for medium-sized data volumes | Native distributed architecture with strong horizontal scalability, supporting tens of millions of nodes and billions of edges | In root cause localization scenarios, NebulaGraph can easily handle future growth. |
| **Query Language**      | Cypher: Strong semantic expression capability, low learning cost    | nGQL: Low learning cost, supports graph computation expressions                                 | Both are powerful, but nGQL is closer to engineering practices. |
| **Temporal Capabilities** | Not good at handling time-series data                              | Supports multi-version storage of edges (TimeRank) mechanism                                     | In root cause analysis, service dependencies and performance metrics have clear temporal correlations. NebulaGraph's TimeRank support is crucial. |
| **Ecosystem & Integration** | Rich ecosystem, mature tools and community                        | Rapidly growing ecosystem, compatible with Spark, Flink, Prometheus, Grafana, etc.              | NebulaGraph is better suited for Boss Zhipin system in terms of cloud-native and observability integration. |
| **Operations & Cost**   | Community edition has limited features; enterprise license is costly | Fully open-source, low resource consumption, simple deployment                                  | NebulaGraph has lower costs, which facilitates centralized middleware construction and horizontal rollout. |

After evaluating options like Neo4j, they chose [NebulaGraph](https://www.nebula-graph.io/) — a distributed graph database built for scale, performance, and production-grade reliability.

>“NebulaGraph wasn’t just faster — it was the only solution that could model our entire infrastructure as a living, breathing dependency graph.”
— Wan Jiafei, SRE Engineer at BOSS Zhipin

# Building the Intelligent RCA Engine with NebulaGraph

After completing the technology selection, BOSS Zhipin built a complete root cause location mechanism based on NebulaGraph, focusing on “how to transform complex fault problems into structured graph problems”, covering the four core parts of modeling, collection, calculation and display.
 
![https://www-cdn.nebula-graph.io/blogs/BOSS%20Zhipin%20Demonstration.png](https://www-cdn.nebula-graph.io/blogs/BOSS%20Zhipin%20Demonstration.png)

## Multi-Layer Dependency Modeling
They started by modeling the system across multiple dimensions:
* Horizontal layer: Service-to-service call relationships (HTTP, RPC, SQL)
* Vertical layer: Dependencies between applications and infrastructure (VMs, databases, gateways)
* Root cause dimension: Abstraction of potential failure sources (e.g., configuration changes, resource exhaustion)
* Time-series modeling: Using NebulaGraph’s multi-version edges (TimeRank) to track performance changes over time

## Data Collection and Graph Data Construction
In terms of data acquisition, the system connects multiple key data sources for operation and maintenance, including:
* Trace/Span: service call chain tracing information
* Metric: Performance metrics from Prometheus, JVM, etc.
* Log/Event: log and alarm events
* Infra information: host, container, and middleware resource status.

Data from traces (Trace/Span), metrics (Prometheus, JVM), logs, events, and infrastructure metadata was collected via Kafka, enriched, and loaded into NebulaGraph as a property graph — where edges carry latency, error rates, and timestamps.

## [Graph Algorithms](https://www.nebula-graph.io/posts/Graph-Algorithms-And-How-to-Use-Them) for Smarter RCA
With a clear graph model, BOSS Zhipin implemented a graph-driven root cause analysis process on NebulaGraph:
* Impact Propagation Analysis: Traversing upstream dependencies to find blast radius
* PageRank-Based Scoring: Nodes with high in-degree and error spikes are ranked as top root cause candidates
* Visualized Fault Chains: Automatically generating a “root cause → service → user impact” path

### Use PageRank Algorithm to Dynamically Calculate Node Failure Weight
1. [Data Fusion](https://www.nebula-graph.io/posts/When_AI_Meets_Graph_Databases_Innovating_with_Multimodal_Data_Fusion)

By integrating the three major data sources of link tracking, system indicators, and logs, a unified full-link anomaly topology map was constructed. It was found that multiple true subgraphs appeared scattered in the graph structure, and each subgraph had a “storm center.”

2. Graph Algorithm-Driven Positioning
* Calculation: Rank value is calculated by weighting the node in-degree, link error number, and events.
* Output: TopN faulty nodes with the highest Rank values

3. Association Analysis

Use graph relationships to divide related queues (direct fault nodes) and non-related queues (indirectly affected nodes) to accurately narrow the scope of investigation.

In one case, a network port failure cascaded through a host to an auth-service — NebulaGraph identified the true root cause (network device) in under 20 seconds, not the “storm center” (auth-service) that traditional tools would flag.

# The Results: 20-Second Root Cause
The impact of BOSS Zhipin’s graph-powered operations system has been transformative. 

Mean Time to Recovery (MTTR) has been reduced by over 70%, enabling faster resolution of critical incidents. Incident triage is now 90% faster, allowing engineers to identify and act on root causes within seconds. With a unified, graph-based view of the system, engineers spend significantly less time switching between disparate tools and correlating data manually. 

As a result, post-mortem analyses have shifted from being anecdotal to fully data-driven, improving accountability, accuracy, and long-term system resilience.

**Implementation Plan - Benefits**

Strictly following the three stages of fault response to reduce Mean Time To Recovery (MTTR)

| Fault Stage       | Duration (Max/Avg)                     | Response Measures                                      |
|-------------------|----------------------------------------|--------------------------------------------------------|
| Fault Detection   | 1 min (average convergence time: 20s) | Fault localization, quickly identify root cause        |
| Fault Handling    | 5 min (average response time: 40s)    | Coordinate responsible personnel based on root cause to develop mitigation plan |
| Fault Recovery    | 10 min (average response time: 2 min) | Activate mitigation measures and restore services      |

# The Future: Graph + AI = Autonomous Operations
BOSS Zhipin isn’t stopping at RCA. They’re building toward autonomous operations with:

* Data Agents: AI assistants that analyze graph patterns to surface hidden anomalies
* Root Cause Agents: LLM-powered bots that correlate logs, traces, and topology to predict failures
* Precomputed Subgraphs: Caching common traversal patterns for instant insights

This is the promise of AIOps 2.0 — not just automation, but intelligent, context-aware decision-making powered by graph.

BOSS Zhipin’s journey shows that with the right data model — and the right database — you can turn chaos into clarity, and minutes into seconds.

As systems grow more distributed and ephemeral, traditional monitoring tools are hitting their limits. **Graph databases like NebulaGraph are becoming essential infrastructure for observability, SRE, and platform engineering.**

Discover how BOSS Zhipin uses NebulaGraph to achieve root cause analysis in just 20 seconds. Learn how graph databases power intelligent operations, reduces MTTR, and brings clarity to complex distributed systems.

20-Second Root Cause Identification: BOSS Zhipin Builds Intelligent Operations and Maintenance Based on NebulaGraph

> NebulaGraph supports a rich set of graph algorithms, efficiently transforming hidden relationships into actionable insights. This blog will introduce you to graph algorithms, NebulaGraph Algorithms, and explore how users are using these algorithms in production environments and how to get started.

# Graph Databases and Graph Algorithms
## What is a “Graph”?
Imagine you have a network, vertex represents an independent entity and edges represent the relationships between these entities. This structure consisting of vertices and the edges connecting them is called a “graph”.

![https://www-cdn.nebula-graph.io/blogs/graph%20algorithm-01.png](https://www-cdn.nebula-graph.io/blogs/graph%20algorithm-01.png)

*Fig.1 Using NebulaGraph Studio to Analyze a Company’s Equity*

## What is a [Graph Algorithm](https://en.wikipedia.org/wiki/List_of_algorithms#Graph_algorithms)?

Graph algorithm is a set of smart “problem-solving ideas” or “toolkits” that are specifically used to analyze the relationship network composed of “points” and “lines” and calculate problems about this network.

### Why Do We Need Specialized “Graph Algorithms”?
* **Beyond Simple Queries:** Traditional queries find immediate neighbors, but graph algorithms can analyze the structure and dynamics of the entire network.
* **Quantify the Value of Relationships:** Transform vague “associations” into calculable indicators (such as importance, closeness, and similarity).
* **Discover Hidden Patterns:** Automatically identify communities, key hubs, and communication paths that are difficult to query using traditional relational databases.
### Applications of Graph Algorithms
1. Find the Shortest Path:
* **Question:** When navigating from home (point A) to workplace (point B), how does the navigation plan the fastest or lowest cost route?
* **Graph Algorithm:** The classic shortest path algorithm (such as Dijkstra algorithm) can quickly calculate the path with the smallest total weight (usually representing distance length, travel time or comprehensive cost) among all possible routes from A to B.

![https://www-cdn.nebula-graph.io/blogs/the%20Shortest%20Path.png](https://www-cdn.nebula-graph.io/blogs/the%20Shortest%20Path.png)

2. [Friends Recommendation](https://www.nebula-graph.io/posts/graph_database_for_recommendation_systems):
* **Question:** How does Instagram, X, or Facebook know who you might know and recommend friends to you?
* **Graph Algorithms:** Common neighbor-based link prediction algorithms (such as the Jaccard algorithm) analyze your social network, focusing on your direct friends (first-degree neighbors) and then examining their friends (second-degree neighbors). People with whom you have many common friends (first-degree neighbors) but with whom you are not yet connected are likely to be recommended to you.
3. Page Rank:
* **Question:** How do search engines decide which web pages should appear first when you search for “graph algorithms”?
* **Graph Algorithm:** PageRank algorithm. Its core idea is:
  * Web pages (points) that are pointed to by many other web pages are usually more important (have more scores).
  * A web page pointed to by an important web page will also gain higher importance (an important vote has more weight).
  * The algorithm will continuously calculate the “importance score” of each web page, and the ones with higher scores will be ranked higher.

# Graph Algorithm Types and Application Scenarios
Graph algorithms can be broadly categorized into the following types: 

![https://www-cdn.nebula-graph.io/blogs/Graph%20Algorithm%20Types.png](https://www-cdn.nebula-graph.io/blogs/Graph%20Algorithm%20Types.png)

# Graph Algorithms Supported by [NebulaGraph](https://www.nebula-graph.io/)

![https://www-cdn.nebula-graph.io/blogs/Graph%20Algorithms%20Supported%20by%20NebulaGraph.png](https://www-cdn.nebula-graph.io/blogs/Graph%20Algorithms%20Supported%20by%20NebulaGraph.png)

The above figure shows the basic graph algorithms, and the enterprise version of NebulaGraph supports more high-performance algorithms, such as InfoMap, APSP, DegreeWithTime, HyperANF, etc., and custom graph algorithms based on [ISO-GQL](https://www.nebula-graph.io/posts/Unveiling%20ISO-GQL).

> *Note: When writing the algorithm results into the NebulaGraph, make sure that the tag in the corresponding graph space has properties names and data types corresponding to the table above.*

# How to Use NebulaGraph Algorithm
How do NebulaGraph users unlock business value with graph algorithms?
1. Centrality Analysis – PageRank
 
**When to Use:** When you need to find the most influential or widely cited/connected nodes in the entire network.

**Scenario Examples:** Identifying key opinion leaders on social media; locating core transit accounts in financial transaction networks.

**Use Case:** Boss Zhipin (leading recruitment platform in Asia) integrated three data sources: trace, metrics, and logs, to construct a unified, full-link anomaly topology map. They discovered multiple true subgraphs scattered throughout the graph structure, each with a “storm center”. Therefore, they used the PageRank algorithm to dynamically calculate node failure weights (rank values are weighted by node in-degree, link error count, and events). This algorithm identified the TopN faulty nodes with the highest rank values, enabling rapid root cause identification with an average convergence time of just 20 seconds.

2. Community Discovery - Louvain, Hanp

**When to Use:** When you need to discover hierarchical community structures in large-scale networks.

**Scenario Examples:** Division of interest groups in social networks; segmentation of e-commerce user groups (similar purchasing patterns); and zoning of urban traffic flow.

**Use Case:** China Mobile first built a relationship network based on all mobile users and used the Louvain and Hanp algorithms to discover and mine communities, such as individual credit scores and relationships between individuals. It then scored the community to identify whether it is a fraudulent community or a low-credit community, thereby conducting risk management.

3. Community Discovery-Label Propagation

**When to Use:** When you need to quickly discover communities, or when the network structure is clear and the community boundaries are distinct.

**Scenario Examples:** Identifying user interest circles in real-time recommendation systems; group segmentation along news/information dissemination paths.

**Use Case:** At ZhongAn Insurance, Label Propagation was used in the loan processing phase. Label Propagation primarily propagated information from a specific point Y and derived related points. For example, if a user on the loan processing list is severely overdue, this user becomes point Y, labeled as overdue. Based on established risk control rules, the system checks which points associated with point Y exhibit similar overdue behavior, thereby determining whether these points belong to a community with severe overdue payments.

4. Connected Component/Strongly Connected Component

**When to Use:** CC (weakly connected components) cares about whether paths are connected (ignoring edge direction). That is used to detect isolated islands. SCC (strongly connected components) cares about whether paths are reachable from each other via directed paths. That is used to analyze tight cyclic dependencies.

**Scenario Examples:** Analyzing isolated user groups in social networks (CC); identifying research schools in a paper’s citation network (SCC); analyzing circular dependencies between system modules (SCC).

**Use Case:** ZhongAn Insurance used Connected Component to calculate a user relationship graph. When an unusual number of people (e.g., 50 or 60) mark a mobile phone number as a “family contact”, that number and its associated users constitute a potentially risky community. Being in such an unusual community is a strong signal (sufficient, but not necessary) that the user is at risk, and the user may also be implicated due to relatives involved in illegal activities. Based on this, ZhongAn conducted preliminary risk control flagging and in-depth verification of users within the community.

Graph algorithms turn connected data into actionable insights—from finding key nodes to uncovering hidden patterns. The real value starts when you apply them to your own data.

Ready to explore? Platforms like [NebulaGraph](https://www.nebula-graph.io/) provide the scalable foundation to run these analyses and discover what your data truly knows. Start experimenting today!

This blog will introduce the graph algorithms, NebulaGraph Algorithms, and explore how users are using these algorithms in production environments and how to get started.

What are Graph Algorithms? And How to Use Them?

> The EU’s MiCA Act and OFAC Sanctions are raising the bar for crypto risk control. How can we build secure, compliant systems in this new era? BlockSec, a global leader in blockchain security, offers a solution: a robust risk control system built on NebulaGraph, enabling seamless flow from data ingestion to actionable risk insights. Yunfei Xie, a security R&D engineer at BlockSec, leads work on crypto address tagging and graph databases.

# The Core Idea: From Transaction Data to a Risk Network

## The Atomic Unit: The Transfer as the Core of Fund Flow

All complex on-chain value transfer activities are ultimately reduced to the most basic token transfer.

However, the raw on-chain data is incredibly complex, including batch processing of multiple transfers, complex swap logic, and cross-chain messaging.

Our goal is to build a foundation for risk analysis from these massive and complex on-chain “atomic units”, including noise filtering (such as removing junk tokens) and the establishment of a Fund Flow Graph.

## Risk Network: The Graph is the Skeleton, Labels are the Soul

Imagine you have only raw blockchain data: connections between anonymous addresses, such as the transfer from “0x098b…2f96” to “0x1361…1f39” and then to “0xd90e…f31b.” This data forms an “anonymous skeleton”—we see structured connections but lack meaningful context. We know funds are flowing, but we don’t know who’s moving them, why, or what they represent.

When we assign labels to these addresses and transactions, the data comes to life.

For example, by labeling “0x098b…2f96” and “0x1361…1f39” as “Lazarus Group: Ronin Bridge Exploiter,” and “0xd90e…f31b” as “Tornado.Cash Router,” we can clearly see that the renowned North Korean hacker group, the Lazarus Group, laundered 3,000 ether through the sanctioned mixer Tornado.Cash after the Ronin Bridge attack.

Through labeling, the anonymous skeleton becomes an insightful risk map. Labeling gives meaning to the data, allowing us to accurately identify high-risk entities and behaviors from massive amounts of on-chain data.

## Accurate Portrait: On-Chain Risk Classification System

By combining graph analysis with a sophisticated tagging system, we can accurately profile on-chain risks. The system needs to be able to identify and tag multiple threat types to help us fully understand and respond to the “dark forest” of the crypto world.

As shown in the following figure:
 
![https://www-cdn.nebula-graph.io/blogs/blocksec_01.png](https://www-cdn.nebula-graph.io/blogs/blocksec_01.png)

By accurately identifying and classifying these threats, the risk control system can provide multi-dimensional risk assessment.

# The Implementation: Building the Risk Control System with [NebulaGraph](https://www.nebula-graph.io/)

## Reasons for Choosing NebulaGraph

First and foremost, performance was the primary consideration. **NebulaGraph’s distributed architecture and superior concurrent processing capabilities can easily handle queries on tens of billions of nodes and edges,** ensuring we complete complex graph traversals and analyses in milliseconds.

Secondly, a flexible data model allows us to better depict the complex relationships in the blockchain world. The property graph model in NebulaGraph is ideally suited to capture the rich, multi-layered connections in blockchain data.

![https://www-cdn.nebula-graph.io/blogs/blocksec_02.png](https://www-cdn.nebula-graph.io/blogs/blocksec_02.png)

Finally, ecosystem compatibility is also a key consideration. NebulaGraph natively supports [ISO-GQL](https://www.nebula-graph.io/posts/Unveiling%20ISO-GQL), which reduces the learning curve for our team. Its rich visualization tools and APIs allow us to quickly build intuitive cash flow analysis interfaces.

## System Architecture: Four Pillars of Risk Control System

BlockSec’s risk control system is built on four pillars, which work together to support the functionality of the entire system.

**The Data Layer** is responsible for extracting and processing filtered on-chain fund flow data in real time from various blockchain networks (such as BSC, ETH, and Tron full nodes). This data is mined through data extractors and cleaned using a multi-filter pipeline to ensure data accuracy and relevance.

**The Intelligence Layer** is the “brain” of the system. Through 24/7 intelligence collectors, it draws information from a variety of sources, including public APIs, open-source intelligence (OSINT) feeds, and regulatory agency lists. This raw intelligence is processed through intelligence processors to generate precise address tags, providing critical context for subsequent risk analysis.

**The Storage Layer** is the core infrastructure of the system and is powered by NebulaGraph. NebulaGraph was chosen for its superior graph data storage and query capabilities, which can efficiently handle massive amounts of addresses and transaction relationships, providing a solid foundation for building the risk network.

**The Computation Layer** deploys predefined and custom risk engines. These engines leverage graph data from the Storage Layer and labels provided by the Intelligence Layer to perform advanced risk pattern detection and threat assessment. These engines interact with the system through the nGQL (NebulaGraph Query Language) query interface to obtain real-time risk analysis results.

These four pillars together constitute a powerful encryption risk control system, ensuring efficient operation of the entire chain from data capture to risk insight.

## Qualitative Analysis: Using Labels to Give Data Meaning

Where do labels come from? How can we ensure their accuracy? This is precisely the key to qualitative analysis.

Our label sources are multi-dimensional:

* On-Chain Heuristics: Analyze behavioral patterns from blockchain activity, build phishing detection engines and attack detection engines, and identify phishing addresses and attack transactions.
* Off-Chain Intelligence: This information is gathered from public sources, including social media, official legal documents, and collaboration with third-party intelligence partners. If an address is sanctioned by an official agency or widely identified as a hacker in the public community, it will be labeled accordingly.
* Human Analysis: As an important supplement to the automated system, a team of experts conducts in-depth investigations to verify automated findings and discover new and complex crime patterns that the system may have missed.

We adopt the following strategies to ensure the label accuracy:

* Automated Cross-Validation: The system automatically aggregates and cross-references data from multiple intelligence sources. If an address is labeled as fraudulent by multiple independent sources, the confidence level of that label is higher.
* Human-in-the-Loop Feedback: Leverage product suites (e.g., MetaSleuth, Phalcon, and API services) to form a continuous feedback loop. When analysts use these tools to investigate, any labeling errors or updates they discover can be immediately corrected and fed back into the system, continuously optimizing labeling accuracy and coverage.

## Risk Quantification: Building a Computable Risk Model

To quantify the risk and trace the sources of funds, we apply a heuristic algorithm with the following key steps:

1. Fiat Exposure Calculation

**Objective**: Standardize the USD value of token transfers.

**Approach**: Use price oracles to calculate the USD equivalent for every token transfer. 

2. Time Series Filtering

**Objective**: Ensure temporal consistency in tracing.

**Approach**: Only edges in compliance with a time sequence rule are preserved. An address cannot spend funds that it has not yet received.

3. Haircut Strategy

**Objective**: Focus on the most relevant paths.

**Approach**: Apply proportional weight allocation and introduce a threshold to prune low-contribution or irrelevant paths. This prevents contamination of the result by negligible or noisy funding sources.

Through these steps, we can build a relatively accurate and flexible risk quantification model to provide a quantitative basis for attributing high-risk transactions.

# The Value of Risk Control Systems

## Proactive Prevention: Building a Proactive Defense System

**Core Capability:** Real-time blocking of risky transactions.

**Application Scenario:**
When processing user deposits on an exchange or interactions on a DeFi protocol, an API call can fetch the risk score of associated addresses. If the score exceeds a threshold (e.g., funds from a mixer or sanctioned entity), the system can automatically halt or reject the transaction, stopping the risk at the gate.

## In-Process Control: Raising the Security Baseline of Partners

**Core Capability:** Comprehensive due diligence on counterparties and projects.

**Application Scenario:**
When evaluating a new DeFi project for integration or conducting a large transaction with an institution, graph analysis can review the historical behavior and funding network of their contracts and wallets. This effectively identifies if they have close ties to "high-risk entities," providing critical data for partnership decisions.

## Post-Mortem Forensics: Providing Precise Investigation & Evidence

**Core Capability:** Deep penetration and tracing of on-chain funds.

**Application Scenario:**
After a security incident (like a hack), provide clear, visual fund flow reports for the project team and law enforcement. Our system can quickly trace the complete path of stolen funds through multiple hops, mixers, and into exchanges, securing the crucial time window for asset freezing and recovery.

# Conclusion
Leverage [NebulaGraph](https://www.nebula-graph.io/), BlockSec has built a robust risk control system from transaction data to risk networks. In the future, we believe that NebulaGraph can provide more stable and solid support for the compliant development of global crypto finance.

BlockSec uses graph technology and tagging to turn transaction data into a risk network for crypto compliance. This article covers the core idea, implementation with NebulaGraph, and key benefits.