INTRODUCTION

(A). BACKGROUND
Blockchain technology has revolutionized digital transactions, and Ethereum is now the most
popular platform for developing and executing smart contracts. In particular, Decentralised
Finance (DeFi) and Non-Fungible Tokens (NFTs) rely on smart contracts, which are self-
contained programs written in languages like Solidity and compiled into low-level Ethereum
Virtual Machine (EVM) bytecode. While the immutability of smart contracts guarantees that
their behavior can’t be changed after deployment, it also means that any hidden bug or
security oversight becomes a permanent part of the code. Once such an issue slips through, it
can quickly turn into heavy financial losses, something the DeFi space has seen more than
once in its major breach history. The 2016 DAO breach—where attackers siphoned off more
than 3.6 million ETH—stands as one of the clearest examples of why stronger security
measures are urgently needed.

When faced with the increasing complexity and rapid evolution of smart contracts and the
EVM environment, traditional security auditing techniques usually fail. As a result, more
advanced techniques are needed to identify minor but harmful vulnerabilities that
conventional tools might miss. Even in cases where the source code is absent or has been
modified due to compiler optimisations, reverse engineering offers an efficient way for
analysts to dissect produced EVM bytecode, rebuild the underlying logic, and identify
vulnerabilities. Additionally, by analysing opcode-level data from smart contract bytecode,
machine learning techniques—such as Random Forest algorithms—have demonstrated
success in identifying patterns associated with fraudulent or insecure activity in DeFi
protocols.

(B). PROBLEM STATEMENT

Even with the steady progress in smart-contract development and security auditing, uncovering the
more obscure and complex flaws buried in EVM bytecode is still a significant challenge—especially in
fast-moving areas like DeFi and NFT projects. The permanent nature of blockchain deployment
exacerbates the scenario; once a defect is discovered after launch, it is typically impossible to
rectify without significant community consensus, costly contract migrations, or other costly
measures.

The majority of static analysis tools currently in use work relatively well on straightforward
problems, but they often become confused by context-specific flaws, Resulting in either a
large number of false alarms or, worse, a complete lack of detection of sophisticated attack
patterns that exploit minor logical faults. Many categories of critical weaknesses remain
poorly understood and frequently evade detection by existing techniques. The DAO issue is a
classic illustration of how inadequate sharing of lessons learned from previous exploits has
frequently resulted in significant losses throughout history.

An automated, quick, and highly accurate method that can consistently identify these elusive
flaws in compiled EVM bytecode is therefore desperately needed by the ecosystem. By
addressing risks prior to contracts becoming live, such a system would enable developers and
auditors to lower the likelihood of expensive exploits drastically.
(C). RESEARCH OBJECTIVES
This study seeks to tackle the highlighted challenges through the following goals:

1. To create a structured and repeatable process for reverse engineering Ethereum EVM
bytecode, enabling the extraction of key structural and behavioural patterns that reveal
potential vulnerabilities—even in cases where the source code is unavailable or has been
heavily altered by compiler optimisations.
2. To explore and implement machine learning methods, with the Random Forest model, to
automatically recognise hidden patterns and indicators of complex security weaknesses
directly within compiled EVM bytecode.
3. To test and measure the performance of the proposed approach in identifying both known
and previously unseen vulnerabilities in real-world Ethereum smart contracts, especially
those used in DeFi and NFT platforms, while overcoming the shortcomings of current
detection tools.
4. To strengthen the overall security of the Ethereum ecosystem by delivering a fast, scalable,
and practical framework that supports early and proactive discovery of risks in smart
contracts before they are deployed.

(D). RESEARCH METHODOLOGY

To provide reliable vulnerability discovery, the suggested approach combines machine
learning and reverse engineering.

Using advanced methods like Ghidra, the Ethereum EVM bytecode is reverse-engineered to
start the process. In this step, the compiled code is broken down into a readable format, and
key components, such as opcode sequences, control flow graphs—which are especially
challenging to accurately reconstruct due to the stack-based architecture of the EVM—data
dependencies, and general structural properties, are extracted. Following their extraction,
these components are arranged into a structured dataset that may be used for machine
learning analysis.

The last step involves training a Random Forest classifier on this dataset using labelled
samples that provide a clear distinction between secure bytecode patterns and those that are
vulnerable. In related tasks, such as opcode-based analysis for detecting fraudulent behaviour
in DeFi protocols, Random Forest has demonstrated impressive performance in the past. The
trained model gains the ability to identify complex and challenging indicators of security
flaws that are frequently missed by manual assessments or traditional static analysis methods.

Lastly, a wide range of real-world smart contracts is utilised to assess the system's
effectiveness thoroughly. To find out the accuracy of the approach in identifying various
types of vulnerabilities commonly found in DeFi and NFT projects, key metrics, including
precision, recall, and F1-score, are calculated. This method guarantees that the approach is
dependable and feasible for actual implementation.
(E). SCOPE
This research focuses exclusively on Ethereum smart contracts which operate using the
Ethereum Virtual Machine (EVM).The subtle and often missed patterns that reveal
significant vulnerabilities in DeFi protocols and NFT initiatives will be the focus of the
vulnerability identification efforts. Reentrancy attacks, integer overflow and underflow
errors, ineffective access control systems, and other logic-related flaws are examples of these.

The Random Forest technique for machine learning-driven pattern detection and Ghidra for
reverse engineering generated bytecode will be the main tools utilised during the project. The
Ethereum network and its own EVM bytecode format will be the only ones used for actual
implementation, testing, and analyzation even if some of the fundamental ideas may apply to
other blockchain platforms.

(F). LIMITATIONS
This study acknowledges some potential limitations that could impact the whole model.
The performance of a machine-learning model depends heavily on the quality of its training data—
its size, diversity, and accuracy all play a major role. When the dataset contains gaps, built-in biases,
or too few examples of rare vulnerability types, the model’s reliability can drop noticeably . Random
Forest can occasionally behave like a "black box," making it difficult to pinpoint the precise
reason why particular bytecode portions are flagged as dangerous, despite its overall strength
and stability.
Because smart contract attacks are constantly changing, new exploit strategies are frequently
developed. To be successful against new threats, the model may therefore require regular
updates and retraining.
The method may struggle to identify runtime-dependent errors or vulnerabilities that are only
visible during specific transaction sequences, as it is primarily static and only operates on
compiled bytecode. For instance, it is particularly challenging to pinpoint problems related to
gas usage in the absence of real execution traces.
Lastly, only EVM bytecode patterns are included in the study. This approach may not be able
to discover defects that start in high-level languages like Solidity but disappear or become
unrecognisable after compilation.

(G). ORGANIZATION OF THE DISSERTATION

This dissertation is structured as follows:

Chapter 2: Related Work This chapter examines previous studies on smart contract
vulnerabilities, traditional static and dynamic analysis methods, and the growing use of
machine learning in blockchain and cybersecurity domains, with a focus on existing
vulnerability detection approaches.

Chapter 3: Background on Ethereum and Smart Contracts This chapter covers essential
concepts, including the Ethereum blockchain, the Ethereum Virtual Machine (EVM)
architecture, the Solidity programming language, and widely known attack patterns targeting
smart contracts.

Chapter 4: Methodology This chapter gives a detailed explanation of the proposed

framework, describing the reverse engineering workflow using Ghidra, the extraction of key
features such as opcode sequences and control flow graphs, the design and training of the
Random Forest classifier, and the complete experimental setup.

Chapter 5: Experimental Results and Analysis. This chapter presents the evaluation
outcomes, including performance metrics, comparisons with current detection tools, and real-
world case studies that highlight vulnerabilities identified by the system.

Chapter 6: Discussion This chapter interprets the results, explores their broader impact,
revisits the study's limitations, and suggests promising directions for future work.

Chapter 7: Conclusion This final chapter recaps the entire research, highlights the key
contributions, and provides closing remarks.
2. LITERATURE REVIEW
Smart contract security has garnered considerable research interest, mainly due to the significant
financial losses incurred by attacks on decentralised applications. This chapter reviews previous
research on the types of vulnerabilities affecting smart contracts, current detection technologies,
and the utilization of sophisticated methods, such as reverse engineering and machine learning, to
improve identification and prevention.

2.1 Smart Contract Vulnerabilities

Smart contracts can revolutionise decentralised systems, but they are also vulnerable to
several mistakes that could cause financial harm and threaten the safety of entire
blockchain networks. These defects, which are related to the decentralised execution
environment, range from simple coding errors to complex logic problems.
The most frequently observed flaws are reentrancy attacks, integer overflow and underflow
bugs, weak access control mechanisms, reliance on block timestamps, transaction ordering
requirements, and gas consumption inefficiencies or exploits.
To systematically categorise these vulnerabilities, several classification frameworks have
been developed. Some methods classify them according to the layer they impact, such as
blockchain-specific characteristics like block data dependencies, low-level virtual machine
execution (EVM), or high-level programming languages like Solidity. Specialised threats in
DeFi, also known as "contract traps," have been identified by other investigations. These th
eats could result from corrupt developer conduct or minor design flaws in financial
procedures.
The irreversible nature of on-chain deployment presents a fundamental challenge: once a
contract is live, it is rarely possible to correct a found problem without hard forks,
migrations, or community-wide collaboration. This fact emphasises how critical it is to find
and fix vulnerabilities before deployment.

2.2 Traditional Vulnerability Detection Methods

In the past, identifying weaknesses in smart contracts depended mainly on established software
analysis methods, which can be grouped into three main categories: static analysis, dynamic
analysis, and symbolic execution.

2.2.1 Static Analysis

Static analysis examines smart contract code without actually running it. Tools in this
category inspect either the high-level source code (such as Solidity) or the compiled EVM
bytecode to spot known vulnerability patterns.
While this approach scales well to large codebases and requires no test environment, it
frequently produces excessive false alarms or misses real threats. The root cause lies in its
dependence on fixed rule sets and pattern-matching logic, which struggle to keep pace with
evolving language features and compiler behaviours.
Early detection systems relied heavily on manual inspection of opcode sequences,
transaction logs, or call traces-methods that proved unreliable and difficult to maintain as
Solidity and its toolchains advanced.
Static analysis tools have been systematically categorised by capacity in more recent
overviews, which have demonstrated their effectiveness across various vulnerability classes.
For example, the ability to identify problems such as reentrancy and transaction misuse has
been significantly improved by automatically generating correct control-flow graphs from
raw Ethereum bytecode.

2.2.2 Dynamic Analysis and Symbolic Execution

Dynamic analysis tracks the smart contract's actions and identifies any hidden vulnerabilities by
running it in real or simulated environments using a variety of inputs. A common technique in this
industry is fuzz testing, which uses random or inaccurate data to attack the contract and induce
unanticipated crashes or security breaches.

Symbolic execution is another sophisticated method that treats inputs as symbolic variables rather
than fixed values in order to investigate all potential execution paths. This method was used by early
programs like Oyente and DefectChecker to systematically find vulnerabilities in Ethereum contracts.

Although symbolic execution offers strong theoretical guarantees of completeness, it faces

substantial practical challenges. The main bottleneck is path explosion, in which the number of
paths grows exponentially with contract complexity. In the complex EVM context, additional
challenges occur during inter-contract calls and cross-procedure analysis, making complete coverage
computationally costly and frequently impractical for big or interconnected contracts.

2.2.3 Limitations of Traditional Methods

Most conventional detection tools depend heavily on hand-defined rules or static pattern
matching, which quickly become outdated and fail to catch novel or multi-step exploits.
Another persistent issue is the inability to model EVM memory behaviour accurately across
all execution paths, which can cause either slow performance or missed vulnerabilities in
tools aiming for completeness.
Moreover, gas-related mechanics are often ignored or oversimplified. This leaves a
dangerous gap: attackers frequently exploit gas limit tricks, out-of-gas denial-of-service, or
block-level gas manipulation-real threats that standard tools rarely address effectively.

2.3 Reverse Engineering of EVM Bytecode

Analysing Ethereum Virtual Machine (EVM) bytecode is essential for securing smart
contracts, especially when the original source code is missing or when compiler optimisations
create discrepancies that only appear at the low-level bytecode stage.
Reverse engineering (RE) enables experts to break down and interpret this compiled code-the
only version permanently stored on the blockchain-to recover the contract's underlying logic
and execution flow.

Tools such as Ghidra play a central role by offering powerful disassembly, decompilation,
and control-flow graph (CFG) generation capabilities. These features allow analysts to
reconstruct program behavior even without access to the high-level source.

However, building an accurate and complete CFG from EVM bytecode remains technically
difficult. The stack-based execution model and dynamic jump targets (computed at runtime)
make traditional control-flow reconstruction unreliable and incomplete in many cases.

Despite these obstacles, reverse engineering delivers critical structural insights and feature
sets-like opcode patterns and data flows-that serve as the foundation for advanced automated
analysis, including machine learning-based vulnerability detection.

2.4 Machine Learning Approaches for Vulnerability Detection

The research community has turned to machine learning (ML) techniques because of the
limitations of rule-based and manual analysis. ML techniques offer automatic, scalable
detection of even the most subtle and detailed vulnerability patterns in smart contracts.
Unlike traditional tools that depend on fixed signatures, ML models learn directly from data,
enabling them to recognise new or evolving threats by training on large collections of both
secure and compromised contracts.
Several algorithms have proven effective in this space. Random Forest, for example, has
been widely adopted due to its robustness and interpretability. When trained on opcode-
level features extracted from smart contracts, it has successfully flagged fraudulent
behavior in DeFi protocols with strong performance metrics, including an F1-score around
80%.
Other approaches leverage deep learning, such as Long Short-Term Memory (LSTM)
networks, which treat bytecode as sequences and capture long-range dependencies in
execution flows-ideal for detecting timing or order-dependent bugs.
Many ML systems operate directly on EVM bytecode, extracting rich features like opcode n-
grams, control-flow paths, and data-flow relationships. Some advanced models go further
by automatically inferring high-level semantics from low-level bytecode, eliminating the
need for handcrafted features and outperforming classical static analysers.
Recent research has also used function call interfaces, contract interaction patterns, and
semantic embeddings to improve context awareness, allowing the detection of logic defects
that span many contracts or rely on external calls.
In relation to their scope, precision, and ability to detect vulnerabilities that were either
previously misidentified or not recognized, these techniques powered by machine learning
represent a significant progress.
2.5 Research Gaps

Despite tremendous advances in the security of smart contracts, this study tries to address some
major gaps:

Detecting Subtle EVM-Level Flaws Current ML approaches show potential, but they often miss low-
signal, high-impact vulnerabilities that evade rule-based detectors-especially in DeFi and NFT
contracts. The fast-evolving attack landscape demands detection systems that adapt quickly to new
exploit patterns as they emerge on the blockchain.

Robust Feature Extraction from Bytecode. Constructing accurate control-flow graphs (CFGs) from
stack-based EVM bytecode continues to be a major bottleneck. A more systematic and
comprehensive feature extraction pipeline is needed to capture fine-grained behavioural traits
suitable for training reliable ML models.

Model Interpretability for Developer Trust. Even effective models like Random Forest can appear
opaque. Developers need clear explanations-not just predictions-of why a specific bytecode segment
is flagged, enabling faster debugging and confident remediation.

Scalability against Emerging Threats. With smart contract logic growing in complexity and new
vulnerability classes appearing regularly, detection frameworks must operate efficiently at scale and
deliver low-latency risk alerts to prevent exploitation in production environments.

This study fills in these gaps by offering an integrated system that tightly couples advanced reverse
engineering (using tools like Ghidra) with targeted machine learning (Random Forest) to perform
high-precision, explainable, and adaptable vulnerability identification directly on EVM bytecode.

It is anticipated that the suggested approach, which highlights the uses of DeFi and NFTs, would
significantly improve detection accuracy as well as the delivery of useful insights. This would lessen
the attack surface inside the Ethereum ecosystem by allowing developers to protect decentralized
apps before they are deployed.
 1

3. METHODOLOGY

This chapter presents the research methodology in a structured yet practical way,

showing how each step contributes to the overall aims of the study. The approach is

built to detect subtle, and at times surprisingly complex, vulnerability patterns in

smart contracts-especially those operating within DeFi platforms and NFT

applications. To make this possible, the method combines machine-learning

techniques with a careful reverse-engineering of Ethereum Virtual Machine (EVM)

bytecode. Doing so transforms dense low-level instructions into features the model

can actually interpret, which is essential for identifying the kinds of nuanced

weaknesses that would otherwise go unnoticed.

The process is structured into five core phases:

1. Research Design & Scope Definition

2. Data Collection and Preprocessing

3. Reverse Engineering and Feature Extraction

4. Machine Learning Model Development

5. Evaluation and Validation

The next sections go into further detail about each step to ensure that the suggested

framework is repeatable, rigorous, and realistic to apply.

3.1 INTRODUCTION

The proposed framework is specifically engineered to overcome the core limitations

of existing intelligent contract security analysis-especially the difficulty of

 2

interpreting compiled EVM bytecode and the scalability bottlenecks of rule-based

systems.

This work presents an automated, scalable, and high-precision detection pipeline

designed explicitly for DeFi and NFT smart contracts, achieved by skillfully

combining advanced reverse engineering with data-driven machine learning.

This method learns vulnerability signatures directly from bytecode behaviour, in

contrast to typical tools that rely on static heuristics or predetermined patterns.

3.2 RESEARCH DESIGN

This study employs a quantitative experimental approach centred on developing and

validating a machine learning classification system.

Its key component is a Random Forest model that is trained on a carefully selected

dataset, which includes EVM bytecode samples classified as either susceptible or non-

vulnerable. To assure impartial and comparable outcomes, the model's performance is

evaluated using standard categorisation measures.

The workflow follows the standard machine learning pipeline:

1. Data Collection & Labelling

2. Preprocessing & Cleaning

3. Feature Engineering

4. Model Training & Tuning

5. Evaluation & Validation

 3

This end-to-end framework improves reproducibility, supports consistent

benchmarking, and moves the vulnerability-detection system closer to being usable in

real-world settings.

3.3 DATA COLLECTION AND DATASET PREPARATION

An excellent, well-organised dataset is the first step in creating a successful machine

learning model. To provide a solid training foundation for the Random Forest

classifier, this section outlines the entire process of data collection, vulnerability

detection, labelling, and preprocessing.

Figure 3.1: Data Collection Pipeline

 4

3.3.1 Repository Selection

The dataset is built from authentic, on-chain Ethereum smart contract bytecode to

ensure maximum realism and relevance. Multiple trusted sources are combined to

create a balanced, diverse, and well-labelled collection of both vulnerable and secure

contracts.

Key data sources include:

Ethereum Mainnet (via Etherscan API) Direct extraction of live deployed bytecode

from verified contracts on the Ethereum blockchain, representing real-world usage in

DeFi and NFT ecosystems.

SmartBugs Dataset: A widely recognized benchmark containing pre-labelled

vulnerable contracts across multiple vulnerability classes, ideal for training and

testing.

High-quality datasets containing injected and actual vulnerabilities, including

reentrancy, timestamp dependence, unhandled exceptions, and transactions, are

included in the Slither-Audited & SolidiFI Benchmark. Misuse of origin, making

controlled experimentation possible.

GitHub & Open-Source Repositories Manually curated, audited, and exploited

contracts from public projects, along with CTF challenges (e.g., Ethernaut, Damn

Vulnerable DeFi), to capture edge cases and advanced attack patterns.

This multi-source strategy assures broad coverage, correct labelling, and

generalization capabillity through various contract types, compilers, and vulnerability

scenarios.
 5

3.3.2 Bug Identification

A key component of supervised learning is correctly classifying contracts as

vulnerable or safe. Security holes in the gathered bytecode samples are methodically

found and confirmed at this stage.

The process begins with well-documented vulnerability classes well observed in

Ethereum contracts, including:

 Reentrancy

 Integer overflow/underflow

 Access control bypass

 Timestamp/transaction order dependency

 Unhandled exceptions

For contracts with pre-existing audit reports or benchmark labels, these annotations

are adopted directly.

 6

Figure 3.2: Bug Identification & Labeling Workflow

 7

For unlabeled or partially labelled contracts, a hybrid verification pipeline is applied:

Automated Scanning Run established static analysis tools (Slither, Mythril,

SmartCheck) to generate initial vulnerability candidates.

Manual Expert Review Security researchers cross-validate tool outputs, focusing on

bytecode-level manifestations of bugs (e.g., unsafe external calls, unchecked

arithmetic, improper use of [Link]).

Consensus Labelling Only confirmed vulnerabilities-agreed upon by at least two

reviewers or supported by on-chain exploit evidence-are assigned positive labels.

This methodical, multi-phase labelling workflow minimises noise, assures high label

accuracy, and prioritises EVM-specific fault patterns that resist compilation and

increase in efficiency.

3.3.3 Labeling

Ensuring that each bytecode sample is labeled correctly as vulnerable or non-

vulnerable is a foundational part of any supervised machine-learning workflow. If

those labels are off, the model’s understanding starts to drift. In this section, I describe

a three-level labeling process built to stay accurate at scale while also reducing the
 8

kinds of bias that can quietly shape security datasets.

Figure 3.3: Labeling Method Levels

 9

Method Description Use Case

Directly adopt pre-validated labels from benchmark Contracts with
Automated
datasets (e.g., Solid I, SmartBugs) for known established audit
Labeling
vulnerability types. tags.
Semi- Use source-to-bytecode mapping (via compiler traces or
Contracts with
Automated "supervising oracles") to propagate high-confidence
source-only audits.
Labeling source-level findings to their compiled form.

Manual Expert Security researchers perform line-by-line bytecode Complex, novel, or

Annotation inspection to confirm subtle or undocumented flaws. tool-missed bugs.

Quality Assurance Measures

 Cross-Validation: Every manually labelled sample is reviewed by at least two

independent experts.

 Bias Control: Annotators are rotated across batches and blinded to prior labels to

prevent familiarity bias.

 Consistency Checks: Inter-annotator agreement (e.g., Cohen's Kappa) is computed

and maintained at a level above 0.8.

 Documentation: Each label includes justification, affected opcodes, and an exploit

scenario for full traceability.

This hybrid, expert-guided labelling technique produces a trustworthy Random Forest

classifier training dataset while lowering noise and ensuring high-fidelity ground

truth.

3.3.3 Data Preprocessing

 10

Figure 3.4: Data Preprocessing Pipeline

Since raw EVM bytecode isn’t something a machine-learning model can make sense

of on its own, the data has to go through a bit of reshaping first. In practice, this

means cleaning it up, pulling out the pieces that actually matter, and turning

everything into a format the model can reason about without getting lost in low-level

noise. In this section, I walk through the preparation pipeline step by step-what tools

were used, why those choices made sense at the time, and the kind of output each

stage produces once the bytecode has been processed enough to be useful.

Step Description Tool / Method

1. Disassembly The raw bytecode is broken down into readable pyevmasm, evm-
 11

Step Description Tool / Method

opcode sequences so both humans and the model
disassembler
can interpret it.
Individual functions-or any risky code blocks-are Runtime analysis +
2. Function
separated out to reduce noise and keep attention function-dispatch table
Isolation
on potentially vulnerable areas. parsing
Each opcode is assigned a unique integer ID, Custom vocabulary +
3. Tokenization
such as PUSH1 → 1 or ADD → 2. integer encoding
All sequences are standardized to a fixed length
4. Sequence Fixed maximum length
using padding or truncation, and attention masks
Padding (e.g., 512 tokens)
are generated alongside.
Control Flow Graphs (CFGs) and Data Flow
5. Graph Ghidra + custom EVM
Graphs (DFGs) are built from the disassembled
Construction CFG recovery
code to clarify structural relationships.

Output Formats

Sequence-based:

[60, 60, 1, 91, 80, 63, ...] # Tokenized opcode IDs

[1, 1, 1, 1, 0, 0, ...] # Attention mask

Graph-based (for GNNs):

 Nodes: Opcodes with features (type, stack effect, gas cost)

 Edges: Control flow (JUMP), data flow (stack push/pop)

Because of its multi-modal preprocessing, the Random Forest model and its future

modifications may learn from both sequential patterns and structural correlations seen

in EVM bytecode.
 12

3.4 FEATURE ENGINEERING

This end-to-end framework improves reproducibility, supports consistent

benchmarking, and moves the vulnerability-detection system closer to being usable in

real-world settings.

Figure 3.5: Feature Engineering Categories

Feature Categories
 13

Category Key Features Rationale

• Opcode counts (unigrams) • N-gram Gives a direct look at how the
1. Opcode-
patterns (bi/tri-grams) • Opcode-level contract behaves at the
Based
entropy instruction level.
• Nodes, edges, basic blocks • Cyclomatic Shows how the contract’s
2. Control complexity • Longest path depth • logic branches and how
Flow (CFG) Loop/back-jump signals • Patterns linked to execution moves around
reentrancy internally.
• Read/write activity • Taint paths from Helps spot issues in how data
3. Data Flow
inputs → sensitive actions • Stack moves and where it might leak
(DFA)
irregularities • Unchecked external calls or misbehave.
4. Tool- • Flags from Slither/Mythril • Confidence or Makes use of what established
Augmented risk scores tools already know.
• Function count and size spread • Dispatcher
5. Structural Adds higher-level context that
patterns • Pseudocode embeddings (when
& Hybrid raw opcodes can’t fully show.
available)

Final Feature Vector

Each contract/function is represented as:

X = [opcode_freq[256], ngram_counts[1000], cfg_metrics[10], dfa_flags[8], ...]

→ High-dimensional, sparse, interpretable input for Random Forest.

Our layered feature design lets the model pick up on both small-scale execution

cues and the broader structure of the program, making it better suited to identify

subtle vulnerabilities that depend heavily on context.

3.5 MODELS

Random Forest is the major classification technique used in this work to discover

EVM bytecode vulnerabilities, and it also provides features for comparing with other

models.
 14

3.5.1 Random Forest Classifier

A Random Forest combines a large number of decision trees, each built from different

sampled data and feature subsets. During prediction, it checks the outputs of all trees

and assigns the class that most of them agree on.

Strength Relevance to This Study

Works well with mixed opcode and graph-based
High accuracy on tabular data
features.
Handles high-dimensional, sparse
Perfect for n-grams, CFG stats, and DFA-style flags.
inputs
Helps explain why a contract is flagged - important
Built-in feature importance
for audits.
Robust to overfitting Stays reliable even when labels are messy or uneven.
Fast inference Makes quick scanning of contracts practical.

3.5.2 Hyperparameter Configuration

Selected Value /
Parameter Justification
Range
n_estimators 500–1000 Helps steady the model and reduce variance.
Lets the forest capture deeper, more subtle
max_depth None (or ~30)
patterns.
min_samples_split 2 A simple setting that keeps overfitting in check.
Cuts down tree similarity and improves
max_features 'sqrt' or 'log2'
diversity.
class_weight 'balanced' Useful when vulnerable samples are fewer.

3.5.3 Comparative & Future Models

Model Use Case Input Type

Learns how opcode sequences unfold over Tokenized instruction
LSTM / BiLSTM
time. sequences.
Spots short, repeating patterns-like small loops
CNN (1D) Sliding opcode windows.
linked to reentrancy issues.
XGBoost / Fast, high-accuracy boosting for structured
Tabular representations.
LightGBM features.
 15

Model Use Case Input Type

Useful for zero-shot detection and explaining
Fine-tuned LLMs Decompiled pseudocode.
suspicious behavior.

3.6 ENSEMBLE METHODOLOGY

3.6.1 Model Selection: Random Forest

A random forest works a bit like a crowd of decision-makers rather than one overly

confident model. Instead of relying on a single decision tree, it builds hundreds of

them, each trained on a shuffled slice of the data and a different mix of features. This

randomness introduces a kind of healthy disagreement among the trees, which oddly

enough makes the final result more reliable. Once all the trees have made their

guesses, the forest settles on whatever answer most of them agree on-a majority vote

that tends to smooth out the mistakes any single tree might make.

Core Mechanism

A Random Forest works by building a large collection of decision trees, each trained

on its own randomly sampled slice of the data and feature set. This randomness

introduces just enough variety among the trees to keep the model from locking onto

noise. When it’s time to make a prediction, the forest simply looks at what the

majority of its trees decide and takes that as the final answer.

Advantage Benefit in This Context

Handles high-dimensional Works seamlessly with opcode n-grams, CFG metrics, and
data DFA features
Robust to noise & outliers Tolerates compiler artifacts and label noise
Reveals which opcodes or patterns drive vulnerability
Built-in feature importance
predictions
 16

Advantage Benefit in This Context

Accepts mixed sparse/dense inputs without preprocessing
No strict scaling required
hassle
Fast training & inference Enables large-scale scanning of on-chain contracts

Figure 3.6: Random Forest Model Architecture

 17

Comparison with Single Decision Tree

Aspect Single Tree Random Forest

Tends to overfit, especially when Much lower risk because multiple trees
Overfitting
the tree grows deep. balance each other out.
Struggles with new or unseen Handles unseen data better thanks to
Generalization
data. model diversity.
Easy to read-just follow one Still understandable, mostly through
Interpretability
decision path. feature importance scores.
Works fine but hits limits in Usually delivers stronger accuracy in
Accuracy
complex tasks. tougher domains.

Figure 3.7: Ensemble vs Single Model

 18

Random Forest is the best option for automatic, scalable, and easily accessible

vulnerability identification in EVM bytecode because it delivers the perfect balance of

accurate, dependable, and useful insights.

 19

Figure 3.8: End-to-End Vulnerability Detection Pipeline