💻 computer science

Assessing Vulnerability in Smart Contracts: The Role of Code Complexity Metrics in Security Analysis

This research demonstrates that while individual software complexity metrics show low correlation with specific vulnerabilities in Solidity smart contracts, their collective analysis effectively distinguishes between secure and vulnerable code, with vulnerable contracts consistently exhibiting higher mean complexity scores.

Original authors: Masoud Jamshidiyan Tehrani

Published 2026-01-26

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Masoud Jamshidiyan Tehrani

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a Smart Contract is like a self-executing vending machine built on a blockchain. Once you put money in and press a button, it gives you a snack automatically. You can't go back and change the machine's internal gears later; it's "immutable." If there's a flaw in the gears, a hacker can steal all the money inside, and there's no way to fix it without building a whole new machine.

This paper is about trying to find those broken gears before the machine is deployed. The researchers asked a simple question: "Can we tell if a vending machine is likely to be broken just by looking at how complicated its blueprints are?"

Here is the breakdown of their findings using everyday analogies:

1. The Core Idea: Complexity is a "Red Flag"

The researchers looked at 21 different ways to measure how "messy" or "complicated" a piece of code is. Think of these metrics as measuring things like:

SLOC (Source Lines of Code): How many pages is the instruction manual?
Nesting: How many layers of "if this, then that" boxes are inside each other? (Like a Russian nesting doll).
Coupling: How many other machines does this one need to talk to in order to work?

The Finding: They found that messy blueprints usually mean broken machines.
When they looked at contracts that had been hacked (vulnerable), those blueprints were almost always more complex, longer, and more tangled than the blueprints for safe contracts.

2. The "Crystal Ball" Problem (Individual Metrics)

The researchers tried to see if one specific measurement could predict a hack.

Analogy: Imagine trying to guess if a car will crash just by looking at the number of cup holders.
Result: It didn't work well. No single metric (like just counting the lines of code) was a perfect "crystal ball." If you looked at only the number of lines, you couldn't reliably say, "This one is definitely going to get hacked." The connection was there, but it was weak.

3. The "Team Effort" Success (Combined Metrics)

However, when they looked at all the measurements together, the picture became very clear.

Analogy: You can't tell if a soup is salty just by tasting the salt shaker, but if you taste the whole bowl, you know exactly how salty it is.
Result: While one metric wasn't enough, the combination of metrics was very good at distinguishing between safe contracts and dangerous ones. The "vulnerable" contracts consistently had higher scores across the board (more lines, deeper nesting, more connections) compared to the safe ones.

4. The Surprising Exceptions

There were three things that went against the "more complexity = more danger" rule:

Comments (CLOC): Safe contracts had more comments (notes written by the programmer explaining the code). Vulnerable contracts had fewer.
- Takeaway: Writing notes on your blueprint seems to help keep the machine safe.
Descendants (NOD): Safe contracts had more "descendants" (versions or children contracts). Vulnerable ones had fewer.
Parameters: Vulnerable contracts actually had slightly fewer inputs/parameters on average.

5. What This Means for Developers

The paper concludes that complexity isn't the cause of the hack (like a virus), but it is a very loud warning sign.

The Analogy: If you see a house with a tangled mess of wires, exposed pipes, and a confusing floor plan, you don't know for sure it will catch fire, but you know it's much more likely to than a house with neat, organized wiring.
The Advice: Developers should try to keep their code simple. If a contract is getting too complicated, it's a signal to stop and check for security holes. Also, write more comments; the data suggests that well-documented code is safer.

Summary

The paper proves that complexity is a strong indicator of risk in smart contracts. You can't rely on just one number to predict a hack, but if you look at the overall "messiness" of the code, you can spot the dangerous contracts much better than if you ignored the complexity entirely. It's a tool to help auditors and developers prioritize which contracts need the most careful inspection.

Technical Summary: Assessing Vulnerability in Smart Contracts via Code Complexity Metrics

Problem Statement
Smart contracts deployed on blockchain platforms like Ethereum are immutable and often handle high-value financial transactions, making security assurance critical. While the underlying blockchain is secure, the smart contracts themselves are vulnerable to exploits stemming from programmer negligence or coding errors. Traditional static analysis tools often rely on pattern matching to detect specific vulnerability types. However, there is a need to understand if structural properties of the code, specifically software complexity, can serve as complementary indicators for identifying vulnerable areas. The authors posit that code differing from established best practices (i.e., higher complexity) may exhibit higher exposure to security defects, yet the specific relationship between complexity metrics and Solidity smart contract vulnerabilities remains an open problem requiring empirical validation.

Methodology
The study employs a quantitative, empirical approach to analyze the relationship between 21 distinct software complexity metrics and the presence of vulnerabilities in Solidity smart contracts.

Dataset: The research utilizes a dataset derived from Liu et al., consisting of 16,239 individual contracts (258 vulnerable, 15,981 neutral) crawled from Etherscan. The vulnerable contracts were labeled based on eight specific vulnerability types: Integer Underflow/Overflow, Dangerous Ether Strict Equality, Reentrancy, Timestamp Dependency, Block Number Dependency, Dangerous Delegatecall, Ether Frozen, and Unchecked External Call.
Metric Extraction: The static analysis tool Solmet was used to extract 21 complexity metrics for each contract. These include size metrics (SLOC, LLOC, CLOC), structural metrics (NF, WMC, NOS), nesting metrics (NL, NLE), inheritance metrics (DIT, NOA, NOD), coupling metrics (CBO, NOI, NA), and average versions of these metrics.
Statistical Analysis:
- Correlation Analysis: Spearman's rank correlation coefficient was used to assess monotonic relationships between metrics and to identify redundancies among the metrics themselves.
- Group Comparison: The Mann-Whitney U test was employed to determine if the distribution of metric values differed significantly between vulnerable and neutral contracts.
- Effect Size: Cliff's Delta ( $\delta$ ) was calculated to quantify the magnitude of the difference between the two groups.
- Confidence Intervals: Used to compare the central tendency (means) of the metrics between vulnerable and neutral groups.

Key Contributions
The paper addresses four specific research questions (RQs) to evaluate the utility of complexity metrics:

RQ1 (Metric Inter-dependency): The study identifies significant redundancy among certain metrics. For instance, SLOC is strongly correlated with NOI, NOS, WMC, and NF. Similarly, nesting metrics (NL, NLE) and their averages show high correlation, suggesting that not all 21 metrics provide unique information for vulnerability detection.
RQ2 (Metric-Vulnerability Correlation): The analysis reveals that while all 21 metrics show a statistically significant correlation ( $p < 0.05$ ) with the presence of vulnerabilities, the strength of these correlations is generally weak (coefficients mostly below 0.3). This contrasts with findings in traditional programming languages where correlations are often stronger. Consequently, no single metric acts as a strong predictor on its own.
RQ3 (Discriminative Power): Despite weak individual correlations, the Mann-Whitney U test confirms that all metrics can statistically distinguish between vulnerable and neutral codes ( $p < 0.05$ ). Most metrics exhibit a large effect size (e.g., SLOC, LLOC, NF, WMC, NL, NOS, CBO, NA, NOI), indicating that the distributions of these metrics are practically different between the two groups.
RQ4 (Directionality of Difference): The study finds that vulnerable contracts generally exhibit higher mean complexity scores than neutral contracts for the majority of metrics. However, there are three notable exceptions where vulnerable contracts have lower values:
- CLOC (Comment Lines): Neutral contracts have more comments, suggesting documentation may mitigate vulnerability.
- NOD (Number of Descendants): Vulnerable contracts have fewer descendants.
- Avg. NUMPAR (Average Parameters): Vulnerable contracts have fewer parameters on average.

Results and Significance
The paper concludes that complexity metrics are indicators rather than direct causes of vulnerability. The primary significance of the findings lies in the following points:

Collective Utility: While individual metrics have weak predictive power, the study demonstrates that when analyzed collectively, complexity metrics possess strong discriminative capabilities. This supports their use as complementary features in automated vulnerability detection tools.
Redundancy Management: The identification of highly correlated metrics (e.g., SLOC vs. WMC vs. NF) suggests that vulnerability prediction models can be optimized by selecting a non-redundant subset of features, improving efficiency without sacrificing accuracy.
Contextual Nuance: The findings highlight unique characteristics of Solidity compared to traditional software. For example, the inverse relationship with comment density (CLOC) suggests that in the context of smart contracts, a lack of documentation is a specific marker of risk.
Practical Application: The authors propose that these metrics can be integrated into existing static analysis tools to prioritize audit efforts. Contracts with high complexity scores can be flagged for deeper manual review, and developers can use these insights to adhere to best practices such as minimizing nesting, reducing coupling, and ensuring adequate documentation.

The authors maintain a modest stance, emphasizing that the observed relationships are statistical associations. They acknowledge that high complexity often correlates with a larger "problem domain" (e.g., complex DeFi protocols naturally require more code), which may be the underlying driver for increased vulnerability risk rather than the complexity metrics themselves being the sole causal mechanism. Future work is suggested to include domain-specific stratification and the exploration of cognitive complexity metrics.