pith. sign in

arxiv: 2604.26727 · v2 · pith:DCEXS2L7new · 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-22 10:47 UTC · model grok-4.3

classification 💻 cs.SE cs.PL
keywords smart contractsSolidityMove languagesecurity checksprogramming paradigmsresource-oriented languagesdeveloper experiencecyclomatic complexity
0
0 comments X

The pith

Resource-oriented languages like Move cut explicit security checks in smart contracts by 60 percent compared to Solidity.

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

The paper examines whether programming language paradigms can lower the manual effort needed to secure smart contracts. It compares twelve pairs of functionally identical contracts written by the same team in Solidity and in Move, tracking how much code is spent on explicit security validations such as access controls and balance checks. The results show that Move achieves the same logical behavior with far fewer of these checks because many safety rules are enforced by the type system at compile time rather than added as runtime code. A small survey of developers familiar with both languages finds greater confidence in Move's safety properties despite a moderate learning curve and less mature tooling. These controlled observations suggest that paradigm choice itself can shift where security work happens.

Core claim

In the twelve matched contract pairs the density of explicit security checks fell from 16.8 percent in Solidity to 6.7 percent in Move, a 60 percent reduction that reached statistical significance, while cyclomatic complexity stayed identical and total code size grew by 47 percent. Developers who had worked in both languages gave Move a median safety-confidence rating of six out of seven and more than half said they would choose it for security-critical applications once ecosystem gaps are addressed.

What carries the argument

Security check density, the measured fraction of source code occupied by manual runtime validations for access, ownership, and state consistency.

If this is right

  • Developers write and review less security-specific code when using the resource-oriented language.
  • Logical complexity of the contracts does not change, so the reduction is not achieved by simplifying the intended behavior.
  • Larger source files may raise on-chain storage costs even though the number of decision points stays the same.
  • Developers who overcome the initial learning cost report higher confidence that safety properties hold.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the density difference appears in larger and more diverse samples, language selection itself becomes a practical lever for lowering exploit risk.
  • Measuring actual vulnerability rates in production contracts written in each paradigm would test whether lower check density translates into fewer real incidents.
  • Extending the comparison to additional resource-oriented languages would show whether the pattern is tied to Move or to the broader paradigm.

Load-bearing premise

The twelve functionally equivalent contract pairs written by one team give an unbiased picture of how security code is normally written in each language.

What would settle it

A replication with contracts built independently by separate teams that finds no statistically significant drop in security-check density when the same functionality is expressed in Move.

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 comparing Solidity and Move smart contract paradigms using 12 functionally equivalent contract pairs written by the same team and 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 work.

Significance. If the security classification protocol proves robust, the controlled same-team design and reported effect sizes offer initial quantitative evidence that resource-oriented type systems can shift security effort from runtime checks to compile-time guarantees. This informs language selection for smart contracts and highlights trade-offs in code size and learning curve, though the small n limits generalizability.

major comments (2)
  1. [Methods] Methods section on security check identification: the protocol for classifying 'explicit security checks' is not described in detail. It is unclear whether invariants enforced by Move's linear types and resource ownership are excluded from counts while equivalent runtime guards in Solidity (require/assert) are included; this directly undermines the 60% density reduction claim and the p=0.002 result, as the metric may not be paradigm-neutral.
  2. [Results] Results, §4 (quantitative analysis): with n=12 pairs the large effect sizes are presented, but no sensitivity analysis to alternative security-check definitions or inter-rater reliability metrics is reported. This is load-bearing for the central paradigm-effect conclusion given the language-specific idioms noted in the skeptic's concern.
minor comments (2)
  1. [Abstract] Abstract: the limitation of small sample size (n=12, n=11) should be stated more explicitly alongside the 'preliminary' qualifier.
  2. [Survey] Survey section: missing details on survey administration, exact questions, and how 'experienced in both languages' was verified would improve reproducibility.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive and detailed feedback on our preliminary mixed-methods study. We address each major comment below, providing clarifications and indicating where revisions have been made to strengthen the manuscript.

read point-by-point responses

  1. Referee: [Methods] Methods section on security check identification: the protocol for classifying 'explicit security checks' is not described in detail. It is unclear whether invariants enforced by Move's linear types and resource ownership are excluded from counts while equivalent runtime guards in Solidity (require/assert) are included; this directly undermines the 60% density reduction claim and the p=0.002 result, as the metric may not be paradigm-neutral.

    Authors: We agree that the original Methods section provided only a high-level description of the classification protocol and that greater detail is necessary for replicability and to demonstrate paradigm neutrality. Explicit security checks were defined as developer-authored runtime validations (require/assert statements and equivalent patterns), with language-enforced invariants from Move's resource model deliberately excluded to isolate the reduction in manual checks. In the revised manuscript, we have substantially expanded Section 3.2 with a step-by-step protocol, decision criteria, concrete examples drawn from the 12 contract pairs, and explicit rules distinguishing compile-time guarantees from runtime checks in both languages. These changes preserve the reported 60% reduction while improving transparency. revision: yes

  2. Referee: [Results] Results, §4 (quantitative analysis): with n=12 pairs the large effect sizes are presented, but no sensitivity analysis to alternative security-check definitions or inter-rater reliability metrics is reported. This is load-bearing for the central paradigm-effect conclusion given the language-specific idioms noted in the skeptic's concern.

    Authors: We acknowledge that sensitivity analysis would better substantiate the robustness of the findings given the modest sample size and potential language-specific idioms. We have added a sensitivity analysis to the revised Results section, re-evaluating the security-check density under two alternative operationalizations (a stricter definition limited to direct assertions and a broader one incorporating additional safety-related constructs). The direction, magnitude, and statistical significance of the 60% reduction remain consistent across these variants. Inter-rater reliability metrics were not originally reported because classification was performed jointly by the two authors who implemented the contracts, reaching full consensus; we have now documented this process explicitly and added it as a limitation in the Discussion. revision: yes

Circularity Check

0 steps flagged

Empirical code measurements and survey responses yield independent results without reduction to self-referential definitions or fitted predictions.

full rationale

The study derives its quantitative claims (security check density, code size, cyclomatic complexity) directly from manual analysis of 12 functionally-equivalent contract pairs and statistical tests on those observations, supplemented by separate survey data. No equations, parameters, or uniqueness theorems are fitted to subsets of the target data and then re-presented as predictions. No self-citation chain or ansatz is invoked to justify the central comparison. The methodology section presents the counting rules as an a-priori protocol applied to the collected artifacts, making the reported differences falsifiable against external replication rather than tautological by construction. This is a standard empirical comparison whose central claims remain independent of the inputs they summarize.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The central claims rest on the assumptions that the contract pairs are functionally equivalent and that security checks can be identified and counted consistently across languages without implementation bias.

axioms (2)
  • domain assumption The 12 contract pairs are functionally equivalent across languages.
    Required for attributing differences in security density to the language paradigm rather than functional differences.
  • domain assumption Security checks can be objectively and consistently identified in source code of both languages.
    Underpins the security check density metric and the 60% reduction claim.

pith-pipeline@v0.9.0 · 5770 in / 1395 out tokens · 45735 ms · 2026-05-22T10:47:47.021485+00:00 · methodology

Review history (2 revisions) →

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 · 32 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

    work page 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

    work page 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

    work page 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...

    work page 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

    work page 1995

  7. [7]

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

    work page 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

    work page 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

    work page 2020

  10. [10]

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

    work page

  11. [11]

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

    work page 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

    work page 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

    work page 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

    work page 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

    work page

  25. [25]

    In: Proceedings of the 34th Annual Computer Security Applications Conference

    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

    work page 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

    work page 2023