Pith. sign in

REVIEW 3 major objections 6 minor 2 cited by

Guiding LLM-based Smart Contract Generation with Finite State Machine

T0 review · 3 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Interposing a finite state machine between requirements and code, then repairing the code with compiler and security feedback, yields smart contracts that compile far more often and carry far fewer vulnerabilities.

desk verdict Promising engineering idea for FSM-guided smart contract generation, but the evaluation leaks the training distribution into the test set, so the headline gains are not credible as stated. read the letter →

arxiv 2505.08542 v1 pith:K2CP5GMS submitted 2025-05-13 cs.AI

Hao Luo , Yuhao Lin , Xiao Yan , Xintong Hu , Yuxiang Wang , Qiming Zeng , Hao Wang , Jiawei Jiang This is my paper · ORCID
classification cs.AI
keywords finitestatemachinesmartcontractgenerationlargelanguagemodelsSoliditycompilationpassratevulnerabilityriskscorefine-tuningfeedbackprompting
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Large language models generate Solidity code that often fails to compile and frequently carries exploitable vulnerabilities. The paper's bet is that the bottleneck is a missing intermediate structure: the model is asked to jump from a natural-language requirement straight to code. The proposed FSM-SCG pipeline instead has a fine-tuned LLM first translate each requirement into SmartFSM, an augmented finite state machine recording states, variables, functions, and events, then generate the contract from that machine, and finally repair the code using compiler errors and static vulnerability reports as feedback. On 1,000 sampled requirements with Llama-3.1-8B, the pipeline raises the compilation pass rate from 36.9% (direct generation) to 95.1% and lowers the average vulnerability risk score from 7.44 to 2.36. The paper's claim is that this decomposition plus repair loop is what makes the difference, and the topic matters because smart contracts cannot be patched after deployment.

What carries the argument

The load-bearing object is SmartFSM, a five-section extension of a Mealy state machine—basic information, states, variables, functions, and events—that keeps the transition function $\delta: S \times X \to S$ while adding the information a contract needs. It works by giving the LLM a fixed JSON scaffold that it can be fine-tuned to fill and that can be machine-checked before any code is written. Around that object, the framework wraps two repair loops: compilation feedback from the Solidity compiler and security feedback from Slither, both prompting the model to regenerate until checks pass. The format and graph checks (initial state defined, targets defined, all states reachable from the initial state, no self-loops) are what make the intermediate representation trustworthy enough to guide generation.

What would settle it

Run FSM-SCG on 1,000 Solidity requirements written by humans rather than generated by an LLM from existing contract code; if the compilation pass rate falls back toward the 37–50% baseline range, the reported gains come from test/training distribution overlap, not from the method itself.

Watch

Extended reading notes

Core claim

The paper's central claim is that the bottleneck in LLM-based smart contract generation is not the language model itself but the absence of a checkable intermediate structure. FSM-SCG therefore inserts a SmartFSM—an augmented finite state machine carrying five sections (basic information, states, variables, functions, events)—between the user's natural-language requirements and the Solidity code. A fine-tuned model first produces the machine, checks it for format and reachability, then writes the contract from it; compiler errors and static vulnerability findings are fed back into the model to patch the code. On the paper's own experiments this raises the compilation pass rate for Llama-3.1-8B from 36.9% to 95.1% and cuts the average vulnerability risk score from 7.44 to 2.36, with qualitatively similar gains on five other models.

Load-bearing premise

The load-bearing premise is that the 1,000 test requirements, sampled from the same dataset used to build the fine-tuning set, are independent of that set and representative of real user requests.

Editorial extensions

If this is right

  • On Llama-3.1-8B, the full FSM-SCG pipeline reaches a 95.1% compilation pass rate and a 2.36 vulnerability risk score, beating direct generation (36.9% / 7.44) and both intermediate-DSL baselines.
  • The benefit transfers across model families: fine-tuned Qwen2.5-7B reaches 93.6% CPR and VRS 2.48, and even the no-fine-tuning variant FSM-SCG* beats all baselines on the six tested models.
  • Every ablated component matters: removing feedback drops Llama-3.1-8B CPR from 95.1% to 91.3% and raises VRS from 2.36 to 3.11; removing the whole fine-tuning step drops CPR to 71.3%.
  • SmartFSM itself, without fine-tuning or feedback, already beats plain Mealy FSM and the CML/IContractML baselines, so the five-section representation is a genuine improvement over a bare state machine.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A consequence the authors leave implicit: because the test requirements are drawn from the same synthetic distribution used for fine-tuning, the reported CPR/VRS gains are likely an upper bound on what the pipeline would deliver on genuinely novel user requirements; an independent human-written test set is needed.
  • The graph check accepts any reachable graph with no self-loops, which is too weak to catch many logical errors; pairing SmartFSM with invariant checking or a model checker could reduce vulnerabilities further than the one-round Slither feedback loop.
  • The same requirement-to-FSM-to-code decomposition could transfer to other low-resource contract languages such as Vyper or Move, where syntax errors are the dominant failure mode; the paper only demonstrates Solidity.
  • A policy of one compilation feedback round plus one security feedback round is a bounded repair loop; on out-of-distribution requirements, repair may require many rounds or may never terminate, so a budget-aware stopping rule would make the framework more robust.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper proposes FSM-SCG, a pipeline that transforms natural-language user requirements into an enhanced finite-state-machine representation (SmartFSM), uses a fine-tuned LLM to generate smart contracts from the FSM, and then iteratively refines the code using compilation and Slither-based security feedback. The main claims are that FSM-guided generation plus fine-tuning and feedback substantially improves compilation success rate (CPR) and reduces vulnerability risk score (VRS) relative to direct generation and to intermediate-representation baselines, with headline numbers of 95.1% CPR and a 68% VRS reduction reported on LLaMa3.1-8B. The authors also describe the construction of a 30k-item fine-tuning dataset generated by GPT-4o from Etherscan contract code, and they report ablations on SmartFSM, feedback, fine-tuning, and the A2C sub-dataset.

Significance. If the evaluation were sound, the paper would make a useful contribution: SmartFSM is a reasonable way to inject structure into LLM-based contract generation, the ablation study isolates the contribution of individual components, and an open fine-tuning dataset would help reproducibility. However, the current test protocol does not support the headline quantitative claims. The test requirements are drawn from the same synthetic dataset used for fine-tuning, so the CPR and VRS numbers may reflect train/test distribution overlap rather than a generalizable improvement; in addition, the VRS metric assigns 10 to non-compiling contracts, entangling security with compilation success. The core idea is promising and the flaws are addressable, but the evidence as presented is not sufficient for acceptance.

major comments (3)
  1. [§3.2, §4.3] The test set is sampled from the same dataset used for fine-tuning, creating a direct train/test overlap. Section 4.3 states "We sample 1,000 high-quality requirements from dataset for testing," and Section 3.2 defines that dataset as the fine-tuning set built by having GPT-4o generate requirements and FSMs from existing contract code. No separate held-out set or contract-level split is described anywhere in the paper. Because the fine-tuned model has been trained on requirements of the same synthetic style and possibly derived from the same contracts, the reported CPR and VRS improvements in Figure 4 and Table 2 may reflect distribution overlap rather than a generalizable advantage. This is load-bearing for every headline number; the authors must evaluate on an independent test set of human-written or otherwise held-out requirements and must describe how the 1,000 test requirements were selected and verified to be disjoint from the fine-tuning data.
  2. [§4.2, VRS definition] The VRS metric assigns a score of 10 to every non-compiling contract. Since FSM-SCG achieves much higher CPR than the baselines (Table 1 and Figure 4), part of the reported 68% VRS reduction may be a mechanical consequence of more contracts compiling, not of improved security. The paper should report VRS computed only over compiled contracts, or make ZRCP and HRCP the primary security metrics, so that the security effect is separated from the compilation effect.
  3. [§3.2, §4.3] The fine-tuning dataset construction also limits external validity. Because the "user requirements" are reverse-engineered by GPT-4o from existing contract code, the model is trained and tested on a distribution that may not match real user requirements, which are often incomplete, ambiguous, or expressed differently. A random split of this dataset would not fully solve the problem. The authors should test on independently collected human-written requirements, or at minimum provide a contract-level split and a qualitative comparison showing that the synthetic requirements resemble real-world usage.
minor comments (6)
  1. [§4.3] The text says the CPR of LLaMa3.1-8B rises from 36.9% to 95.3%, but Table 1 and Figure 4 report 95.1%; please correct the inconsistency.
  2. [§4.1, Figure 4] Figure 4 appears to include FSM-SCG on GPT-4o, but Section 4.3 states that FSM-SCG is applied only to LLaMa3.1-8B and Qwen2.5-7B; clarify which bars correspond to FSM-SCG in the figure.
  3. [Appendix A, Algorithm 1] The FSM regeneration loop in lines 4-6 calls M_f t(R) rather than M_f t(P_{R→F}), and neither loop has an iteration cap; align the pseudocode with the experimental setting of one feedback round described in Section 4.1.
  4. [§3.4] The graph check requires that all transitions satisfy t ≠ s, but a self-loop can model a legitimate event that does not change the contract state; please justify or remove this condition.
  5. [§3.2] The paper claims to release an open-source fine-tuning dataset but gives no URL or repository; include a link or release mechanism for reproducibility.
  6. [Throughout] Minor typos and naming inconsistencies should be fixed, including "LlaMa3.1" (should be "LLaMA3.1") and "GeMini1.5" (should be "Gemini1.5").

Circularity Check

2 steps flagged · score 6.0 of 10

The main evaluation is self-referential: the 1,000 test requirements are sampled from the same GPT-4o-generated fine-tuning dataset used to train FSM-SCG, so the headline CPR/VRS gains largely reflect train-set fit; VRS is additionally defined to assign the worst score to non-compiling code, making part of the security improvement an artifact of the compilation metric.

  1. fitted input called prediction [Section 4.3 (Main Experiments), Figure 4 caption, vs. Section 3.2 and Appendix B (Fine-tune Dataset Construction)]
    "We sample 1,000 high-quality requirements from dataset for testing. ... All methods generate contracts from the same 1,000 user requirements. ... 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)."

    Section 3.2 builds the fine-tuning dataset D_f t from 30k GPT-4o-generated (R, F, C) triples, and Sections 3.1 and 4.1 fine-tune the LLM on this dataset. Section 4.3 then evaluates on 1,000 requirements sampled 'from dataset' - the same pool - with no held-out split or external test set described. The test requirements therefore come from the distribution on which the model was trained, and may be near-duplicates of training requirements derived from the same contracts. The headline CPR (95.1%) and VRS (~68% reduction) numbers are thus measurements of fit to the training data, not predictions on independent user requirements.

  2. self definitional [Section 4.2, Performance Metrics (VRS definition); Table 1]
    "VRS = Pn i=1(SeverityScorei×ConfidenceScorei) / n ... VRS is set to 10 when the code does not compile successfully."

    By this definition, every non-compiling contract is assigned the maximum vulnerability score 10. Since CPR is defined as N_compiled / N_total, VRS is a direct decreasing function of CPR by construction: a method that compiles more often automatically has a lower VRS, regardless of any static-analysis findings. FSM-SCG raises CPR from 36.9% to 95.1% on LLaMa3.1-8B, so much of the reported '68% vulnerability risk reduction' is forced by the compilation-success improvement rather than by an independent security property, making the security claim partially restate the effectiveness claim.

full rationale

The paper's core derivation - using SmartFSM as an intermediate representation, checking it, generating code, and refining with compilation/security feedback - is not itself circular: SmartFSM is a defined representation, and the generation pipeline adds components (format/graph checks, feedback) that are not presupposed by the evaluation. The circularity is in the evaluation design. Section 3.2 constructs a 30k-item dataset by having GPT-4o generate requirements and FSMs from Etherscan contracts, and Section 3.1 fine-tunes the model on that same dataset. Section 4.3 samples the test requirements 'from dataset', so the fine-tuned FSM-SCG is scored on the same synthetic requirement distribution (and potentially the same source contracts) it was trained on. No train/test split, filtering against training items, or external human-written requirement set is described, so the headline CPR/VRS improvements cannot be read as generalizable predictions. The VRS metric adds a further self-definitional tie: assigning VRS=10 to all non-compiling contracts makes the security number partly a monotone transform of the compilation number. These are load-bearing because every headline claim (up to 48% CPR improvement, ~68% VRS reduction) is computed on this setup. The result is partial circularity, not a complete one: the FSM representation and feedback loop may still offer real gains, but the paper's central quantitative evidence does not establish them independently of its training distribution.

Assumptions & free parameters 4 free parameters · 5 assumptions · 1 invented entities

The framework relies on several unverified assumptions: that GPT-4o-generated requirements and FSMs represent real user needs, that the test set is independent of training, that Slither and compilation checks are adequate oracles for security and effectiveness, and that the SmartFSM graph-check conditions ensure logical correctness. These assumptions are load-bearing for the reported results and are not independently validated.

free parameters (4)
  • Fine-tuning epochs = 3
    Selected based on the plateau observed in Figure 7; all reported CPR and VRS numbers depend on this choice.
  • Feedback rounds = 1 compilation + 1 security round
    Chosen after sensitivity analysis showing the largest improvement from 0 to 1 rounds; the headline results use this configuration.
  • Fine-tuning dataset size = ~30k items
    Hand-selected scale with no principled justification; performance may vary with dataset size.
  • Learning rate = 5e-5
    Standard FPFT setting, reported without a sensitivity study.
assumptions (5)
  • domain assumption The graph check conditions (all states reachable from the initial state, no self-loops) are sufficient to establish logical correctness of the SmartFSM.
    Section 3.4. These are syntactic reachability conditions, not full semantic verification of the contract behavior.
  • domain assumption Slither static analysis is an accurate ground truth for smart contract security vulnerabilities.
    Sections 3.6 and 4.2. The security metrics (ZRCP, HRCP, VRS) depend entirely on Slither detections.
  • domain assumption Compilation success with py-solc-x is a valid proxy for smart contract effectiveness.
    Section 4.2. CPR is the effectiveness metric; semantic correctness of the generated logic is not evaluated.
  • ad hoc to paper User requirements and FSMs generated by GPT-4o from existing contract code faithfully represent real user requirements.
    Section 3.2. The entire training and test data is built this way, so the evaluation is confined to this synthetic distribution.
  • ad hoc to paper The test set of 1,000 requirements is independent of the fine-tuning set.
    Section 4.3 says the test requirements are sampled 'from dataset', which appears to be the same dataset described in Section 3.2. No separate held-out set is described.
invented entities (1)
  • SmartFSM
    purpose: Intermediate representation that structures a smart contract into five sections (basic information, states, variables, functions, events) to guide LLM code generation.
    Introduced in Section 3.3. It is a designed format with no external validation showing it captures contract semantics better than alternatives such as CML or IContractML.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Guiding LLM-based Smart Contract Generation with Finite State Machine." pith.science (2026). https://pith.science/paper/K2CP5GMS

@misc{pith2026250508542,
  author       = {Pith},
  title        = {Pith review of: Guiding LLM-based Smart Contract Generation with Finite State Machine},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/K2CP5GMS}},
  note         = {Machine review of arXiv:2505.08542}
}
read the original abstract

Smart contract is a kind of self-executing code based on blockchain technology with a wide range of application scenarios, but the traditional generation method relies on manual coding and expert auditing, which has a high threshold and low efficiency. Although Large Language Models (LLMs) show great potential in programming tasks, they still face challenges in smart contract generation w.r.t. effectiveness and security. To solve these problems, we propose FSM-SCG, a smart contract generation framework based on finite state machine (FSM) and LLMs, which significantly improves the quality of the generated code by abstracting user requirements to generate FSM, guiding LLMs to generate smart contracts, and iteratively optimizing the code with the feedback of compilation and security checks. The experimental results show that FSM-SCG significantly improves the quality of smart contract generation. Compared to the best baseline, FSM-SCG improves the compilation success rate of generated smart contract code by at most 48%, and reduces the average vulnerability risk score by approximately 68%.

Figures

Figures reproduced from arXiv: 2505.08542 by the authors.

Figure 1
Figure 1. An overview of our FSM-SCG framework. 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 se￾mantics of smart contracts. Together, these adaptations sig￾nificantly improve the quality of the generated code. Requirement processing. This mo… view at source ↗
Figure 2
Figure 2. The prompts for FSM and contract generation. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Examples for compilation and security feedback. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Compilation Pass Rate (CPR) of smart contracts generated [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Procedure for generating the fine-tuning dataset. [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]
Figure 6
Figure 6. Figure 6: Three key elements involved in the smart contract generation process: Requirement, FSM, and Smart Contract. [PITH_FULL_IMAGE:figures/full_fig_p011_6.png]
Figure 7
Figure 7. Figure 7: Comparison of model performance with respect to feed [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. On LLM-Assisted Generation of Smart Contracts from Business Processes

    cs.SE 2025-07 conditional novelty 6.0 of 10

    An open benchmark shows top LLMs generate functionally correct smart contracts from BPMN process models in about 80 to 92 percent of checks, below the reliability needed for blockchain deployment.

  2. SoK: Security and Privacy of AI Agents for Blockchain

    cs.CR 2025-09 conditional novelty 5.0 of 10

    A systematization of knowledge that proposes a taxonomy and reference architecture for blockchain AI agents, and catalogs security and privacy threats.

Reference graph

Works this paper leans on

35 extracted references · 29 canonical work pages · cited by 2 Pith papers

  1. [1]

    Ver- ification of smart contracts: A survey

    [Almakhour et al., 2020] Mouhamad Almakhour, Layth Sli- man, Abed Ellatif Samhat, and Abdelhamid Mellouk. Ver- ification of smart contracts: A survey. Pervasive and Mo- bile Computing, 67:101227,

    work page 2020

  2. [5]

    Lora: Low-rank adaptation of large language models

    [Hu et al., 2022] Edward J Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, Weizhu Chen, et al. Lora: Low-rank adaptation of large language models. ICLR, 1(2):3,

    work page 2022

  3. [6]

    Retrofitting temporal graph neural networks with transformer

    [Huang et al., 2024b] Qiang Huang, Xiao Yan, Xin Wang, Susie Xi Rao, Zhichao Han, Fangcheng Fu, Wen- tao Zhang, and Jiawei Jiang. Retrofitting temporal graph neural networks with transformer. arXiv preprint arXiv:2409.05477,

    arXiv

  4. [7]

    A survey on large language models for code generation

    [Jiang et al., 2024b] Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. A survey on large language models for code generation. arXiv preprint arXiv:2406.00515,

    arXiv

  5. [8]

    Bert: Pre-training of deep bidirectional transformers for lan- guage understanding

    [Kenton and Toutanova, 2019] Jacob Devlin Ming- Wei Chang Kenton and Lee Kristina Toutanova. Bert: Pre-training of deep bidirectional transformers for lan- guage understanding. In Proceedings of NAACL-HLT , volume 1, page 2,

    work page 2019

  6. [9]

    Blockchain smart contracts: Applications, challenges, and future trends

    [Khan et al., 2021] Shafaq Naheed Khan, Faiza Loukil, Chirine Ghedira-Guegan, Elhadj Benkhelifa, and Anoud Bani-Hani. Blockchain smart contracts: Applications, challenges, and future trends. Peer-to-peer Networking and Applications, 14:2901–2925,

    work page 2021

  7. [11]

    When moe meets llms: Parameter efficient fine-tuning for multi-task medical applications

    [Liu et al., 2024] Qidong Liu, Xian Wu, Xiangyu Zhao, Yuanshao Zhu, Derong Xu, Feng Tian, and Yefeng Zheng. When moe meets llms: Parameter efficient fine-tuning for multi-task medical applications. In Proceedings of the 47th International ACM SIGIR Conference on Research and Development in Information Retrieval , pages 1104– 1114,

    work page 2024

  8. [12]

    Structured chain-of-thought prompting for code genera- tion

    [Li♂ et al., 2023] Jia Li♂, Ge Li, Yongmin Li, and Zhi Jin. Structured chain-of-thought prompting for code genera- tion. ACM Transactions on Software Engineering and Methodology,

    work page 2023

Show all 35 references
  1. [15]

    Making smart con- tracts smarter

    [Luu et al., 2016] Loi Luu, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. Making smart con- tracts smarter. In Proceedings of the 2016 ACM SIGSAC conference on Computer and Communications Security , pages 254–269,

    2016

  2. [17]

    Tool demonstration: Fsolidm for designing secure ethereum smart contracts

    [Mavridou and Laszka, 2018] Anastasia Mavridou and Aron Laszka. Tool demonstration: Fsolidm for designing secure ethereum smart contracts. In Principles of Security and Trust: 7th International Conference, POST 2018, Held as Part of the European Joint Conferences on Theory and...

    2018

  3. [19]

    Model-driven smart contract generation lever- aging chatgpt

    [Petrovi´c and Al-Azzoni, 2023] Nenad Petrovi ´c and Issam Al-Azzoni. Model-driven smart contract generation lever- aging chatgpt. In International Conference On Systems Engineering, pages 387–396,

    2023

  4. [20]

    Synchromesh: Reliable code gener- ation from pre-trained language models

    [Poesia et al., 2022] Gabriel Poesia, Oleksandr Polozov, Vu Le, Ashish Tiwari, Gustavo Soares, Christopher Meek, and Sumit Gulwani. Synchromesh: Reliable code gener- ation from pre-trained language models. arXiv preprint arXiv:2201.11227,

    2022 arXiv

  5. [22]

    Smart contract: Attacks and protections

    [Sayeed et al., 2020] Sarwar Sayeed, Hector Marco-Gisbert, and Tom Caira. Smart contract: Attacks and protections. IEEE Access, 8:24416–24427,

    2020

  6. [23]

    Das contract-a visual domain specific language for modeling blockchain smart contracts

    [Skotnica and Pergl, 2019] Marek Skotnica and Robert Pergl. Das contract-a visual domain specific language for modeling blockchain smart contracts. In Enterprise Engineering Working Conference, pages 149–166,

    2019

  7. [24]

    Smart contract design meets state machine synthesis: Case studies

    [Suvorov and Ulyantsev, 2019] Dmitrii Suvorov and Vladimir Ulyantsev. Smart contract design meets state machine synthesis: Case studies. arXiv preprint arXiv:1906.02906,

    2019 arXiv

  8. [25]

    Lorikeet: A model-driven engineering tool for blockchain-based business process execution and as- set management

    [Tran et al., 2018] An Binh Tran, Qinghua Lu, and Ingo Weber. Lorikeet: A model-driven engineering tool for blockchain-based business process execution and as- set management. In BPM (dissertation/demos/industry), pages 56–60,

    2018

  9. [26]

    An overview of smart contract: architecture, applications, and future trends

    [Wang et al., 2018] Shuai Wang, Yong Yuan, Xiao Wang, Juanjuan Li, Rui Qin, and Fei-Yue Wang. An overview of smart contract: architecture, applications, and future trends. In 2018 IEEE Intelligent Vehicles Symposium (IV), pages 108–113,

    2018

  10. [27]

    Self-supervised learning for graph dataset condensation

    [Wang et al., 2024] Yuxiang Wang, Xiao Yan, Shiyu Jin, Hao Huang, Quanqing Xu, Qingchen Zhang, Bo Du, and Jiawei Jiang. Self-supervised learning for graph dataset condensation. In Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining , pages 3289–3298,

    2024

  11. [28]

    Chain-of-thought prompting elicits reasoning in large language models

    [Wei et al., 2022] Jason Wei, Xuezhi Wang, Dale Schuur- mans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. Chain-of-thought prompting elicits reasoning in large language models. Advances in Neural Information Processing Systems, 35:24824–24837,

    2022

  12. [29]

    Domain specific language for smart contract devel- opment

    [Wöhrer and Zdun, 2020] Maximilian Wöhrer and Uwe Zdun. Domain specific language for smart contract devel- opment. In IEEE International Conference on Blockchain and Cryptocurrency (ICBC), pages 1–9,

    2020

  13. [30]

    Efficient multi-task llm quanti- zation and serving for multiple lora adapters

    [Xia et al., 2024] Yifei Xia, Fangcheng Fu, Wentao Zhang, Jiawei Jiang, and Bin Cui. Efficient multi-task llm quanti- zation and serving for multiple lora adapters. Advances in Neural Information Processing Systems, 37:63686–63714,

    2024

  14. [31]

    Harnessing the power of llms in practice: A survey on chatgpt and be- yond

    [Yang et al., 2024] Jingfeng Yang, Hongye Jin, Ruixiang Tang, Xiaotian Han, Qizhang Feng, Haoming Jiang, Shaochen Zhong, Bing Yin, and Xia Hu. Harnessing the power of llms in practice: A survey on chatgpt and be- yond. ACM Transactions on Knowledge Discovery from Data, 18(6):1–32,

    2024

  15. [32]

    Smart contract gen- eration model based on code annotation and ast-lstm tun- ing,

    [Yong et al., 2024] Chen Yong, Hu Defeng, Xu Chao, Chen Nannan, Fanfan Shen, and Jianbo Liu. Smart contract gen- eration model based on code annotation and ast-lstm tun- ing,

    2024

  16. [33]

    Treecss: An efficient framework for verti- cal federated learning

    [Zhang et al., 2024] Qinbo Zhang, Xiao Yan, Yukai Ding, Quanqing Xu, Chuang Hu, Xiaokai Zhou, and Jiawei Jiang. Treecss: An efficient framework for verti- cal federated learning. In International Conference on Database Systems for Advanced Applications, pages 425–

    2024

  17. [34]

    Recommender systems in the era of large language models (llms)

    [Zhao et al., 2024] Zihuai Zhao, Wenqi Fan, Jiatong Li, Yun- qing Liu, Xiaowei Mei, Yiqi Wang, Zhen Wen, Fei Wang, Xiangyu Zhao, Jiliang Tang, et al. Recommender systems in the era of large language models (llms). IEEE Transac- tions on Knowledge and Data Engineering,

    2024

  18. [35]

    1 for other notations

    Technical Appendix A FSM-SCG Algorithm 1 FSM-SCG Algorithm Workflow Input: User requirementsR Output: Refined smart contractCr Refer to Fig. 1 for other notations. 1: Mf t← FPFT(Mpre,D f t) 2: PR→F← R2FPrompt(R) 3: F←Mf t(PR→F ) 4: while not (FormatCK(F ) and GraphCK(F )) do 5...

    2024

  19. [2016]

    Visual and user-defined smart contract de- signing system based on automatic coding

    [Mao et al., 2019] Dianhui Mao, Fan Wang, Yalei Wang, and Zhihao Hao. Visual and user-defined smart contract de- signing system based on automatic coding. IEEE Access, 7:73131–73143,

    2019

  20. [2017]

    Taiyi: a bilingual fine-tuned large language model for diverse biomedical tasks

    [Luo et al., 2024] Ling Luo, Jinzhong Ning, Yingwen Zhao, Zhijun Wang, Zeyuan Ding, Peng Chen, Weiru Fu, Qinyu Han, Guangtao Xu, Yunzhi Qiu, et al. Taiyi: a bilingual fine-tuned large language model for diverse biomedical tasks. Journal of the American Medical Informatics As- ...

    2024

  21. [2018]

    Lever- aging large language models for automatic smart contract generation

    [Napoli et al., 2024] Emanuele Antonio Napoli, Fadi Bar- bàra, Valentina Gatteschi, and Claudio Schifanella. Lever- aging large language models for automatic smart contract generation. In IEEE 48th Annual Computers, Software, and Applications Conference (COMPSAC) , pages 701– 710,

    2024

  22. [2019]

    Slither: a static analysis framework for smart contracts

    [Feist et al., 2019] Josselin Feist, Gustavo Grieco, and Alex Groce. Slither: a static analysis framework for smart contracts. In IEEE/ACM 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB), pages 8–15,

    2019

  23. [2020]

    Efficacy of various large language models in generating smart contracts

    [Chatterjee and Ramamurthy, 2024] Siddhartha Chatterjee and Bina Ramamurthy. Efficacy of various large language models in generating smart contracts. arXiv preprint arXiv:2407.11019,

    2024 arXiv

  24. [2021]

    Quantifying multilingual performance of large language models across languages

    [Li et al., 2024] Zihao Li, Yucheng Shi, Zirui Liu, Fan Yang, Ali Payani, Ninghao Liu, and Mengnan Du. Quantifying multilingual performance of large language models across languages. arXiv preprint arXiv:2404.11553,

    2024 arXiv

  25. [2022]

    Chat2code: A chatbot for model specification and code generation, the case of smart contracts

    [Qasse et al., 2023] Ilham Qasse, Shailesh Mishra, Björn þór Jónsson, Foutse Khomh, and Mohammad Hamdaqa. Chat2code: A chatbot for model specification and code generation, the case of smart contracts. In IEEE In- ternational Conference on Software Services Engineering (SSE), p...

    2023

  26. [2023]

    Caterpillar: A blockchain-based business process manage- ment system

    [López-Pintado et al., 2017] Orlenys López-Pintado, Lu- ciano García-Bañuelos, Marlon Dumas, and Ingo Weber. Caterpillar: A blockchain-based business process manage- ment system. BPM (Demos), 172:1–5,

    2017

  27. [2024]

    Smart contract templates: foundations, design landscape and research directions (2016)

    [Clack et al., 2019] Christopher D Clack, Vikram A Bakshi, and Lee Braine. Smart contract templates: foundations, design landscape and research directions (2016). Preprint. arXiv, 1608,

    2016

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.