pith. sign in

arxiv: 2604.26727 · v1 · submitted 2026-04-29 · 💻 cs.SE · cs.PL

Comparing Smart Contract Paradigms: A Preliminary Study of Security and Developer Experience

Matteo Vaccargiu , Andrea Pinna , Maria Ilaria Lunesu , Giuseppe Destefanis This is my paper

Pith reviewed 2026-05-07 13:10 UTC · model grok-4.3

classification 💻 cs.SE cs.PL
keywords smart contractsSolidityMovesecurity overheadprogramming paradigmsdeveloper experienceresource-oriented languagesimperative languages
0
0 comments X

The pith

Resource-oriented languages reduce explicit security overhead in smart contracts by 60% compared to imperative languages.

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

The paper tests whether the programming paradigm used for smart contracts can lower the amount of manual security work required. It does so by having the same team write 12 contracts in both Solidity, an imperative language where checks must be added by hand, and Move, a resource-oriented language where many safety rules are enforced by the type system. The resource-oriented version needs far fewer explicit checks because potential errors are caught at compile time instead of runtime. This change comes with larger files and a learning curve for developers, yet it produces higher reported confidence in contract safety. Such a shift could matter because many expensive exploits stem from missed runtime checks that a different language design might prevent.

Core claim

By implementing 12 functionally equivalent contract pairs in Solidity and Move with the same development team, the study finds that Move lowers security check density from 16.8% to 6.7%, a 60% reduction that is statistically significant. Code size increases by 47% while cyclomatic complexity stays identical. A survey of 11 developers experienced in both languages reports moderate learning difficulty but a median safety confidence of 6 out of 7 for Move, with 55% preferring it for security-critical work despite ecosystem gaps.

What carries the argument

The controlled comparison of 12 functionally equivalent smart contract pairs written in Solidity and Move by the same team, together with a survey measuring security check density, code metrics, and developer-reported confidence and preferences.

Load-bearing premise

The 12 contract pairs perform exactly the same functions and that security checks were identified and counted the same way in both languages without bias from the shared development team.

What would settle it

A replication study using independent developers or a larger set of contracts that finds no significant drop in security check density or developer safety confidence when using the resource-oriented language.

Figures

Figures reproduced from arXiv: 2604.26727 by Andrea Pinna, Giuseppe Destefanis, Maria Ilaria Lunesu, Matteo Vaccargiu.

Figure 1
Figure 1. Figure 1: Resource-oriented patterns in Move contracts. Bub view at source ↗
Figure 2
Figure 2. Figure 2: Developer perceptions: (a) Safety confidence dis view at source ↗
read the original abstract

Smart contract vulnerabilities have caused billions in financial losses, raising questions about whether programming language paradigms can reduce security overhead. While imperative languages like Solidity require developers to manually implement security checks, resource-oriented languages like Move encode safety guarantees in type systems. We present a preliminary mixed-methods study analyzing 12 functionally-equivalent contract pairs implemented in both Solidity and Move by the same development team, complemented by a survey of 11 developers experienced in both languages. Quantitative analysis reveals that Move reduces explicit security overhead by 60\% (security check density: 6.7% vs. 16.8%, p=0.002, Cohen's d=-1.75) at the cost of 47% larger code size (p=0.002, d=1.90), while maintaining identical cyclomatic complexity. Developer surveys show moderate learning difficulty but higher safety confidence in Move (Median=6/7, 10 of 11 above neutral), with 55% preferring Move for security-critical applications despite ecosystem maturity gaps. These preliminary findings suggest resource-oriented paradigms shift security from runtime validation to compile-time guarantees, though adoption requires investment in learning and tooling. The controlled comparison provides initial evidence for paradigm effects on smart contract development, informing language selection decisions and identifying opportunities for improved developer resources.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper presents a preliminary mixed-methods study of smart contract security and developer experience, comparing 12 functionally-equivalent contract pairs implemented in both Solidity (imperative) and Move (resource-oriented) by the same team, along with a survey of 11 developers experienced in both languages. It reports that Move reduces explicit security check density by 60% (6.7% vs. 16.8%, p=0.002, Cohen's d=-1.75), increases code size by 47% (p=0.002, d=1.90), maintains identical cyclomatic complexity, and yields higher developer safety confidence (median 6/7) with 55% preferring Move for security-critical applications despite ecosystem gaps. The central claim is that resource-oriented paradigms shift security from runtime checks to compile-time guarantees.

Significance. If the results hold after addressing verification gaps, the work supplies initial empirical evidence that language paradigm choice can materially reduce explicit security overhead in smart contracts, complementing existing vulnerability studies with controlled comparisons and statistical reporting (p-values, effect sizes, medians). The mixed-methods design and focus on both quantitative overhead and qualitative developer preferences are strengths that could inform language selection guidelines and tooling priorities, though the preliminary scope limits generalizability.

major comments (2)
  1. [Methods] The Methods section (contract pair construction): The central 60% reduction claim in security check density rests on the 12 pairs being functionally equivalent, so that density differences reflect paradigm features rather than omitted behavior. The manuscript states the pairs were implemented by the same team but provides no description of shared test suites, differential testing, independent review, or other verification steps to establish equivalence. This is load-bearing; systematic divergence (e.g., Move versions handling fewer edge cases) could artifactually inflate the reported difference.
  2. [Results] Results (security check identification): Security checks were author-identified and counted to produce the 6.7% vs. 16.8% densities. Without an explicit protocol, inter-rater reliability measure, or blinding procedure, the possibility of implementation bias (same team authoring both versions) cannot be ruled out and directly affects the validity of the p=0.002 comparison.
minor comments (2)
  1. [Survey] The survey section could clarify response rate, recruitment method, and exact wording of the preference question to allow replication.
  2. [Results] Table or figure presenting per-contract security check counts would strengthen transparency beyond aggregate densities.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on our preliminary mixed-methods study. The comments highlight important areas for strengthening the methodological transparency of the work. We address each point below and will incorporate revisions to improve clarity and rigor without altering the core findings.

read point-by-point responses

  1. Referee: [Methods] The Methods section (contract pair construction): The central 60% reduction claim in security check density rests on the 12 pairs being functionally equivalent, so that density differences reflect paradigm features rather than omitted behavior. The manuscript states the pairs were implemented by the same team but provides no description of shared test suites, differential testing, independent review, or other verification steps to establish equivalence. This is load-bearing; systematic divergence (e.g., Move versions handling fewer edge cases) could artifactually inflate the reported difference.

    Authors: We agree that explicit documentation of functional equivalence verification is necessary to support the validity of the security check density comparison. The manuscript currently states only that the pairs were implemented by the same team from matching specifications. We will revise the Methods section to add a dedicated subsection detailing the equivalence process, including development from identical requirements, manual cross-review of implementations, and execution against shared test suites to confirm behavioral parity. This will directly address the concern that unverified divergences could affect the results. revision: yes

  2. Referee: [Results] Results (security check identification): Security checks were author-identified and counted to produce the 6.7% vs. 16.8% densities. Without an explicit protocol, inter-rater reliability measure, or blinding procedure, the possibility of implementation bias (same team authoring both versions) cannot be ruled out and directly affects the validity of the p=0.002 comparison.

    Authors: We acknowledge that author identification of security checks introduces a risk of bias, especially with the same team authoring both language versions. The counts were performed using consistent criteria based on standard vulnerability categories, but the manuscript does not describe the protocol. We will revise the Results section to explicitly outline the identification criteria and procedure. We will also expand the Threats to Validity section to discuss this limitation and note the absence of inter-rater reliability or blinding in this preliminary study. These changes will improve transparency while preserving the reported statistical comparisons. revision: yes

Circularity Check

0 steps flagged

No significant circularity: purely empirical measurements with no derivations or self-referential fits

full rationale

The paper reports direct code measurements (security check density, cyclomatic complexity, code size) across 12 implemented contract pairs plus survey responses from 11 developers. No equations, fitted parameters, predictions, or uniqueness theorems appear in the abstract or described methods. The 60% overhead reduction is a statistical comparison of observed counts, not a quantity derived by construction from prior self-citations or ansatzes. Functional-equivalence assumptions affect validity but do not create circularity in any derivation chain. The study is self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The central claims rest on domain assumptions about functional equivalence and consistent security-check identification rather than new free parameters or invented entities.

axioms (2)
  • domain assumption The 12 contract pairs are functionally equivalent across languages
    Required to attribute density differences to paradigm rather than functional divergence.
  • domain assumption Security checks can be reliably identified and counted in both languages
    Underpins the 6.7% vs 16.8% density metric and the 60% reduction claim.

pith-pipeline@v0.9.0 · 5539 in / 1354 out tokens · 65939 ms · 2026-05-07T13:10:40.135204+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

32 extracted references · 16 canonical work pages

  1. [1]

    Andrea Arcuri and Lionel Briand. 2011. A practical guide for using statistical tests to assess randomized algorithms in software engineering.33rd International Conference on Software Engineering(2011), 1–10

    2011

  2. [2]

    Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli. 2017. A survey of attacks on Ethereum smart contracts.Principles of Security and Trust(2017), 164–186

    2017

  3. [3]

    Massimo Bartoletti et al . 2024. Rosetta Smart Contracts: A Chrestomathy of Smart Contract Implementations. https://github.com/blockchain-unica/rosetta- smart-contracts. Accessed: January 2025

    2024

  4. [4]

    Massimo Bartoletti, Lorenzo Benetollo, Michele Bugliesi, Silvia Crafa, Gia- como Dal Sasso, Roberto Pettinau, Andrea Pinna, Mattia Piras, Sabina Rossi, Stefano Salis, Alvise Spanò, Viacheslav Tkachenko, Roberto Tonelli, and Roberto Zunino. 2025. Smart contract languages: A comparative analysis.Future Genera- tion Computer Systems164 (2025), 107563. doi:10...

    work page doi:10.1016/j.future.2024.107563 2025

  5. [5]

    Massimo Bartoletti, Silvia Crafa, and Enrico Lipparini. 2025. Formal Verification in Solidity and Move: Insights from a Comparative Analysis. In6th International Workshop on Formal Methods for Blockchains (FMBC 2025) (Open Access Series in Informatics (OASIcs), Vol. 129), Diego Marmsoler and Meng Xu (Eds.). Schloss Dagstuhl – Leibniz-Zentrum für Informati...

    2025

  6. [6]

    Yoav Benjamini and Yosef Hochberg. 1995. Controlling the false discovery rate: a practical and powerful approach to multiple testing.Journal of the Royal Statistical Society: Series B (Methodological)57, 1 (1995), 289–300

    1995

  7. [7]

    Virginia Braun and Victoria Clarke. 2006. Using thematic analysis in psychology. Qualitative Research in Psychology3, 2 (2006), 77–101

    2006

  8. [8]

    Lars Brünjes and Murdoch J. Gabbay. 2020. UTxO- vs Account-Based Smart Contract Blockchain Programming Paradigms. InLeveraging Applications of Formal Methods, Verification and Validation: Applications, Tiziana Margaria and Bernhard Steffen (Eds.). Springer International Publishing, Cham, 73–88

    2020

  9. [9]

    Huashan Chen, Marcus Pendleton, Laurent Njilla, and Shouhuai Xu. 2020. A sur- vey on ethereum systems security: Vulnerabilities, attacks and defenses.Comput. Surveys53, 3 (2020), 1–43

    2020

  10. [10]

    Mamdouh Chen, Felix Fischer, Na Meng, Xiaofeng Wang, and Jens Grossklags

  11. [11]

    An empirical study of developers’ discussions about security challenges of different programming languages.Empirical Software Engineering26, 6 (2021)

    2021

  12. [12]

    Myers, and Joshua Sunshine

    Michael Coblenz, Jonathan Aldrich, Brad A. Myers, and Joshua Sunshine. 2020. Can advanced type systems be usable? An empirical study of ownership, assets, and typestate in Obsidian.Proc. ACM Program. Lang.4, OOPSLA, Article 132 (Nov. 2020), 28 pages. doi:10.1145/3428200

    work page doi:10.1145/3428200 2020

  13. [13]

    1988.Statistical power analysis for the behavioral sciences

    Jacob Cohen. 1988.Statistical power analysis for the behavioral sciences. Routledge

    1988

  14. [14]

    Giuseppe Destefanis, Michele Marchesi, Marco Ortu, Roberto Tonelli, Andrea Bracciali, and Robert Hierons. 2018. Smart Contracts Vulnerabilities: A Call for Blockchain Software Engineering?. In2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE). IEEE, Campobasso, Italy, 19–25. doi:10. 1109/IWBOSE.2018.8327567

    work page arXiv 2018

  15. [15]

    Ferreira, Rui Abreu, and Pedro Cruz

    Thomas Durieux, João F. Ferreira, Rui Abreu, and Pedro Cruz. 2020. Empirical review of automated analysis tools on 47,587 Ethereum smart contracts. InPro- ceedings of the ACM/IEEE 42nd International Conference on Software Engineering (Seoul, South Korea)(ICSE ’20). Association for Computing Machinery, New York, NY, USA, 530–541. doi:10.1145/3377811.3380364

    work page doi:10.1145/3377811.3380364 2020

  16. [16]

    Georgiadis

    Antonios Giatzis, Stamatis Papangelou, and Christos K. Georgiadis. 2025. A Com- parative Study of Solidity and Sui Move: Advancing Smart Contract Development. IEEE Access13 (2025), 170504–170522. doi:10.1109/ACCESS.2025.3615072

    work page doi:10.1109/access.2025.3615072 2025

  17. [17]

    Simone Giuffrida, Shahid Salim, Azmat Ullah, and Matteo Vaccargiu. 2025. A Move Sui library for secure, certified and trusted supply chain ownership man- agement. In2025 IEEE/ACM 7th International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB). 50–56. doi:10.1109/WETSEB66605. 2025.00013

    work page doi:10.1109/wetseb66605 2025

  18. [18]

    Sungjae Hwang and Sukyoung Ryu. 2020. Gap between theory and practice: an empirical study of security patches in solidity. InProceedings of the ACM/IEEE 42nd International Conference on Software Engineering(Seoul, South Korea)(ICSE ’20). Association for Computing Machinery, New York, NY, USA, 542–553. doi:10. 1145/3377811.3380424

    work page arXiv 2020

  19. [19]

    Giacomo Ibba, Sabrina Aufiero, Rumyana Neykova, Silvia Bartolucci, Marco Ortu, Roberto Tonelli, and Giuseppe Destefanis. 2024. A Curated Solidity Smart Contracts Repository of Metrics and Vulnerability. InProceedings of the 20th International Conference on Predictive Models and Data Analytics in Software Engineering (PROMISE). ACM, Porto de Galinhas, Braz...

    work page arXiv 2024

  20. [20]

    2007.Estimating software costs: bringing realism to estimating

    Capers Jones. 2007.Estimating software costs: bringing realism to estimating. McGraw-Hill

    2007

  21. [21]

    Chihiro Kado, Naoto Yanai, Jason Paul Cruz, Kyosuke Yamashita, and Shingo Okamura. 2025. Empirical Study of Impact of Solidity Compiler Updates on Vulnerabilities in Ethereum Smart Contracts.Distrib. Ledger Technol.4, 2, Article 14 (June 2025), 14 pages. doi:10.1145/3688812

    work page doi:10.1145/3688812 2025

  22. [22]

    Thomas J McCabe. 1976. A complexity measure.IEEE Transactions on Software Engineering4 (1976), 308–320

    1976

  23. [23]

    Charalambos Mitropoulos, Maria Kechagia, Chrysostomos Maschas, Sotirios Ioannidis, Federica Sarro, and Dimitrios Mitropoulos. 2024. Broken Agreement: The Evolution of Solidity Error Handling. InProceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (Barcelona, Spain)(ESEM ’24). Association for Computing ...

    work page doi:10.1145/3674805.3686686 2024

  24. [24]

    Ivica Nikolić, Aashish Kolluri, Ilya Sergey, Prateek Saxena, and Aquinas Hobor

  25. [25]

    InProceedings of the 34th Annual Computer Security Applications Conference(San Juan, PR, USA) (ACSAC ’18)

    Finding The Greedy, Prodigal, and Suicidal Contracts at Scale. InProceedings of the 34th Annual Computer Security Applications Conference(San Juan, PR, USA) (ACSAC ’18). Association for Computing Machinery, New York, NY, USA, 653–663. doi:10.1145/3274694.3274743

    work page doi:10.1145/3274694.3274743

  26. [26]

    Marco Ortu, Matteo Orrù, and Giuseppe Destefanis. 2019. On Comparing Soft- ware Quality Metrics of Traditional vs Blockchain-Oriented Software: An Em- pirical Study. In2019 International Workshop on Blockchain Oriented Software Engineering (IWBOSE). IEEE, Hangzhou, China, 32–37. doi:10.1109/IWBOSE.2019. 8666770

    work page doi:10.1109/iwbose.2019 2019

  27. [27]

    Daniel Perez and Benjamin Livshits. 2021. Smart Contract Vulnerabilities: Vulner- able Does Not Imply Exploited. In30th USENIX Security Symposium (USENIX Se- curity 21). USENIX Association, 1325–1341. https://www.usenix.org/conference/ usenixsecurity21/presentation/perez

    2021

  28. [28]

    Shuwei Song, Jiachi Chen, Ting Chen, Xiapu Luo, Teng Li, Wenwu Yang, Leqing Wang, Weijie Zhang, Feng Luo, Zheyuan He, Yi Lu, and Pan Li. 2024. Empirical Study of Move Smart Contract Security: Introducing MoveScan for Enhanced Analysis. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis(Vienna, Austria)(ISSTA 202...

    work page doi:10.1145/3650212 2024

  29. [29]

    Christof Ferreira Torres, Julian Schütte, and Radu State. 2018. Osiris: Hunting for Integer Bugs in Ethereum Smart Contracts. InProceedings of the 34th Annual Computer Security Applications Conference(San Juan, PR, USA)(ACSAC ’18). Association for Computing Machinery, New York, NY, USA, 664–676. doi:10. 1145/3274694.3274737

    work page arXiv 2018

  30. [30]

    Matteo Vaccargiu, Rumyana Neykova, Nicole Novielli, Marco Ortu, and Giuseppe Destefanis. 2025. More Than Code: Technical and Emotional Dynamics in So- lidity’s Development. In2025 IEEE/ACM 18th International Conference on Co- operative and Human Aspects of Software Engineering (CHASE). IEEE, 260–271. doi:10.1109/CHASE66643.2025.00036

    work page doi:10.1109/chase66643.2025.00036 2025

  31. [31]

    Shuo Yang, Jiachi Chen, Mingyuan Huang, Zibin Zheng, and Yuan Huang. 2024. Uncover the Premeditated Attacks: Detecting Exploitable Reentrancy Vulnera- bilities by Identifying Attacker Contracts. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering(Lisbon, Portugal)(ICSE ’24). Association for Computing Machinery, New York, NY...

    work page doi:10.1145/3597503.3639153 2024

  32. [32]

    Liyi Zhou, Xihan Xiong, Jens Ernstberger, Stefanos Chaliasos, Zhipeng Wang, Ye Wang, Kaihua Qin, Roger Wattenhofer, Dawn Song, and Arthur Gervais. 2023. SoK: Decentralized finance (DeFi) attacks. In2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2444–2461

    2023