<p><img src="https://user-images.githubusercontent.com/38887077/87019600-64ccf480-c205-11ea-91f6-7a5092bfae2c.png" alt="Release-note" /></p>
<p><a href="https://github.com/vesoft-inc/nebula">NebulaGraph</a> v1.0.1 is released. Compared with v1.0.0, this release has made improvement in system stability and performance.</p>
<h2 id="post-new-features">New Features</h2>
<ul>
<li>Support <code>uuid()</code> in <code>FIND PATH</code> statement. https://github.com/vesoft-inc/nebula/pull/2209</li>
<li>Support disabling block cache of rocksdb by setting <code>rocksdb_block_cache</code> of <code>storaged.conf</code> to less than or equal to 0.  https://github.com/vesoft-inc/nebula/pull/2177</li>
<li>Adopt <code>folly::SingletonThreadLocal</code> in meta client to avoid multi-threads mitigating lock contention on <code>localCacheLock_</code>, which improves the performance significantly. https://github.com/vesoft-inc/nebula/pull/2165</li>
<li>Support different compression algorithms of storage and setting different compressions for different levels.  https://github.com/vesoft-inc/nebula/pull/2179</li>
</ul>
<h2 id="post-bug-fix">bug-fix</h2>
<ul>
<li>Fix the issue that compaction filter does not work when calls manual compaction. https://github.com/vesoft-inc/nebula/pull/2184</li>
<li>Fix the issue that <code>Leader</code> sends <code>Snapshot</code> in some cases. https://github.com/vesoft-inc/nebula/pull/2150</li>
<li>Fix the issue when <code>UPSERT/UPDATE</code> the new prop of existing data after adding a new prop of tag/edgetype, an error return. https://github.com/vesoft-inc/nebula/pull/2186</li>
<li>Fix the issue that <code>GO m ... n</code> returns an error when m is set to 0. https://github.com/vesoft-inc/nebula/pull/2202</li>
<li>Fix the issue when combining <code>GO n STEPS</code> and <code>|</code> pipe，an incomplete result is returned in some cases. https://github.com/vesoft-inc/nebula/pull/2203</li>
</ul>
<h2 id="post-you-might-also-like">You might also like</h2>
<ul>
<li><a href="https://nebula-graph.com.cn/posts/nebula-graph-1.0-release-note/">NebulaGraph 1.0 Release Note</a></li>
</ul>

Compared with v1.0.0, this release has made improvement in system stability and performance.

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.0.1 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

Imagine you’re trying to find the fastest way to work during rush hour. Your navigation app doesn’t just look at the roads near you—it analyzes the entire city’s traffic network, weighing distance, congestion, and turn restrictions to find the optimal route. That’s not magic—it’s a **graph algorithm** at work.

But what exactly is a graph algorithm? And how can businesses use them to detect fraud, recommend friends, or pinpoint system failures in seconds?

Let’s break it down—from the ground up.

# From Social Networks to Supply Chains: What Is a “Graph”?

At its core, a graph is a way to model relationships. It consists of:

**Nodes (or vertices):** Represent entities—like people, bank accounts, web pages, or servers.

**Edges:** Represent connections between them—like friendships, transactions, hyperlinks, or data flows.

This structure is surprisingly powerful. Whether you’re mapping equity ownership in a corporate group, tracing disease spread, or analyzing user behavior in an app, graphs capture the “who is connected to whom” that traditional tables often miss.

# Why Can’t We Just Use Regular Queries?

You could ask, “Who are Alice’s direct friends?” using a standard database query. But what if you want to know:

* “Which users are indirectly connected to Alice through 3 mutual friends?”

* “Is there a hidden group of accounts coordinating fraudulent transactions?”

* “Which server is the true root cause of this system-wide outage?”

These questions require understanding the shape and flow of the entire network—not just isolated records. That’s where graph algorithms come in.

Think of them as specialized tools for exploring networks. They don’t just retrieve data—they analyze structure, uncover patterns, and quantify influence in ways relational databases simply can’t.

# Three Real-World Problems Solved by Graph Algorithms

## Finding the Best Route: Shortest Path Algorithms
When your GPS reroutes you around traffic, it’s likely using Dijkstra’s algorithm or a variant. It treats roads as edges (with weights for time or distance) and intersections as nodes, then computes the lowest-cost path from A to B—even in massive networks.

## “People You May Know”: Link Prediction Algorithms
Social apps like LinkedIn or Instagram use algorithms like Jaccard similarity to [recommend connections](https://www.nebula-graph.io/posts/graph_database_for_recommendation_systems). The idea? If you and another user share many mutual friends, you’re likely to know each other too. The algorithm scores potential links based on shared neighbors—turning vague “maybe” into actionable suggestions.

## Why This Web Page Ranks First: PageRank Algorithm
Ever wonder why some sites appear at the top of Google? PageRank treats the web as a graph: pages are nodes, and hyperlinks are votes of confidence. A page gains authority not just from how many links point to it, but from how important those linking pages are. It’s a recursive popularity contest—and it works.

# How NebulaGraph Brings Graph Algorithms to Life
[NebulaGraph](https://www.nebula-graph.io/) is a scalable, open-source graph database that natively supports a rich library of graph algorithms—so you can run these powerful analyses directly on your live data, without exporting to external tools.

Whether you’re using the community or enterprise edition, NebulaGraph provides production-ready implementations of key algorithm categories:

| Algorithm               | Description                        | Scenario                                   | Properties name       | Properties type     |
|-------------------------|------------------------------------|--------------------------------------------|-----------------------|-------------------|
| PageRank                | The rank of pages                  | Web page ranking, key node mining          | pagerank              | double/string     |
| Louvain                 | Louvain                            | Community mining, hierarchical clustering  | louvain               | int/string        |
| KCore                   | K core                             | Community discovery, financial risk control| kcore                 | int/string        |
| LabelPropagation        | Label propagation                  | Information spreading, advertising, and community discovery | lpa         | int/string        |
| Hanp                    | Label propagation advanced         | Community discovery, recommendation system | hanp                  | int/string        |
| ConnectedComponent      | Weakly connected component         | Community discovery, island discovery      | cc                    | int/string        |
| StronglyConnectedComponent | Strongly connected component     | Community discovery                        | scc                   | int/string        |
| ShortestPath            | The shortest path                  | Path planning, network planning            | shortestpath          | string            |
| TriangleCount           | Triangle counting                  | Network structure analysis                 | trianglecount         | int/string        |
| GraphTriangleCount      | Graph triangle counting            | Network structure and tightness analysis   | count                 | int               |
| BetweennessCentrality   | Intermediate centrality              | Key node mining, node influence computing  | betweenness           | double/string     |
| ClosenessCentrality     | Closeness centrality                 | Key node mining, node influence computing  | closeness             | double/string     |
| DegreeStatic            | Degree of statistical              | Graph structure analysis                   | degree,inDegree,outDegree | int/string    |
| ClusteringCoefficient   | Aggregation coefficient            | Recommendation system, telecom fraud analysis | clustercoefficient    | double/string     |
| Jaccard                 | Jaccard similarity                 | Similarity computing, recommendation system | jaccard               | string            |
| BFS                     | Breadth-First Search               | Sequence traversal, shortest path planning | bfs                   | string            |
| DFS                     | Depth-First Search                 | Sequence traversal, shortest path planning | dfs                   | string            |
| Node2Vec                | -                                  | Graph classification                       | node2vec              | string            |

The enterprise version goes further—supporting advanced algorithms like InfoMap (for hierarchical communities), HyperANF (for estimating graph size), and even custom algorithms written in [ISO-GQL](https://www.nebula-graph.io/posts/Unveiling%20ISO-GQL), the emerging international standard for graph queries.

*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.*

# Real Companies, Real Impact: How They Use NebulaGraph Algorithms

## Root Cause Analysis in 20 Seconds — [Boss Zhipin](https://www.nebula-graph.io/posts/use_case_boss_zhipin)
Boss Zhipin, a leading recruitment platform in Asia, faced slow incident diagnosis across its microservices. By modeling traces, metrics, and logs as a graph, they applied PageRank to identify “storm centers”—nodes with high failure weights based on error rates and dependencies. Result? Root causes are pinpointed in under 20 seconds, slashing MTTR (Mean Time to Resolution).

## Fraud Detection at Scale — China Mobile
With hundreds of millions of users, China Mobile built a massive social graph and ran Louvain and HANP community detection algorithms. These uncovered hidden clusters—like groups of users sharing devices or locations—then scored each community for risk. Suspicious clusters (e.g., low credit + high churn) triggered automated reviews, reducing fraud losses significantly.

## Risk Propagation in Insurance — ZhongAn Insurance
When processing loan applications, ZhongAn used Label Propagation to spread “risk labels” from known defaulters through the user graph. If a new applicant was tightly connected to multiple labeled high-risk users, the system flagged them for manual review—catching collusive fraud rings traditional rules would miss.

They also used **Connected Components** to detect unusual “family contact” clusters (e.g., 60 people listing the same number as “mom”). Such dense, atypical subgraphs became early warning signals for identity fraud.

# Final Thought: Relationships Are the New Data
In a world drowning in data but starving for insight, the connections between things often matter more than the things themselves. Graph algorithms help you see those connections.

Whether you’re optimizing delivery routes, stopping financial crime, or personalizing user experiences, the power isn’t just in having data—it’s in understanding how it’s linked.

The real value starts when you apply these algorithms to your own data. Try [NebulaGraph](https://cloud.nebula-graph.io/login) today —and turn relationships into results!

Discover what graph algorithms are, why they matter, and how companies like Boss Zhipin and China Mobile use NebulaGraph to turn complex relationships into actionable insights—no prior graph knowledge needed.

What Are Graph Algorithms—and How Can They Solve Real Business Problems?

> 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: Seeing the Hidden Patterns in Web3 Security

By leveraging [NebulaGraph](https://www.nebula-graph.io), a high-performance distributed graph database, BlockSec has built a scalable and real-time risk control system capable of mapping complex on-chain relationships across billions of transactions.

The system transforms raw blockchain data into a dynamic fund flow graph, where advanced graph traversal and analysis enable precise tracking of high-risk activities. With NebulaGraph’s low-latency queries and flexible property graph model, BlockSec efficiently integrates address labels, threat intelligence, and algorithms to identify malicious behavior, trace stolen funds, and assess risk in real time. 

This technical foundation powers capabilities like transaction screening, counterparty due diligence, and post-incident fund tracing — proving that in the world of blockchain security, graph technology is necessary.


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.