Programming Language Design for Safer Smart Contract Execution

Abstract

Most smart contract vulnerabilities are not caused by careless programmers -- they are caused by programming languages that make dangerous patterns easy to write and safe patterns hard to enforce. Solidity's default behaviour on external calls is to continue execution after the call returns, which is precisely the pattern that enables reentrancy. Its integer arithmetic silently overflowed for years before version 0.8 added checked math by default. Its storage layout is implicit and collision-prone in proxy patterns. These are not bugs in Solidity -- they are design choices, and different choices would prevent entire classes of vulnerability. I evaluate seven smart contract programming languages -- Solidity, Vyper, Rust (Solana/CosmWasm), Move, Cairo, Huff, and Fe -- against a Safety-by-Design Assessment Framework (SDAF) that measures how effectively each language's type system, execution model, and default behaviours prevent the 42 vulnerability patterns from the SCFVAF benchmark (Novak and Kovacs, 2025). The Language Safety Score (LSS) shows that Move achieves the highest safety (0.916) through its resource-oriented type system that makes reentrancy and double-spending structurally impossible. Rust-based languages score second (0.872) through ownership semantics. Solidity scores lowest (0.624) despite being the most widely used -- a gap between adoption and safety that the ecosystem should take seriously.