Guiding LLM-based Smart Contract Generation with Finite State Machine

1 Introduction

Blockchain, with its characteristics of immutability, transparency, and decentralization, has demonstrated a wide range of applications in various fields such as finance, supply chain, data sharing, etc [Wang et al., 2018]. As a key component for realizing blockchain systems, the automatic generation of smart contracts has become one of the focuses in current research [Khan et al., 2021].

Smart contracts require precise coding and verification to ensure their effectiveness and security [Almakhour et al., 2020]. Due to the irreversible nature of smart contract execution, any vulnerabilities or errors in the code could lead to serious security risks, or even financial losses [Luu et al., 2016; Sayeed et al., 2020]. Therefore, the ability to quickly and reliably generate fully functional and secure smart contracts has become a critical issue. Previously, the generation of smart contracts relies on manual coding and professional audits of experts, requiring developers to have extensive blockchain programming skills and experience [Mao et al., 2019].

∗Corresponding authors: Jiawei Jiang, HaoWang

In recent years, LLMs have demonstrated significant potential in programming tasks, such as code generation, program repair, and code translation [Poesia et al., 2022; Jiang et al., 2024b]. Motivated as such, LLMs have also shifted the paradigm of smart contract generation. Existing works on LLMs for generating smart contracts mainly focus on direct generation from user requirements to code (R2C) [Napoli et al., 2024; Chatterjee and Ramamurthy, 2024]. Other works transform requirements into intermediate models to guide LLMs in code generation (requirements-to-model-to-code, R2M2C) [Wöhrer and Zdun, 2020; Petrovi´c and Al-Azzoni, 2023; Qasse et al., 2023].

As shown in Table 1, when the LLMs directly generate smart contracts based on user requirements, the code has a low compile pass rate (CPR) and a high vulnerability risk score (VRS). When intermediate states, such as the Contract Modeling Language (CML), IContractML, and the FSM in our proposed method, are introduced to guide the LLMs to generate smart contracts, all metrics significantly improve.

Challenges. Despite pioneering efforts to generate smart contracts using LLMs, there are notable limitations concerning their essential features.

• Effectiveness: Smart contracts typically use low-resource programming languages, such as Solidity, Vyper, and Move, which lack sufficient documentation, libraries, and community support. Consequently, in the internal repre-

sentation space of LLMs, the distribution of low-resource programming languages is often more concentrated compared to high-resource programming languages, such as Python or JavaScript [Li et al., 2024]. This gap causes more syntax errors and incomplete logic in smart contracts, reducing compilation success.

• Security: Existing research [Chatterjee and Ramamurthy, 2024; Jiang et al., 2024a] has found that LLMs frequently overlook security issues when generating smart contract code. This oversight stems from the use of general-purpose LLM services (e.g., ChatGPT, OpenAI Codex), which are not designed for the blockchain domain, potentially introducing security vulnerabilities in the generated contracts.

To address these limitations, we try to study the following question in this work - How to leverage LLMs to generate effective and secure smart contracts?

Our Solution FSM-SCG. Formal methods enable precise modeling of requirements and systems to ensure high reliability and security. FSM, as a formal method, can capture the state changes and condition triggers in smart contract to guide secure and reliable generation[Suvorov and Ulyantsev, 2019]. Therefore, we consider incorporating FSM into the smart contract generation process. Additionally, inspired by the Chain-of-Thought (CoT)[Wei et al., 2022] and Structured Chain-of-Thought (SCoT)[Li♂ et al., 2023] techniques, we divide the smart contract generation process into two subtasks: generating FSMs from user requirements and generating smart contracts from FSMs. Our approach follows a requirement-to-FSM-to-code (R2F2C) generation pattern, guided by FSM throughout the process, which we call FSMSCG. The workflow begins by fine-tuning LLM to enhance its ability to generate FSMs from user requirements, and then generate smart contracts from FSMs. Then, we format user requirements to guide LLMs generate FSMs. After this, the generated FSMs undergo format and graph checks. Once verified, FSMs are input into LLMs to generate the corresponding smart contract code. The resulting contracts are evaluated in terms of effectiveness and security. These validations are utilized as feedback to refine the generation results.

To summarize, we make the following contributions.

• We propose a smart contract generation framework called FSM-SCG upon LLMs. By abstracting user requirements as FSM, FSM-SCG can significantly improve the generation of smart contracts.
• We construct a fine-tuning dataset to improve the ability of LLMs to generate FSMs and smart contracts. Additionally, we conduct compilation and security checks, and use them as feedback to optimize the generation of smart contracts.
• Experimental results show that FSM-SCG 1 significantly enhances the effectiveness and security of smart contracts. Using LlaMa3.1-8B, the compilation success rate reaches 95.1%, 48% higher than the best baseline. Security risks are greatly reduced, with the vulnerability risk score dropping by 68% on average.

1 This paper's code is available at https://github.com/pluto-ms/ FSM-Smart-Contract-Generation.

2 Preliminaries

2.1 Smart Contract Generation Process

There are two approaches to generating smart contracts using LLMs. The first is the direct generation approach, which inputs user requirements directly for the LLM to generate corresponding smart contract code. The second is the intermediate representation approach, where the LLM first transforms user requirements into an abstract model, then generates smart contract code from this model, effectively decomposing the task into two steps. The direct generation approach prioritizes rapid implementation and user interaction, while the intermediate representation approach focuses on modeling and abstraction, making it better suited for complex requirements. Our work adopts the second approach, utilizing FSM as the intermediate representation.

2.2 Finite State Machine

FSM is an abstract computational model used to represents the dynamic behavior of a system by recognizing input sequences and transitioning between states according to predefined rules.

A Mealy state machine is a type of FSM. Its main characteristic is that the output depends not only on the current state but also on the input signal, allowing for an instantaneous and precise response when the input changes. Typically, a Mealy state machine can be defined as a quintuple (S, X, Y, δ, λ):

• S represents the set of states;
• X represents the set of inputs;
• Y represents the set of outputs;
• δ : S × X → S is the state transition function, which defines the transition rules under different inputs;
• λ : S ×X → Y is the output function that determines the system output based on the current state and input.

The Mealy state machine, although it can represent the state transfer of smart contracts well, has limited guidance for the contract generation task.

3 FSMGuided Smart Contract Generation

In this part, we first provide an overview of our solution FSMSCG. Then, we introduce its key designs, including an enhanced FSM to encode more information for smart contracts, the prompts tailored for generating FSM and smart contract, and the refinement of smart contract using feedback from compilation and security checks.

3.1 FSM-SCGOverview

Figure 1 provides an overview of FSM-SCG, including the following key processes. We also provide the detailed algorithm of FSM-SCG in Appendix A of [Luo et al., 2025].

Fine-Tuning Process. To enhance the ability of LLMs in generating smart contracts, we build a fine-tuning dataset Dft that uses FSM as an intermediate representation to generate smart contracts based on user requirements (see Section 3.2). Based on this dataset, we optimize the pretrained LLM Mpre using the supervised full parameter fine-tuning (FPFT) method [Kenton and Toutanova, 2019]. In FPFT, all model parameters are updated during training, enabling the model to learn the task-specific domain. In this manner, the LLM can better understand user requirements, translate them into FSMs, and master the domain-specific syntax and semantics of smart contracts. Together, these adaptations significantly improve the quality of the generated code.

Requirement Processing. This module takes the natural language descriptions of the desired smart contract from the user, where the user requirements are denoted as R. We transform R into the Requirement-FSM Prompt PR→F , which can guide the LLM to generate the FSM F describing the desired smart contract.

FSMGeneration. The Requirement-FSM Prompt PR→F is fed into the fine-tuned LLMMft. The Mft analyzes the functionality requirements and logic within the user requirements, extracts the states and their transition conditions, and generates the corresponding FSM F .

FSMCheck. This module conducts format and graph checks on FSM F. The format check ensures syntactic and content integrity, while the graph check verifies logical correctness of states and transitions. Finally, the FSM-Code Prompt PF→C is generated to produce the smart contract C.

Smart Contract Generation. The checked FSM F and FSM-Code Prompt PF→C are fed into fine-tuned LLMMft to guide the generation of smart contract C. Since F is rigorously checked in terms of format and logic, Mft can efficiently encapsulate its states and events in smart contracts.

Feedback Driven Refinement. Generated smart contracts C are evaluated for effectiveness and security. We use Py-solcx to check for compilation errors Ic and Slither [Feist et al., 2019] to detect vulnerabilities Is. These issues are fed back into the LLM via compilation Pc and security Ps prompts to guide refinement, producing refined smart contracts Cr.

3.2 Fine-tune Dataset Construction

Existing work has not provided open-source datasets [Liu et al., 2024; Zhao et al., 2024; Luo et al., 2024], making it difficult to reproduce their results. Moreover, these works consider a single task or scenario and thus cannot encompass the diverse requirements of practical smart contract generation.

To tackle these two problems, we construct an open-source fine-tuning dataset that covers various tasks and adopts a dialogic format.

We collect smart contract source code from platforms like Etherscan and use GPT-4o to generate the corresponding user requirements and FSM, forming a dataset of 30k items, each containing requirements (R), FSM (F), and code (C). From this, we derive sub-datasets by rearranging elements-R2F2C, R2F, F2C, C2F, and R2C. Additionally, the A2C dataset maps extracted annotations to function code. These datasets support training LLMs for various smart contract generation tasks. We present the dataset details in Appendix B of [Luo et al., 2025].

3.3 Enhanced FSM for Smart Contract

Limitations of Mealy. As in Section 2.2, the Mealy machine abstracts state transitions and outputs but lacks explicit representation of functions, variables, and state-output interactions, limiting its ability to capture smart contract complexity.

SmartFSM. To enhance the capability of FSM to represent smart contracts, we propose SmartFSM, an enhancement to the Mealy state machine that more accurately models the structure and functionality of smart contracts. SmartFSM divides the representation of contracts into five sections, i.e., basic information, states, variables, functions, and events, which we introduce as follows.

• Basic information. This section contains the background and functional descriptions of the contract, providing an overall overview of the contract for LLM.
• States. This section lists all possible states of the contract to help the LLM understand the states and transfer logic.
• Variables. This section records important data in the smart contract, serving as the conditions for state transfer.
• Functions. Each functional module of a smart contract is usually a function that receives external inputs and may trigger state transfers. The function part resembles the input-output mechanism in Mealy state machine.
• Events. This section records the key operations and state changes that occur in the contract. The triggering of each event reflects the operational state of the contract and is similar to the output function in the Mealy state machine.

Dividing smart contract into five sections, SmartFSM retains Mealy machine state transfer capabilities while better representing variables, functions, and underlying details. We provide an example in Appendix C of [Luo et al., 2025].

3.4 Checking of SmartFSM

The SmartFSM generated by LLMs may have errors like incomplete structure or incorrect logic. Therefore, we verify its correctness through three steps: SmartFSM information extraction, format check, and graph check.

SmartFSM Information Extraction. From SmartFSM, we extract the following sets: The state set S = {s1, s2, . . . , sn}, representing all possible states. The trigger set X = {x1, x2, . . . , xm}, representing all triggers causing state transitions. The target state set T = {t1, t2, . . . , tk}, where T ⊆ S, representing all possible target states. The transition set ∆ = {(s, x, t) | s ∈ S, x ∈ X, t ∈ T}, representing all transitions as triples.

Format Check. This step uses static analysis methods to verify the completeness and correctness of the SmartFSM. The correct FSM should satisfy the following conditions: (i) the initial state s0 must be defined within the state set (s0 ∈ S); (ii) the target states in transitions must be defined within the state set (∀(s, x, t) ∈ ∆, t ∈ S); (iii) the triggers must be defined within the event set (∀(s, x, t) ∈ ∆, x ∈ X).

Graph Check. Format check ensures that the SmartFSM follows the formatting rules but it does not ensure the SmartFSM is logically correct. Graph check is used to check logical correctness as the states and state transfers of FSM can be expressed as graphs. We first use the extracted states to construct a directed graph, where the nodes represent the states, the edges represent state transitions, and the states are connected through state transitions. A SmartFSM can be considered correct if it satisfies the following conditions: (i) All states in the SmartFSM can be reached from the initial state via some path p (∀s ∈ S, ∃p : s0 → s); (ii) The state graph should have loops but no self-loops, to ensure that states can transition correctly (t ̸= s).

3.5 Prompts for FSMand Contract Generation

Prompt engineering is crucial for effectively using LLMs. Figure 2 shows the prompts for FSM and contract generation.

Prompt for FSMGeneration. To construct FSM accurately from user requirements, we carefully design the prompt to make the LLM focus on the structure of the FSM and ensure that no unnecessary information is generated. The prompt comprises the following components:

• Task description: Guide the LLM to generate smart contracts based on user requirements.
• Output constraints: Request the LLM to return only the FSM content, without outputting any other information.
• FSM integration: The prompt explicitly provides the JSON format of the FSM. By providing a predefined format, the prompt helps the LLM understand the expected structure and syntax of FSM. This also reduces the possibility of formatting errors and deviations from the intended structure.
• Requirement integration: The prompt includes placeholders for user requirements.

The prompt, by providing a task description, limiting the output, and offering a structured template, enables the LLM to understand the requirements and generate FSMs, while minimizing the possibility of redundant or irrelevant content.

Prompt for Smart Contract Generation. In order to generate a smart contract that meets user requirements, conforms to the specific FSM, and adheres to coding standards, we design the following prompt.

• Task description: As shown in Figure 2, the prompt directs the LLM to generate smart contract based on the previously generated FSM. The LLM can leverage the session context to extract the smart contract content and accurately implement the logic and structure defined in the FSM, without requiring the FSM to be included in the prompt.
• Output constraints: Request the LLM to return the smart contract, without outputting any other information.

The proposed prompt hence maintain logical consistency between the design phase (FSM) and the implementation phase (smart contract). This stratified approach ensures that the behavior represented in the FSM, such as state transitions and triggers, is reflected in the code.

3.6 Contract Refinement with Feedback

Compilation Feedback. As shown in Figure 3, we compile the generated code by Solidity compiler. If errors are detected, we return the errors to the LLM along with a contextual prompt to help improve the quality of generated code. In the prompt, we inform the LLM about the details of the errors and desired improvements for regeneration. The feedback not only provides the specific reasons for failure but also offers explicit correction guidance. As Figure 3 shows, during the compilation process, we identify address errors within the functions and provide the errors in the compilation feedback prompt to guide the LLM in regenerating the contract.

Security Feedback. To ensure code security, we use Slither to detect vulnerabilities such as reentrancy and locked assets. Detected issues, including type and code segment, are recorded in a security feedback prompt. Figure 3 shows a "Locked Ether" vulnerability, where the contract can receive but not transfer funds. Using a predefined prompt template, we integrate details to guide regeneration.

The above feedback procedure is iterated until compilation errors and security vulnerabilities are eliminated.

3.7 Comparison to PriorWorks

Compared to the prior works [Napoli et al., 2024; Chatterjee and Ramamurthy, 2024; Petrovi´c and Al-Azzoni, 2023; Qasse et al., 2023], our approach has the following advantages.

FSM as an Intermediate Representation. Our experiments show that FSM outperforms IContractML[Petrovi´c and AlAzzoni, 2023] and CML[Wöhrer and Zdun, 2020], as it concisely captures requirements and state transitions. In contrast, IContractML is overly complex with redundant details, while CML lacks state transition representation.

Fine-Tuning and Feedback. We use supervised FPFT approach to enhance smart contract generation and introduce a novel feedback mechanism. Effectiveness and security checks provide feedback to improve contract quality.

4 Experimental Evaluation

4.1 Experiment Settings

Base LLMs. We evaluate our method using both closedsource models (GPT-4o, GeMini1.5-Flash, Qwen-plus) and open-source models (LlaMa3.1-405B/8B, Qwen2.5-7B), covering different parameter scales.

Baselines and Our Method. We select three representative methods for smart contract generation as baselines.

• Direct. A series of research on smart contract generation uses LLMs to generate smart contract code based on user requirements directly [Napoli et al., 2024; Chatterjee and Ramamurthy, 2024].
• IContractML. IContractML generates model language via LLMs, then derives contract code. [Petrovi´c and AlAzzoni, 2023; Qasse et al., 2023]. It represents methods that introduce an intermediate representation.
• CML. Contract Modeling Language (CML), a highlevel DSL, has been used in traditional smart contract generation[Wöhrer and Zdun, 2020], but not for guiding LLMs. We adopt CML as an intermediate representation and use it as a baseline for comparison.

We compare the performance of the three variants of the methods proposed in this paper with the baseline.

• FSM. We employ the SmartFSM proposed in Section 3.3 as an intermediate representation to guide LLMs to generate smart contracts. However, it does not incorporate iterative feedback mechanisms or involve fine-tuning the LLM.
• FSM-SCG*. FSM-SCG* extends FSM by incorporating compilation and security feedback to iteratively optimize smart contracts, improving their effectiveness and security without fine-tuning the LLM.
• FSM-SCG. FSM-SCG further enhances FSM-SCG* by fine-tuning the LLM on our fine-tuning dataset.

Environment and Parameters. We fine-tune instruction versions of LlaMa3.1-8B and Qwen2.5-7B models using 8 NVIDIA A6000-48GB GPUs. FPFT runs for 3 epochs using AdamW (lr=5e-5). FSM-SCG includes one compilation and one security feedback round.

4.2 Performance Metrics

CPR. Compilation pass rate (CPR) reflects the effectiveness of the generated smart contracts.

where Ncompiled is the number of successfully compiled smart contracts, and Ntotal is the total number of contracts.

ZRCP and HRCP. Zero risk contract percentage (ZRCP) and high risk contract percentage (HRCP) quantify the security.

where Nzero is the number of contracts with zero risk scores, Nhigh is the number of contracts with high-severity vulnerabilities, and Ntotal is the total number of contracts.

VRS. Vulnerability risk score (VRS) indicates the risk level, and a high VRS may be caused by many vulnerabilities or high severity of those vulnerabilities.

where n is the total number of detected vulnerabilities, SeverityScorei is the severity score of vulnerability i, which can be 3 (high), 2 (medium), or 1 (low); and ConfidenceScorei is the confidence score of vulnerability i, which can be 3 (high), 2 (medium), or 1 (low).

4.3 Main Experiments

Effectiveness. We evaluate methods using the CPR of generated contracts. We sample 1,000 high-quality requirements from dataset for testing. For each requirement, LLM generates three code samples, which are compiled to compute CPR. Figure 4 presents the results.

• Closed-source LLMs. The FSMmethod uses SmartFSMas an intermediate representation to guide LLMs, outperforming Direct, CML, and IContractML in most cases on both closed-source and open-source LLMs. The FSM-SCG* method, adding generation feedback, achieves the best results among all baselines.
• Open-source LLMs. Due to fine-tuning limitations, FSMSCG is applied only to LlaMa3.1-8B and Qwen2.5-7B, achieving significant CPR improvements, surpassing even GPT-4o. For example, the CPR of LlaMa3.1-8B rises from 36.9% to 95.3%, proving its effectiveness in enhancing smart contract compilation success.

Our method outperforms baselines by structuring requirements into SmartFSM, covering all states and events to enhance contract generation.

Security. We evaluate security of each method in contract generation using ZRCP, HRCP, and VRS metrics. We sample 1,000 high-quality requirements from dataset for testing. For each requirement, LLM generates three code samples. Security is assessed through performance testing, as shown in Table 2, with the following observations:

• Closed-source LLMs. Although FSM lacks a feedback mechanism, it enhances contract security, outperforming Direct, CML, and IContractML in ZRCP and ranking second in HRCP and VRS. This shows SmartFSM improves secure contract generation, with FSM-SCG* achieving the best overall results.
• Open-source LLMs. After applying FSM-SCG, the percentage of smart contracts without security vulnerabilities (ZRCP) increases to 53.21% on Qwen2.5-7B and 50.53% on LlaMa3.1-8B, while high-risk vulnerabilities (HRCP) decrease to 5.15% and 6.62%, respectively.

Our method surpasses baselines in security by ensuring valid state transitions, preventing unsafe changes, handling exceptions, and reducing vulnerabilities.

4.4 Ablation Study

We conduct ablation studies (Table 3) to assess the contributions of key components, including the feedback mechanism, A2C fine-tuning, and the overall fine-tuning process.

• Effect of SmartFSM. Replacing SmartFSM with Mealy

FSM leads to performance degradation. As shown in the table, SmartFSM outperforms Mealy FSM w.r.t. all metrics because it better expresses user requirements and guides LLMs in generating smart contracts.

• Effect of Feedback. Removing the feedback significantly reduces CPR and worsens security metrics. For example, the CPR of LlaMa3.1-8B drops from 95.1% to 91.3%, and VRS increases from 2.36 to 3.11. This shows that feedback improves the compilation success rate and contract security by iteratively refining the generated contracts.
• Effect of A2C Fine-Tuning. Removing the A2C dataset from our fine-tuning dataset and fine-tuning the LLM causes a performance drop as the A2C dataset improves LLM's ability to associate code with annotation.
• Effect of Entire Fine-Tuning. Without fine-tuning, all metrics degrade significantly, highlighting its importance to improve CPR and security. Fine-tuning helps the model grasp Solidity complexities, meet functional requirements, and address security vulnerabilities.
• Effect of Fine-Tuning Method. We compare FPFT and LoRA [Hu et al., 2022; Xia et al., 2024] and include the experimental results in Table 4. FPFT outperforms LoRA by updating all parameters for better task adaptation, while LoRA's limited updates hinder adaptability. Thus, we choose FPFT for our experiments. The detailed discussion is in the Appendix D of [Luo et al., 2025].

4.5 Parameter Sensitivity

We also test FSM-SCG's parameter sensitivity. (see Appendix D of [Luo et al., 2025]).

• Effect of Feedback Count. Varying the feedback count from 0 to 5, the largest improvement occurs from 0 to 1, as most errors are simple and need minimal iterations. Hence, feedback count is set to 1 for balance.
• Effect of Fine-Tuning Epochs. We fine-tune FSM-SCG from 1 to 5 epochs. Performance improves notably up to 3 epochs but plateaus thereafter, as the model converges early and saturates with further training. To balance efficiency and performance, we select 3 epochs.

5 RelatedWork

Automatic Generation Methods for Smart Contracts. Smart contract generation methods include Model-Driven generation (MD)[López-Pintado et al., 2017; Tran et al., 2018] , Domain-Specific Languages (DSL)[Clack et al., 2019; Skotnica and Pergl, 2019] , and Visual Programming Languages (VPL)[Mavridou and Laszka, 2018; Mao et al., 2019]. MD enhances design-code consistency by converting domain models into smart contracts but requires specialized knowledge. DSL simplifies contract development within specific domains but lacks broader applicability and robust verification. VPL uses graphical interfaces to lower development barriers but offers limited functionality and scalability.

Generation of Smart Contracts Using LLMs. The development of LLMs has made automatic smart contract generation a research focus[Yang et al., 2024]. Chatterjee et al.[Chatterjee and Ramamurthy, 2024] explored using descriptive and structured prompts to generate smart contracts, finding quality issues and neglect of security by most LLMs. Petrovi´c and Al-Azzoni[Petrovi´c and Al-Azzoni, 2023] proposed a model-driven framework using ChatGPT, but it suffers from long response times and high costs. Chen et al.[Yong et al., 2024] improved contract quality by combining AST-LSTM representation, clustering models, prompt dataset optimization, and fine-tuning LLaMA2-7B. Qasse et al.[Qasse et al., 2023] extended DSLs with chatbots, improving functionality but facing challenges with input errors and accuracy. However, LLMs still face issues like incorrect syntax, security vulnerabilities, and limited adaptability in this domain [Huang et al., 2024b; Huang et al., 2024a].

Anatomy of Prior Works. Most prior works, except [Chatterjee and Ramamurthy, 2024], rely on a single LLM for smart contract generation, and none has fine-tuned LLMs for this task. Analyzing a single LLM is insufficient, therefore, our work employs six LLMs within the FSM-SCG framework. We assess contract generation through compilation checks, security analysis, and use case testing. A feedback mechanism further enhances trustworthiness by guiding LLMs to refine output, distinguishing our approach and improving performance [Zhang et al., 2024; Wang et al., 2024].

6 Conclusion

In this work, we propose an FSM-guided framework for smart contract generation with LLMs, improving effectiveness and security. We release a fine-tuning dataset to better align LLMs with user needs and integrate compilation and security checks into a feedback mechanism for improved reliability.

Acknowledgments

This work was sponsored by National Key R&D Program of China (No.2023YFB2703600), Key R&D Program of Hubei Province (2023BAB077), the Fundamental Research Funds for the Central Universities (2042025kf0040), and National Natural Science Foundation of China (62472327, 62441229). This work was supported by Sichuan Clinical Research Center for Imaging Medicine (YXYX2402).

Contribution Statement

Hao Luo and Yuhao Lin contributed equally to this work.