Building Executable Secure Design Models for Smart Contracts with Formal Methods

Smart contracts are appealing because they are self-executing business agreements between parties with the predefined and immutable obligations and rights. However, as with all software, smart contracts may contain vulnerabilities because of design flaws, which may be exploited by one of the parties to defraud the others. In this paper, we demonstrate a systematic approach to building secure design models for smart contracts using formal methods. To build the secure models, we first model the behaviors of participating parties as state machines, and then, we model the predefined obligations and rights of contracts, which specify the interactions among state machines for achieving the business goal. After that, we illustrate executable secure model design patterns in TLA+ (Temporal Logic of Actions) to against well-known smart contract vulnerabilities in terms of state machines and obligations and rights at the design level. These vulnerabilities are found in Ethereum contracts, including Call to the unknown, Gasless send, Reentrancy, Lost in the transfer, and Unpredictable state. The resultant TLA+ specifications are called secure models. We illustrate our approach to detect the vulnerabilities using a real-estate contract example at the design level.

💡 Research Summary

The paper addresses the critical need for security verification at the design stage of smart contracts, where flaws can become immutable and costly once deployed. It proposes a systematic, formal‑methods‑driven framework that models the behavior of all participating parties as independent state machines and captures contractual rights and obligations as interactions among these machines. By translating these models into TLA+ (Temporal Logic of Actions) specifications, the authors create executable security models that can be automatically checked with the TLC model checker for invariant violations and safety properties.

The framework proceeds through four main steps: (1) eliciting business requirements and formalizing them into a contract use‑case template (including offer, parties, consideration, terms, acceptance, rights, and obligations); (2) modeling each party’s behavior as a finite‑state machine with states such as Waiting, Joined, Signed, and Aborted, and transitions triggered by external events (e.g., proposal, payment) and internal constraints (e.g., minimum balance); (3) defining rights and obligations as a three‑phase interaction—obligation request, obligation performance, and right request—thereby making the normative aspects of the contract explicit; and (4) applying a set of secure design patterns that correspond to five well‑known Ethereum vulnerabilities: Call to the Unknown (CTU), Gasless Send (GS), Reentrancy (RE), Lost in Transfer (LIT), and Unpredictable State. Each vulnerability is reinterpreted in terms of state‑machine behavior (e.g., RE as a re‑entry transition) and mitigated by adding TLA+ constraints such as “once‑only” execution, gas‑availability checks, or address‑validity predicates.

To demonstrate the approach, the authors construct a complete TLA+ model of a real‑estate property‑selling contract involving a seller, a buyer, and a property manager. The model captures the entire lifecycle: parties join the negotiation, the manager prepares the contract, both parties sign, ownership is transferred, and the transaction is recorded. The TLA+ specification includes the secure design patterns for each of the five vulnerabilities. Running the TLC model checker reveals that any attempt to violate the defined invariants (e.g., a re‑entrant call during obligation execution) is flagged, proving that the design is resistant to those attacks before any Solidity code is written.

Key contributions of the work are: (i) a clear separation of concerns by modeling capabilities (what each party can do) and constraints (how the contract limits those capabilities) in two layers of state machines; (ii) a catalog of executable TLA+ security patterns that directly correspond to known smart‑contract bugs; and (iii) an end‑to‑end verification pipeline that can automatically detect design‑level flaws, thereby reducing the cost and risk associated with post‑deployment patches.

The authors acknowledge limitations: authoring TLA+ specifications and detailed state‑machine models requires expertise in formal methods, and maintaining traceability between the high‑level model and the eventual Solidity implementation can be non‑trivial. Moreover, state‑space explosion may limit scalability for contracts with many parties or complex branching logic.

In conclusion, the paper demonstrates that formal, executable models built with TLA+ can effectively capture both business semantics and security requirements of smart contracts, enabling early detection of critical vulnerabilities. Future work is suggested to develop tooling that automates the translation from contract documents to state‑machine/TLA+ specifications, to integrate model‑code synchronization mechanisms, and to extend the approach to more intricate multi‑party agreements.