Formal Verification of Solidity Smart Contracts via Automata Theory

Abstract

Smart contracts, as a critical application of blockchain technology, significantly enhance its programmability and scalability, offering broad application prospects. However, frequent security incidents have resulted in substantial economic losses and diminished user trust, making security issues a key challenge for further development. Since smart contracts cannot be modified after deployment, flaws in their design or implementation may lead to severe consequences. Therefore, rigorous pre-deployment verification of their correctness is particularly crucial. This paper explores the symmetry in control flows and state transitions of Solidity smart contracts and leverages this inherent structural symmetry to develop a normalized state transition model based on a finite state machine. The FSM model is subsequently formalized into a Promela model with the Spin model checker. By integrating manually defined Linear Temporal Logic formulas with those generated by Smart Pulse, the Promela model is formally verified in Spin to ensure the correctness and security of smart contracts. This approach establishes a systematic verification framework, providing effective support to enhance the reliability and security of smart contracts.

1. Introduction

In [1], Satoshi Nakamoto formally introduced the concept of blockchain, emphasizing the prevailing reliance of online transactions on trusted third parties. This dependency not only increased transaction costs but also introduced unnecessary complexities into transaction processes. To address these challenges, Nakamoto proposed a peer-to-peer digital currency system, known as Bitcoin, which marked the beginning of the blockchain era. At its core, blockchain functions as a distributed ledger that employs cryptographic algorithms and consensus mechanisms to ensure user privacy while eliminating the need for intermediary trust in transactional activities.

In recent years, smart contract platforms, represented by Ethereum [2], have undergone significant development. By the end of 2024, the number of Ethereum addresses exceeded 220 million, with a total market capitalization surpassing USD 400 billion [3]. The concept of smart contracts, first introduced by Szabo [4], was designed to enforce transactions between two or more parties through the automated execution of program code. The primary objective of this design is to utilize digital methods to disseminate, verify, or execute contract terms, thereby minimizing reliance on trusted intermediaries and ensuring the automatic fulfillment of contractual obligations. The decentralized, transparent, trustworthy, collectively maintained, and immutable nature of Ethereum makes it an ideal platform for smart contract execution. With technological advancements, smart contracts have become a fundamental component of blockchain applications. They not only foster novel digital economic models but are also extensively applied in domains such as digital identity, the Internet of Things, and supply chain management. Furthermore, they underpin the development of decentralized applications (dApps) such as wallets, prediction markets, instant messaging platforms, blogs, and crowdfunding systems [5]. These developments highlight the vast potential of smart contracts in shaping the future.

However, despite the inherent characteristics of smart contracts, such as automatic execution and immutability, their code remains susceptible to vulnerabilities. Given that smart contracts often manage substantial digital assets and cannot be modified once deployed, any potential flaw may be exploited by attackers, resulting in significant financial losses or even catastrophic consequences. Numerous cases have demonstrated that smart contracts deployed on public blockchains frequently contain security vulnerabilities, leading to the theft of cryptocurrency worth hundreds of millions of dollars [6,7,8]. Therefore, ensuring the correct and secure execution of smart contracts on blockchains has become a critical and urgent task.

While various verification frameworks such as KEVM [9], Zeus [10], and Verx [11] have been proposed, they often rely on manual annotations, support limited Solidity subsets, or focus solely on safety properties. Crucially, most lack the capability to verify liveness and fairness, leaving a gap in ensuring the full correctness of smart contracts.

In this paper, we propose a novel approach to convert Solidity-based smart contracts into the formal language Promela, and then use the model-checking tool Spin [12] to verify whether the Promela model aligns with the intended functionality of the smart contract, thereby ensuring its correctness. Unlike existing methods, our approach is not limited to security analysis but also extends to the verification of critical properties such as fairness and liveness, which are essential to ensure that the contract reaches its desired state during execution. Notably, liveness properties are particularly important in this context, as smart contracts often involve expected final outcomes, such as “funds will eventually be transferred once specific conditions are met.” For example, in the case of a remote purchase smart contract, a core correctness requirement is that the buyer should be able to recover their funds unless the purchase transaction is successfully completed. This property is essentially a liveness property, ensuring that the fund transfer will ultimately occur. To summarize, this paper makes the following contributions:

• Formal Modeling and Transformation of Smart Contracts: We propose an innovative method to convert Solidity-based smart contracts into the formal language Promela, using a finite state machine (FSM) model that captures the symmetry in contract control flow and state transitions. This provides a structured framework for systematic verification of smart contracts.
• Comprehensive Verification Method Expansion: Our approach extends beyond security analysis to include the verification of key properties such as fairness and liveness, ensuring the correctness, ideal behavior, and expected outcomes of contracts in decentralized environments. This expansion broadens the scope of smart contract verification, addressing not only protection against attacks but also the fairness and final goals of contract execution.
• Blockchain Smart Contract Security Assurance: We introduce a rigorous formal verification mechanism to ensure the security and correctness of smart contracts in decentralized blockchain environments. By formally modeling and verifying the contract execution process, potential logical errors and security vulnerabilities can be effectively identified, preventing deviations from expected behaviors during contract execution and ensuring the transparency and controllability of the contract.
• Model Checking and Verification: We utilize the Spin tool to verify the Promela-modeled smart contracts, employing both manually and automatically generated Linear Temporal Logic (LTL) formulas for comprehensive validation. This ensures the correctness of the contract logic, identifies potential errors and design flaws, and enhances the robustness and trustworthiness of the smart contract.

2. Related Works

In recent years, formal verification of smart contracts has received extensive attention, focusing on three key areas: formal modeling, correctness and security verification, and temporal characterization. Various studies have pushed the development of blockchain technology through a variety of methods and tools, helping to ensure the reliability and security of smart contracts in real-world applications.

2.1. Formal Modeling of Smart Contracts

Hamdaqa et al. proposed a domain-specific language (DSL) [13] designed to help developers create smart contracts and deploy them on blockchain networks, including platforms like Ethereum, Hyperledger Composer, Azure, and DAML. In [14], this approach combines UML class diagrams and state machine diagrams to support modeling smart contracts and their behavioral logic at multiple levels of abstraction. By evaluating examples from the Solidity documentation, the study found a high degree of similarity between the generated contract code and metrics.

Furthermore, according to the definition from Ethereum [15], smart contracts possess FSM characteristics, where the self-executing code running on the blockchain operates through a set of functions that modify the contract state. The smart contract code describes future transactional operations using conditional statements (such as if/when...then), and these operations trigger the subsequent actions [16]. In other words, smart contracts are modeled through the logic of states, operations, and conditions, with their lifecycle involving multiple transitions from an initial state to a final state [17]. Additionally, Mavridou [18] et al. modeled Solidity contracts as state machines using FSolidM, supporting model checking of safety properties and further advancing the formal analysis of smart contracts. Therefore, FSM patterns are considered an ideal choice for modeling smart contracts, as they provide an appropriate level of abstraction to accurately reflect contract behavior [19]. SmartState [20] is a fine-grained state dependency analysis framework based on FSM that automatically detects SRVs in Solidity smart contracts. FSM-SCG leverages FSM and large language models to enhance smart contract generation’s correctness and security via requirement modeling and iterative refinement [21]. Notably, the Solidity documentation explicitly recommends using the FSM pattern for smart contract development, which helps improve modeling accuracy and practicality. Moreover, in [22], a unified model is proposed, defining fully standardized core components for legal smart contracts and providing structured support for legal and behavioral norms.

2.2. Verification of Smart Contracts

In recent years, formal verification of smart contracts has gained increasing attention, leading to the emergence of various verification tools and methods. Early research on the formalization of smart contracts primarily focused on the Ethereum Virtual Machine (EVM) layer. For instance, Hirai [23] provided a formalization of the EVM in Lem, while Hildebrandt et al. used the K-framework [24] to propose KEVM. In contrast to these studies, F* [25] and Zeus also employed formal verification to check the correctness of smart contracts. F* converts Solidity into the F* language and verifies it, but its scope is limited to a subset of Solidity and requires user intervention to prove assertions specified by the user. Zeus, on the other hand, converts Solidity into an intermediate language and uses an SMT solver for verification. To ensure specification compliance, Nehai, Z [26] introduced a generic modeling approach for Ethereum-based smart contract applications and utilized model-checking methods to verify implementation correctness. Bai et al. [27] formalized smart contracts using finite state machines and used the SPIN model-checking tool to verify their correctness, demonstrating the indispensable role of FSM in verifying smart contracts.

VERISOL, SOLC-VERIFY, and KEVMVER [28,29,30] offer correctness property verification based on contract preconditions and postconditions. VERISOL and SOLC-VERIFY rely on user-provided invariants, while KEVMVER automatically generates invariants or converts EVM bytecode into KEVM for verification using the K framework.

ChainSecurity AG introduced the Verx tool, which can perform a combination of symbolic execution and predicate abstraction and automatically extract predicates from contract source code, enabling semi-automated verification of the time safety properties expressed in PastLTL. Jon Stephens et al. proposed the SMARTPULSE tool [31], which builds upon Verx and offers a more efficient verification process. Their work achieves fully automated falsification and verification, eliminating the need for manual intervention while improving the feasibility and accuracy of the verification process. Additionally, research such as TinySol, Featherweight Solidity, and SolidiKeY [32,33,34] has formalized key Solidity features. Although these studies provide important foundations for Solidity formalization, their lack of executability makes them less useful for practical evaluation. A selection of verification tools and their corresponding abstraction levels are provided in Appendix A.

2.3. Checking Correctness and Safety Properties

Many studies focus on analyzing the temporal properties of smart contracts. For instance, in [35], the authors proposed a method for testing whether a smart contract violates past LTL (Linear Temporal Logic) formulas. Similarly, ref. [36] explored how to verify LTL formulas in UML models. The T2 [37] system verifies temporal properties using LLVM, supporting analysis of linear integer arithmetic programs. Moreover, E-HSF [38] introduced a method for converting existentially quantified Horn clauses into existential CTL (Computation Tree Logic) formulas and solving these formulas through counterexample-guided reasoning for verification.

Additionally, typestates [39] provide a method for expressing the correct usage rules for class operations or protocols, and some of the properties we evaluate can also be represented as typestates. These temporal property verifications often rely on formal logical descriptions. The proposed model is implemented in the NuSMV input language to support formal ver-ification, where system properties are specified using CTL [40].

In active verification of infinite-state systems, several methods verify program paths violating LTL properties, such as those in [41,42,43,44]. These methods simplify the verification of liveness properties into a fairness termination problem and use a combination of SMT solvers and ranking function synthesizers to search for unfair termination paths. In the active verification of smart contracts, Sergey et al. proposed the SCILLA [45] intermediate language, and the Coq [46] proof assistant’s manual proof method, which, despite relying on significant manual intervention, has had a profound impact on research in this field.

The commonality of these methods lies in their aim to formalize and verify the temporal properties and liveness characteristics of smart contracts. By utilizing various forms of logic and tools, they provide robust verification mechanisms for the correctness and reliability of smart contracts.

3. Materials and Methods

The methodology proposed in this work for the formal verification of Solidity-based smart contracts is schematically presented in Figure 1. At the theoretical level, the behavioral semantics of the smart contract are abstracted into a finite state machine model, which serves as a formal representation of its execution logic. Based on the FSM abstraction, the original Solidity code is systematically transformed into a Promela specification through a set of well-defined translation algorithms. This Promela model is then subjected to exhaustive verification using the Spin model checker, where specified correctness properties are formally evaluated.

Figure 1. Schematic workflow of our approach.

The overall process comprises three key phases—formal modeling, property specification, and automated verification—thereby enabling rigorous analysis of contract behavior with respect to safety, liveness, and fairness guarantees. Specifically, the method consists of three main stages.

Modeling level: We provide a formal description of Ethereum smart contracts written in Solidity, and by converting them into finite state machines, we successfully create a structured and formal representation of the contract’s execution process and its state transition relations. This formalization provides a solid foundation for subsequent verification. Based on the FSM model, we design a series of algorithms to convert Solidity-based smart contracts into Promela models that can be executed in the Spin tool. This conversion allows the smart contract to be further analyzed and verified using formal model-checking tools, thereby enhancing the understanding and scrutiny of the contract’s behavior.

Formal specification level: we define the functionality of the smart contract using LTL formulas and combine them with LTL formulas automatically generated by the Smart Pulse tool. These combined formulas are then applied in the Spin tool for verification.

Verification level: we use the Promela model obtained in the first stage and the LTL formulas derived in the second stage and input them into the modelchecker tool Spin. This allows us to verify whether the functionality of the formal Promela model aligns with the intended functionality of the Solidity contract, ensuring the correctness and security of the smart contract during execution.

3.1. Formal Description of Smart Contracts

There exist multiple methodologies for the verification of smart contracts. In this context, we adopt an automata-theoretic approach wherein both smart contracts and their properties are formally represented as automata. The primary objective is to rigorously verify that the contract model constitutes a refinement of the specified property.

In the remainder of this section, we provide a formal description of these automata. For illustrative purposes, we employ the example of a smart contract modeling the business process of a remote shopping system. Figure 2 illustrates a simple state machine example of this contract.

Figure 2. A simple state machine.

The execution of smart contracts is from one state to another state, so we can use a contract state machine to represent smart contracts. The smart contract $C_i$ is represented by a six tuple:

$$C_i=(S_i,E_i,V_i,\to ,{\Sigma }_j,{\mathsf{\Gamma }}_j{)}_{\left(i=\mathrm{1,2},j=A,B\right)}$$

Among them,

• $S$ is a finite set of states that represents the different stages of the contract.
• $E$ is a finite set of events.
• $V$ is a finite set of variables.
• $\to :S\times Cond\left(V\right)\times Stmt\times (\Sigma )\to S$ is the deterministic transition relation (where $Cond\left(V\right)=V\times S\to Bool$, and $Stmt=S\times V\to V$).
• $\Sigma \in S$ is the initial state set, which assigns initial values to the contract’s variables and states, $\Sigma :V\to S$.
• $\mathsf{\Gamma }\in S$ is the final state set.

Transitions in the semantics are tagged by pairs of events and variable states, denoting the triggered monitored events and the variable state at that point in time. In the semantics we give to FSM, we only consider the traces that reach end configurations. Then we ignore infinite loops that would never be recorded to the blockchain.

For $s\in S$, a path in $C_i$ starting from $s$ is an infinite sequence of transitions such that if $\mathsf{\pi }$ is not empty, the source of $\mathsf{\pi }\left(0\right)$ is $s$, and the destination of $\mathsf{\pi }\left(i\right)$ is the source of $\mathsf{\pi }(i+1)$ for all $i$ for which these are defined. If $\mathsf{\pi }$ is not empty, define $first\left(\mathsf{\pi }\right)$ as $s$; if $\mathsf{\pi }$ is finite, define $last\left(\mathsf{\pi }\right)$ as the destination of the last transition of $\mathsf{\pi }$. We say that $\mathsf{\pi }$ spells the word $a_0{a}_1\dots$, where $a_i$ is the label of $\mathsf{\pi }\left(i\right)$.

For the smart contract $C_i$, an infinite path is accepted if it visits a state in $\mathsf{\Gamma }$ infinitely often. An (accepting) trace starting from $s$ is a word spelled by a path starting from $s$. A trace of $C_1$ is a trace starting from an initial state. The language of $C_1$, denoted $\mathsf{\tau }\left(C_1\right)$, is the set of all accepting traces of $C_1$. We use an example of a smart contract called Safe Remote Purchase, which is described in the official Solidity documentation (https://docs.soliditylang.org/en/v0.8.26/, accessed on 12 June 2025) to illustrate the method proposed in this paper.

The state machine $C_1$ is a six tuple $(S_1,E_1,V_1,\to ,{\Sigma }_A,{\mathsf{\Gamma }}_A)$, where the contract between the buyer and the escrow named BCC, $S_1$ is the executing state of the contract between the buyer and the escrow. $E_1$ is the set of input events, $V_1$ is the set of variables, and $\to$ is the transition function, where $\to :S_1\times Cond\left(V_1\right)\times Stmt\times \left({\Sigma }_A\right)\to S_1$. ${\Sigma }_A$ is the set of the initial state, ${\Sigma }_A\in S_1$; ${\mathsf{\Gamma }}_A$ is the set of termination states, ${\mathsf{\Gamma }}_A\in S_1$, ${\mathsf{\Gamma }}_A\in \{d,e\}$. The state $S_1$ of $C_1$ can be represented in Table 1.

Table 1. The set of $S_1$.

State	Meaning of Each State
${\Sigma }_A$	Start
$S_{request}/p_a$	Buyer Requests to purchase goods
$S_{confirmed}/p_b$	Buyer pays for goods
$S_{\mathit{int}errupted}/p_c$	Buyer refund or suspension of transaction
$S_{receiving}/p_d$	Buyer receiving
$p_e$	Transaction completed

The state machine $C_2$ is also a six tuple $(S_2,E_2,V_2,\to ,{\Sigma }_B,{\mathsf{\Gamma }}_B)$, where the contract between the seller and the escrow named SBC, $S_2$ is the executing state of the contract between seller and escrow, $E_2$ is the set of input events, $V_2$ is the set of variables, and $\to$ is the transition function, where $\to :S_2\times Cond\left(V_2\right)\times Stmt\times \left({\Sigma }_B\right)\to S_2$. ${\Sigma }_B$ is the set of the initial state, ${\Sigma }_B\in S_2$; and ${\mathsf{\Gamma }}_B$ is the set of termination states, ${\mathsf{\Gamma }}_B\in S_2$, ${\mathsf{\Gamma }}_B\in \left\{\mathrm{4,5}\right\}$. The state $S_2$ of $C_2$ can be represented in Table 2.

Table 2. The set of $S_2$.

State	Meaning of Each State
${\Sigma }_B$	Start
$S_{accept}/q_1$	Seller accepting buyer requests
$S_{refuse}/q_2$	Seller refuses to deal without goods
$S_{confirmed}/q_3$	Seller confirms money in escrow
$S_{\mathit{int}errupted}/q_4$	Seller’s refusal or buyer’s refund
$q_5$	Transaction completed

The set of events $E$ for the two smart contracts above can be briefly summarized as shown in Table 3.

Table 3. The set of contract events $E$.

Event	Event Types for Smart Contracts
a	Initialize transactions between smart contracts
b1	Buyer makes payment
b2	Buyers cancel transactions with sellers
b3	Sellers cancel transactions with buyers
c1	Call revert when entering an error state
c2	Fulfillment of orders
revert	Solidity error-handling functions

In [47], there is an algorithm that consumes any finite subset $C_i$ of smart contract SPR and an $f\in$ Form with $\mathsf{\alpha }f\subseteq C_i$, and produces an SPR $C_1$ with alphabet $C_i$ such that $\mathsf{\tau }\left(C_1\right)$ = $\mathsf{\tau }(f,C_i)$, and there are well-known algorithms that can be used to produce an FSM with alphabet $2^{C_i}$ which accepts exactly the words satisfying $f$ under the state semantics. Let $C_1$ be the same as $C_2$, except the alphabet is $C_i$ and there is a transition $s\stackrel{\hspace{1em}\mathsf{\alpha }\hspace{1em}}{\to }s\prime$ in $C_1$ if $f$ there is a transition $s\stackrel{\hspace{1em}\left\{\mathsf{\alpha }\right\}\hspace{1em}}{\to }s\prime$ in $C_2$. We have

$$a_0{a}_1\dots \in \mathsf{\tau }\left(C_1\right)\iff \left\{a_0\right\}\left\{a_1\right\}\dots \in \mathsf{\tau }\left(C_2\right)$$

$$\iff \left\{a_0\right\}\left\{a_1\right\}\dots {\models }_{s}f$$

$$\iff a_0{a}_1\dots \in \mathsf{\tau }(f,C_i).$$

This indicates that the states within the state machines of different smart contracts demonstrate a form of behavioral symmetry, revealing consistent structural patterns and analogous execution logic across various contract implementations. So let $C_i$ = $(S_i,E_i,V_i,\to ,{\Sigma }_j,{\mathsf{\Gamma }}_j{)}_{\left(i=\mathrm{1,2},j=A,B\right)}$ denote two FSMs over the smart contract. The parallel composition of $C_1$ and $C_2$ is the SPR $C_i$:

$$C_1‖C_2\equiv (S_1\times S_2,E_1\times E_2,V_1\times V_2,\to ,{\Sigma }_A\times {\Sigma }_B,{\mathsf{\Gamma }}_A\times {\mathsf{\Gamma }}_B)$$

where $\to$ denotes

$${\displaystyle \frac{s_1{\stackrel{\hspace{1em}\partial \hspace{1em}}{\to }}_1{s}_1^{\prime } \partial \notin V_2}{⟨s_1,{\mathrm{s}}_2⟩ \stackrel{\hspace{1em}\partial \hspace{1em}}{\to }⟨s_1^{\prime },{\mathrm{s}}_2^{\prime }⟩}} {\displaystyle \frac{s_2{\stackrel{\hspace{1em}\partial \hspace{1em}}{\to }}_2{s}_2^{\prime } \partial \notin V_1}{⟨s_1,{\mathrm{s}}_2⟩ \stackrel{\hspace{1em}\partial \hspace{1em}}{\to }⟨s_1^{\prime },{\mathrm{s}}_2^{\prime }⟩}} {\displaystyle \frac{s_1{\stackrel{\hspace{1em}\partial \hspace{1em}}{\to }}_1{s}_1^{\prime } {\mathrm{s}}_2{\stackrel{\hspace{1em}\partial \hspace{1em}}{\to }}_2{s}_2^{\prime }}{⟨s_1,{\mathrm{s}}_2⟩ \stackrel{\hspace{1em}\partial \hspace{1em}}{\to }⟨s_1^{\prime },{\mathrm{s}}_2^{\prime }⟩}}$$

Using the above axioms, we can combine multiple smart contracts of the same type. The contract state machine $C_1$ and the contract state machine of $C_2$ can be combined to form the entire contract state machine. The following diagram represents the state machine transitions of each smart contract and the combined state machine.

In Figure 3, the initial states of BCC and SBC are denoted as ${\Sigma }_A$ and ${\Sigma }_B$, respectively. Following a series of event-driven transitions, the system reaches the final states ${\Sigma }_A(p_d,p_e)$ and ${\Sigma }_B(q_4,q_5)$. By combining the transition relations of these two distinct smart contracts, we can construct the complete contract state machine. This approach allows us to apply a transformation rule to convert a smart contract written in Solidity into an FSM.

Figure 3. The composition of the smart contract state machine.

After formally defining the smart contract’s FSM, this section details the algorithmic methodology for converting Solidity code into the SPR model. In particular, it systematically maps Solidity variables, statements, functions, and visibility modifiers to their respective FSM components, enabling precise formal representation and analysis.

Figure 4 illustrates the transformation of Solidity smart contract statements into an FSM, mapping code components into states and transitions for structured analysis. On the left is the Solidity code, while the right represents corresponding FSM states. Key components include type declarations, functions, visibility, built-in functions, arithmetic operations, conditionals, and loops.

Figure 4. Algorithm explanation.

In type declarations, data types like uint256, bool, and address are converted into individual states to facilitate identification and handling. For contract functions, each function begins in an Invoke state and transitions to its specific state, enabling clear tracking of function calls. Function visibility, such as that of public, internal, and external functions, maps to distinct states to validate access control logic.

Built-in functions like revert(), transfer(), and assert() are represented as separate states to simulate their execution. Arithmetic operations, such as subtraction and division, are modeled as independent states with transitions representing their sequence. Conditional statements are split into states like If-Branch, Condition Satisfied, and Condition Not Satisfied to simulate logical branching accurately. Loops are broken into states like Loop Start, Condition, Body, and Increment, capturing their iterative behavior.

This FSM model provides a structured representation of Solidity smart contract statements, enabling intuitive modeling and analysis of contract functionality and behavior within the FSM framework. This conversion method supports automated verification, behavioral analysis, and lays the foundation for security checks.

3.2. Converting Smart Contracts to FSM

In this section, we introduce a series of transformation algorithms designed to model a smart contract SC as an FSM. Specifically, Algorithm 1 integrates Algorithms 2 and 3 to construct the SPR model. Algorithm 2 maps the contract’s functions and variables to their respective initial states, where each function is represented by a state named after the function, followed by states that characterize its visibility. Algorithm 3 handles the transformation of function bodies into states and transitions, incorporating relevant parameters into the model. This process generates a state transition system that accurately represents the SC as an FSM. Furthermore, predefined names for certain Solidity statements are employed to enhance the generalizability of the verification model.

Algorithm 1: CREATEStateMachine ($S$,$E$,$V$,$\to$,$\Sigma \ast$,$\mathsf{\Gamma }\ast$)

Call Algorithm 2 and 3 to construct state machine Input: Solidity Source Code Output: SRP Model ($S$,$E$,$V$,$\to$,$\Sigma \ast$,$\mathsf{\Gamma }\ast$)   Initialization 1: Initialize state set $S$ with initial states Σ* 2: Initialize event set $E$ 3: Initialize variable set $V$ 4: Initialize transition function $\to$ 5: Initialize end state set $\mathsf{\Gamma }\ast$   Algorithm 2 Expressions Transformation Algorithm 6: Solidity Statements ← Expressions   Algorithm 3 Statements Transformation Algorithm 7: SRP Model ← Function statements 8: return SRP Model

Algorithm 1 establishes the foundational elements of the FSM, including the state set $S$, event set $E$, variable set $V$, transition function $\to$, initial state set $\Sigma \ast$, and end state set $\mathsf{\Gamma }\ast$. This initialization provides a robust structural baseline for the FSM representation. Subsequently, the FSM is refined through the mapping of Solidity constructs to their corresponding states and transitions, ultimately resulting in an SRP model that comprehensively encapsulates the operational semantics of the contract.

First, as we see in Algorithm 2, the modeling process begins by introducing an initial state S₀, which represents the entry point of the smart contract. If the contract includes variable declarations or a constructor, the algorithm adds S₀ to the state set and establishes a self-transition from S₀ to itself to capture contract-level initialization behaviors.

Then, for each function declaration in the contract, a state named after the function is added, along with a transition from S₀ to the corresponding function state. An event associated with the function declaration is also recorded in the event set.

Within each function, the algorithm systematically models individual statements by translating them into corresponding FSM states and transitions, accompanied by well-defined events to preserve execution semantics. Variable declarations are assigned to ${S_{\_}}_{VarDecl}$ states, and built-in Solidity functions such as revert(), transfer(), assert(), tx.origin, and delegatecall() are abstracted into states labeled by the function name, with transitions from the calling state to the built-in function’s state to represent invocation semantics abstracted into ${S_{\_}}_{SolidityFunc}$ states. Arithmetic operations transition into ${S_{\_}}_{ArithmeticOp}$ states, conditional statements are represented by ${S_{\_}}_{ConditionCheck}$ states, and loop constructs are decomposed into states representing the loop initiation, condition, body, and increment stages.

Algorithm 2: Transform Statements to SRP

Input: Solidity Statements Output: SRP Model ($S$,$E$,$V$,$\to$,$\Sigma \ast$,$\mathsf{\Gamma }\ast$) 1: if Contract variable declarations or constructor exists then 2:  Add initial state S0 to $\Sigma \ast$; 3:  Add state S0 to $S$; 4:  Add transition (S0, S0) to $\to$; 5:  Add event related to contract declarations to $E$; 6: for Each function declaration do 7:  Add state S_name to $S$; 8:  Add transition (S0, S_name) to $\to$; 9:  Add event related to function declaration to $E$; 10: for Each function statement do 11:  if Variable declaration then 12:   Add state S_VarDecl to $S$; 13:   Add transition from previous state to S_VarDecl; 14:   Add variable to $V$; 15:   Add event related to variable declaration to $E$; 16:  if Built-in functions Revert(), Transfer(), Assert(), Tx.origin,    Delegatecall() then 17:   Add state S_SolidityFunc to $S$; 18:   Add transition from previous state to S_SolidityFunc; 19:   Add event related to Solidity function call to $E$; 20:  if Function calls then 21:   Add state S_FuncCall to $S$; 22:   Add transition from previous state to S_FuncCall; 23:   Add event related to function calls to $E$; 24:  if Arithmetic operations Add(a + b), Sub(a - b) then 25:   Add state S_ArithmeticOp to $S$; 26:   Add transition from previous state to S_ArithmeticOp; 27:   Add event related to arithmetic operations to $E$; 28:  if Conditional statements switch(condition), if(condition) then 29:   Add state S_ConditionCheck to $S$; 30:   Add transition from previous state to S_ConditionCheck; 31:   Add event related to condition checks to $E$; 32:  if Loop statements for(int i, condition, i++) then 33:   Add states S_LoopStart, S_LoopCond, S_LoopBody, S_LoopIncr to $S$; 34:   Add transition from previous state to S_LoopStart; 35:   Add transition from S_LoopStart to S_LoopCond; 36:   Add transition from S_LoopCond to S_LoopBody; 37:   Add transition from S_LoopBody to S_LoopIncr; 38:   Add transition from S_LoopIncr back to S_LoopCond; 39:   Add event related to loops to $E$; 40:   Add final states to $\mathsf{\Gamma }\ast$; 41: return SRP Model

Finally, the algorithm appends final states to indicate termination of execution paths, completing the construction of the SRP model that systematically maps the contract’s control flow and semantics into a formal state-transition representation. This meticulous translation enables the FSM to accurately reflect the control flow and logical architecture inherent in the contract’s source code.

Algorithm 3 provides a systematic approach to transform various types of expressions within a smart contract into an FSM representation, ensuring each expression accurately reflects the contract’s logical flow and behavior. The algorithm begins by iterating over each expression $E$ in the set of expressions (lines 1–2). Based on the type of expression, it proceeds to handle specific cases.

• Expressions with Variables ($E_V$): These are expressions that contain at least one local variable. For such expressions (lines 3–13), the FSM introduces a state for each expression $E_V$, with transitions to handle conditional checks and loops, replicating complex execution paths.
• Expressions with Function Calls ($E_F$): These are expressions containing at least one function call, in this case (lines 14–23). The algorithm sets up states and transitions to manage function call sequences and any Ether-sending operations, accurately reflecting interactions within the smart contract.
• Explicit Expressions ($E_E$): These are straightforward expressions without any variables or function calls. The algorithm (lines 24–36) handles arithmetic operations, conditional checks, and loops with constant bounds by creating corresponding states and transitions to maintain logical accuracy in the FSM.

  Algorithm 3: Convert Expressions to Statements

  Input: Expressions $E$ where i =1…N Output: State machine representation of expressions 1: for Every expression $E$ and i = 1..N do 2: if Expression $E$ is of type $E_V$ (with variables) then 3:  Add state Si for expression $E_V$; 4:  Add transition Ti from S_visibility to Si; 5:  if Expression involves conditional checks then 6:   Add state S_Condition; 7:   Add transition Ti from Si to S_Condition; 8:  if Expression involves loops then 9:   Add state S_Loop, S_Loop_condition, S_Loop_increment; 10:   Add transition Ti from Si to S_Loop; 11:   Add transition Ti+1 from S_Loop to S_Loop_condition with guard(condition); 12:   Add transition Ti+2 from S_Loop_condition to S_Loop_increment; 13:   Add transition Ti+3 from S_Loop_increment back to      S_Loop_condition with guard(!condition); 14: if Expression $E$ is of type $E_F$ (with function calls) then 15:  Add state Si for function calls in $E_F$; 16:  Add transition Ti from S_visibility to Si; 17:  if Expression involves sending ether then 18:   Add state S_Sending_ether; 19:   Add transition Ti from Si to S_Sending_ether; 20:  if Expression involves internal/external function calls then 21:   Add state S_Call_function, S_External_call_function; 22:   Add transition Ti from Si to S_Call_function; 23:   Add transition Ti+1 from Si to S_External_call_function; 24: if Expression $E$ is of type $E_E$ (explicit expression) then 25:  if Expression involves simple arithmetic then 26:   Add state S_Arithmetic; 27:   Add transition Ti from S_visibility to S_Arithmetic; 28:  if Expression involves conditional checks without variables then 29:   Add state S_Condition; 30:   Add transition Ti from S_Arithmetic to S_Condition; 31:  if Expression involves loops with constant bounds then 32:   Add state S_Loop, S_Loop_condition, S_Loop_increment; 33:   Add transition Ti from S_Arithmetic to S_Loop; 34:   Add transition Ti+1 from S_Loop to S_Loop_condition with guard(condition); 35:   Add transition Ti+2 from S_Loop_condition to S_Loop_increment; 36:   Add transition Ti+3 from S_Loop_increment to S_Loop_condition with guard(!condition); 37: return SRP model

The algorithm is completed by returning the final SRP model (line 37), representing a faithful simulation of the contract’s structure. Each expression type’s handling ensures that complex behaviors like conditionals, loops, and function calls are captured accurately in the FSM, allowing for a detailed analysis and execution simulation of the contract’s internal logic.

By integrating the outputs from Algorithms 2 and 3, Algorithm 1 constructs a comprehensive SRP model. This model provides an exhaustive FSM representation of all contract functions and state transitions, utilizing predefined state identifiers for various Solidity constructs to enhance generalization within the verification model. This layered methodology establishes a robust FSM-based framework that supports rigorous analysis and formal verification of the contract’s structural and behavioral integrity.

3.3. Modeling Promela Through FSM

To demonstrate our approach to verifying the security of composite smart contracts in blockchain-based collaborative environments—particularly those deployed on the Ethereum platform—we implement a remote purchase security model using Solidity to briefly describe the flow of this smart contract and the flow of the Promela model shown in Figure 5.

Figure 5. Transaction flowchart after formal modeling.

The transaction process of the whole smart contract consists of three main bodies in total, in which the main body Buyer has four phases {Created,Trading,Finished,Revert}, which mainly include inventory inquiries, checking the account balance, acceptance of goods, and initiating the return request. The main Seller model has three phases {Idle,Trading,Finished} which include providing a margin for transactions and registering product information, responding to inventory inquiries, confirming purchase requests and shipping the goods, completing transaction confirmations, and processing return requests. The main Escrow model also has three stages {Initiate,Guard,Execute}, during which it is responsible for registering transactions, securely holding the Buyer’s funds, monitoring the fulfillment of obligations by both parties, handling disputes, and releasing funds to the Seller or processing refunds as needed.

The transaction begins with the Seller in the Idle state. Upon submitting a security deposit and uploading product information to the Escrow, the Seller transitions to the Initiate state. Subsequently, the Buyer enters the Created state by sending a query request to confirm product availability. The Escrow (Guard state) verifies the query with the Seller, who responds with the availability status. If goods are unavailable or the Buyer lacks sufficient balance, the process ends in the Revert state. Otherwise, the Buyer sends a purchase request with payment to the Escrow, which forwards it to the Seller. Upon confirmation, the Seller ships the goods and enters the Trading state. If the Buyer successfully receives the goods, they send a receipt signal, moving to the Finished state. The Escrow then releases the payment and deposit to the Seller, who also enters the Finished state. If the goods are rejected, the Buyer requests a return, and the Escrow refunds the payment while the Seller retrieves the goods and deposit, finalizing the process. This formal process is modeled using Promela for smart contracts.

4. Experiments

After transforming the Solidity-based smart contract into its corresponding Promela model and modeling relevant entities, we proceed to verify the behavioral consistency between the Promela model and the original contract functionality using LTL within a formal verification framework. A two-phase verification strategy is adopted. In the first phase, the functional specifications of the smart contract are formally expressed in LTL. These specifications serve as correctness criteria and are defined with the assistance of Smart Pulse. In the second phase, the Spin model checker is employed to simulate and verify whether the Promela model satisfies the specified LTL properties, thereby ensuring the correctness and reliability of the contract’s execution logic.

We conduct our evaluation using a set of benchmarks that reference and build upon the VerX and Smart Pulse benchmark suites, both of which feature known vulnerability patterns identified in prior research. A selection of these common vulnerability patterns is included in Appendix B for reference. All benchmark data used in our study is publicly available at https://github.com/olstussy/Verification, accessed on 12 June 2025.

4.1. Sculpting Promela Models Using LTL

The correct execution of smart contracts should ensure the orderly execution of the transaction, and the funds should flow safely among accounts during the specific properties to be verified, as follows:

Property 1.

After closing the transaction, the money remaining in all accounts is equal to the money at the beginning of the transaction.

$$\mathsf{\phi }{R}_1\text{: [](seller\_Acc + buyer\_Acc + courier\_Acc + sbc\_Acc + bcc\_Acc==init\_Count)}$$

Property 2.

When a buyer makes a return request and the seller receives the goods, the buyer must eventually receive a refund.

$$\mathsf{\phi }{R}_2\text{: [](seller\_getgoods -> <>( buyer\_back\_fare))}$$

Property 3.

Either the seller will never return the goods themselves until the buyer returns the goods, or the buyer will never perform a return refund action at all, and will only perform a pickup action after paying for the smart contract BCC; otherwise, the pickup will never happen. This means that the system strictly controls the order of the whole process.

$$\mathsf{\phi }{R}_3\text{: ([]((!seller\_back\_fund U buyer\_recfund) || !buyer\_recfund))}$$

&&([]((!pick_goods Upay_bcc) || !pay_bcc)))

Property 4.

If the transaction is successful, the seller’s account balance is the initial balance plus the margin and the price of the item, the buyer’s account balance is the initial balance minus the price of the item, and the escrow’s account balance is the initial balance.

$$\mathsf{\phi }{R}_4\text{: [](get\_success-><>(seller\_Acc==seller\_AccInitpay\_goods+pay\_goods+sbc\_margin)}$$

&&<>(buyer_Acc==buyer_AccInit-pay_goods)&&<>(escrow_Acc==escrow_AccInit))

Property 5.

This property guarantees that the buyer will not be able to request a refund after receiving the goods.

$$\mathsf{\phi }{R}_5\text{: [](buyer\_getgoods -> ! <>( buyer\_refund))}$$

4.2. Generating LTL with Smart Pulse

We put the smart contract Solidity source code into Smart pulse to obtain the LTL generated by this tool according to the function of this smart contract, as shown in Table 4, and then convert the LTL generated by this tool into the LTL that can be recognized in the Promela model according to the variables of Promela and enter it into Spin for verification.

Table 4. Liveness properties in smart pulse.

RefundEscrow	If a user withdraws funds after refunds are enabled, they will eventually be sent the sum of their deposits.	[]((finished(EscrowVault.enableRefunds)) ==>(<>(finished(send(from,to, amt),(to==user&&amt== fsum(EscrowVault.deposit(payee),2, payee==user))))))
	If the beneficiary withdraws after the escrow is ended, they will eventually be sent the sum of all deposits.	[]( !(finished(Seller.withdraw) && finished(Buyer.requestRefund)) )
EscrowVault	If a user requests a refund after refunds are enabled, they will eventually be sent the sum of their deposits.	<>(finished(EscrowVault.deposit)) && <>(finished(EscrowVault.close, (ben==this.beneficiary)))
	If the escrow is closed, the beneficiary will only be sent the sum of all deposits.	<>(finished(EscrowVault.deposit)) && <>(finished(EscrowVault.close, (ben==this.beneficiary)))

Property 6.

Once the EscrowVault.enableRefunds operation is completed, the contract must ensure that, at some future time, the buyer will receive the corresponding refund amount. This refund amount is equal to the total deposit the user made in the EscrowVault.deposit operation.

$$\mathsf{\phi }{R}_6\text{: (buyer\_back\_fare \&\& ((request\_buyer U feed\_seller)==(buyer\_AccInit − pay\_goods)))}$$

Property 7.

This property guarantees that the seller’s fund withdrawal and the buyer’s refund request will not occur simultaneously.

$$\mathsf{\phi }{R}_7\text{: []( !((pay\_sbc -> seller\_get\_succ) \&\& buyer\_back\_fare) )}$$

Property 8.

At some future point, the EscrowVault.close function will be completed, and when this operation finishes, the seller of the current contract will be specified. It emphasizes that before closing the escrow contract, the seller must be correctly identified and complete the necessary operations.

$$\mathsf{\phi }{R}_8\text{:<> (request\_buyer U feed\_seller) \&\& <>(ship\_success U seller\_get\_succ)}$$

Property 9.

Ensures that, for each user, the contract’s deposit and refund operations will both be completed at some point in the future. This means that the contract will not indefinitely block the buyer’s deposit or refund operations, ensuring that the user has an opportunity to complete their deposit and receive the corresponding refund under any circumstances.

$$\mathsf{\phi }{R}_9\text{: (<>(request\_buyer U feed\_seller)) \&\& (<>(buyer\_refund))}$$

Our work rigorously verifies the correctness and security of the remote shopping smart contract by formalizing key properties using LTL. These properties cover fund integrity, operation sequencing, state consistency, and contract liveness, effectively detecting major vulnerabilities such as integer overflow, DoS, TOD, fund leakage, reentrancy, race conditions, and improper finalization. Table 5 summarizes each property’s description, verification purpose, and the primary vulnerabilities addressed.

Table 5. LTL properties and vulnerabilities.

Property	Description	Detects	Main Vulnerabilities
$\mathsf{\phi }{R}_1$	After the transaction ends, the sum of all account balances equals the initial total balance.	Prevents fund misallocation, loss or creation of value.	Integer overflow
$\mathsf{\phi }{R}_2$	If the seller receives returned goods, the buyer must eventually receive a refund.	Ensures liveness and prevents funds being locked.	DoS
$\mathsf{\phi }{R}_3$	Ensures correct operation sequence: return → refund → pickup, and payment before pickup.	Enforces control flow and prevents early/illegal function access.	TOD
$\mathsf{\phi }{R}_4$	Upon successful transaction, seller and buyer balances are updated as per protocol; escrow remains unchanged.	Detects incorrect state updates, faulty fund transfers.	Funds leakage
$\mathsf{\phi }{R}_5$	Once the buyer confirms receipt, refund action must never occur.	Prevents double refunds, ensures finality of transaction.	Reentrancy
$\mathsf{\phi }{R}_6$	Once refund function is triggered, the buyer will eventually receive a refund equal to the original deposit.	Ensures full refund delivery and prevents inconsistency between deposit and refund.	Invariant violation
$\mathsf{\phi }{R}_7$:	Prevents simultaneous execution of seller withdrawal and buyer refund request.	Prevents race conditions and conflicting fund flows.	Race condition/state inconsistency
$\mathsf{\phi }{R}_8$	Before the transaction is closed, the seller must be specified and the seller’s shipping operation completed.	Ensures correct sequencing and state validation before contract closure.	Improper finalization
$\mathsf{\phi }{R}_9$	Every user’s deposit and refund will eventually be completed; the contract must not block any user’s progress.	Guarantees progress of user interactions and avoids indefinite locking.	DOS

These LTL specifications are translated into Promela-compatible formulas and verified using the Spin model checker to rigorously validate the contract’s behavior under all possible executions.

4.3. Model Checking of Smart Contracts

Once we apply the transformation algorithm to generate the Promela model of the smart contract, the verification of the contract’s properties can be reduced to verifying the corresponding properties of the Promela model. For model checking, we use Spin, a formal verification tool based on the Promela language, which is designed to verify the properties of concurrent systems. By exhaustively exploring the system’s state space, Spin automatically checks properties such as safety and liveness and generates counterexamples to reveal potential design flaws.

4.4. Simulation

In the previous section, we formalized the smart contract and transformed it into Pro mela using FSM. Next, we use Spin to perform model checking on the Promela model. We run Spin using bit-state storage and breadth-first search mode. Each time Spin fails, we double the estimated state space until an attack is detected or we reach the memory limit. The final simulation results are shown in Figure 6.

Figure 6. Spin simulation results.

The transaction process include the buyer, seller, escrow, and the smart contract accounts, ensuring secure and regulated execution through multi-party message interactions. First, the buyer sends a request_buyer message to the seller to initiate the transaction. Upon confirmation, the buyer transfers the transaction amount into the smart contract account SBC via the nbg_ok message, ensuring the funds are securely escrowed. SBC then sends a funds_ok message to the seller, signaling that they can prepare for shipment. The seller subsequently sends a request_t message to the escrow to request transportation services. Upon receiving this, the escrow provides confirmation and responds with the carryC_ok message, indicating that transportation preparations are ready. SBC sends a fare_ok message confirming that the transportation fee is in place, allowing the escrow to safely proceed with the delivery. The seller ships the goods and informs the buyer with the ship_success message. Upon receiving the goods, the buyer sends a rec_goods message to SBC to confirm receipt. Based on this confirmation, the SBC smart contract account transfers the payment to the seller, and the seller confirms receipt with the get_success message. Finally, BCC transfers the transportation fee to the escrow.

This transaction process, reliant on the message-passing mechanism, ensures that each participant fulfills their responsibilities and that the funds are transferred transparently and securely in accordance with the transaction rules. From this simulation diagram, it can be concluded that our method of converting Solidity code into Promela models effectively captures all the functionality of the smart contract without errors.

4.5. Verification

Leveraging a prototype conversion algorithm, we systematically generated the Promela model and formally specified a range of smart contract properties using LTL. Building upon the earlier simulation of the Promela model’s execution, we conducted comprehensive verification of both manually defined properties and contract-specific attributes pertinent to our case study. The verification tools employed, along with detailed experimental results and the prototype implementation, are publicly accessible via our GitHub repository (https://github.com/olstussy/Verification, accessed on 12 June 2025).

In this section, we validate both the manually defined LTL formulas and those generated by Smart Pulse through a representative verification experiment. The results of this validation are presented in the figure below.

The results from the model checker Spin in Figure 7 indicate that the search depth reached 9999, exploring 1,084,815 states and nearly 3 million state transitions, with no errors or assertion violations detected. Figure 8 shows the state storage was compressed, occupying 182.93 MB of memory, with a compression ratio of 62.26%. The hash table utilized 128 MB of memory and resolved 34,920 conflicts, with the total memory usage amounting to 311.15 MB. These results demonstrate that the current model satisfies the verification properties, with no deadlock or cycle violations.

Figure 7. Verification result of specific properties.

Figure 8. Memory usage for state-space verification.

We used the method proposed in this paper to verify functional consistency in Spin, and all verifications were successful. A summary of all verification results is shown in Table 6.

Table 6. Properties’ verification results.

LTL Property	Type	States	Transitions	Memory (MB)	Verified
$\mathsf{\phi }{R}_1$	Invariance	1,084,815	3,301,742	311.151	√
$\mathsf{\phi }{R}_2$	Response	967,856	2,869,858	313.397	√
$\mathsf{\phi }{R}_3$	Safety	1,124,427	3,532,446	311.022	√
$\mathsf{\phi }{R}_4$	Liveness	963,291	2,737,076	272.362	√
$\mathsf{\phi }{R}_5$	Safety	1,145,663	3,598,231	315.210	√
$\mathsf{\phi }{R}_6$	Liveness	980,453	2,810,925	276.030	√
$\mathsf{\phi }{R}_7$:	Safety	1,132,450	3,543,678	310.711	√
$\mathsf{\phi }{R}_8$	Fairness	1,169,783	3,669,054	319.409	√
$\mathsf{\phi }{R}_9$	Liveness	970,873	2,756,332	273.862	√

The table illustrates that these properties primarily focus on the security, fairness, and fund protection aspects of the smart contract during the transaction process. Specifically, $\mathsf{\phi }{R}_1$ ensures that the balance of all accounts is consistent with their initial state at the end of the transaction; $\mathsf{\phi }{R}_2$ guarantees that the buyer will receive a refund after a return; $\mathsf{\phi }{R}_3$ controls the transaction flow, ensuring that the actions of the seller and buyer do not conflict; $\mathsf{\phi }{R}_4$ states that, after a successful transaction, the account balances of all parties must meet predetermined conditions; $\mathsf{\phi }{R}_5$ ensures that the buyer cannot request a refund after confirming the receipt of goods; $\mathsf{\phi }{R}_6$ ensures that users will receive a full refund on time after the refund function is activated; $\mathsf{\phi }{R}_7$ prevents simultaneous withdrawal by the seller and refund by the buyer; $\mathsf{\phi }{R}_8$ emphasizes that when the contract is closed, the seller must be correctly designated and complete the relevant actions; and finally, $\mathsf{\phi }{R}_9$ ensures that each user’s deposit and refund operations will be completed at a future point, avoiding indefinite blockage of actions. The verification exhibited a very high accuracy rate. Furthermore, the method proposed in this paper is applicable to a wide range of other smart contracts. Corresponding tests have been conducted, producing the following results.

The data presented in Table 7 demonstrates that our approach exhibits strong applicability and achieves high verification coverage across a diverse range of smart contract categories, particularly in Crowdsale, ICO, and ERC20 token projects. Nevertheless, verification coverage is comparatively lower for certain wallet and gaming contracts, indicating potential limitations in addressing more complex or specialized contract logic. These observations underscore the necessity for further refinement of the verification framework to enhance its capability in handling sophisticated contract scenarios.

Table 7. Smart contract project verification summary.

Project	Properties	Type	Contracts	LOC	Verified
Crowdsale	23	Crowdsale	20	1198	18
Parity-wallet	10	Wallet	2	200	8
Secure-auction	12	Auction	3	149	9
ICO	31	ICO	14	686	27
ERC20	24	Token	6	599	22
Brickblock	10	Token	9	549	8
blockking	8	Game	1	100	7
MRV	12	Token	7	832	10

We applied our proposed method to a range of additional smart contract projects, most of which exhibited strong verification performance. To further assess its effectiveness and generalizability, we conducted a comparative evaluation against several state-of-the-art verification tools—Verx, KEVM, Smart Pulse, and Zeus—using a benchmark suite of 67 tests available at https://github.com/olstussy/Verification, accessed on 12 June 2025. This benchmark set, curated by domain experts, focuses on widely recognized vulnerability classes, including Reentrancy, Transaction-Ordering Dependency, DoS, and race conditions.

Table 8 presents a comparative analysis of each verification tool using standard metrics: true positives (TPs), true negatives (TNs), false negatives (FNs), and false positives (FPs), evaluated across four major vulnerability categories. The results show that our method achieves competitive performance, with relatively high true positive rates and fewer misclassifications in most cases. These findings suggest that our approach can effectively identify a wide range of smart contract vulnerabilities, offering a practical and reliable option for formal verification tasks.

Table 8. Comparative evaluation of smart contract verification tools.

Verx						KEVM				Smart Pulse				Zeus				Our Work
Benchmark	Tests	TP	TN	FN	FP	TP	TN	FN	FP	TP	TN	FN	FP	TP	TN	FN	FP	TP	TN	FN	FP
Reentrancy	17	9	5	2	1	2	2	9	4	13	1	2	0	8	4	4	1	14	2	1	0
Disorder	20	6	10	4	0	4	5	6	6	11	5	3	1	7	9	4	0	15	2	3	0
DOS	11	5	2	3	1	2	2	2	5	8	2	1	0	6	2	2	1	10	1	0	0
Race Condition	8	4	1	2	1	3	1	1	3	6	1	1	0	5	1	2	0	7	1	0	0

We further evaluated our approach using an additional set of 41 tests (Verx’s Benchmark) targeting assertion violations and arithmetic overflows/underflows—common sources of critical smart contract failures. The results reinforce the accuracy and robustness of our method, demonstrating its effectiveness in detecting subtle yet severe vulnerabilities that are often missed by conventional tools.

Through the design of these properties, the smart contract ensures transaction transparency, fairness, and fund security, preventing improper actions and fund losses. Thus, the method we propose demonstrates high functional consistency when converting Solidity smart contracts into Promela models.

5. Conclusions and Future Work

This paper addresses the critical challenges of correctness and security in smart contracts. We introduce a novel approach for transforming Solidity-based smart contracts into formal Promela models through FSMs. Compared to previous methods, our approach not only converts smart contracts into a formal language but also verifies whether they conform to the specifications defined by stakeholders. Our method provides a formal description of Solidity smart contracts, constructs a standardized state transition model through FSM, and transforms it into a formal Promela model. Additionally, we define the smart contract’s security properties using LTL and incorporate formulas generated by the Smart Pulse tool to conduct formal verification in Spin. This process ensures the correctness and security of the smart contracts. The proposed approach offers a systematic verification framework that significantly enhances the reliability and security of smart contracts. It not only reduces the risks associated with design and implementation flaws but also provides strong support for the widespread adoption of secure and reliable blockchain applications.

The method we propose remains largely theoretical, and we plan to focus on automating the conversion of smart contracts into formal languages and verifying their security properties in future work.

In future work, two main research directions will be explored. First, we will expand the scope of smart contracts being verified, including other types of smart contracts written in Solidity and contracts developed using other programming languages. Second, we plan to develop an automated conversion tool using semantic transformation techniques to convert Solidity smart contracts into formal Promela models, which will improve the efficiency of the verification process.