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

Source: arXiv - 2604.26727v1

Overview

The paper presents a first‑look, mixed‑methods comparison of two smart‑contract programming paradigms: the widely‑used imperative language Solidity and the newer resource‑oriented language Move. By implementing the same set of contracts in both languages and surveying developers who have worked with each, the authors investigate whether language design can meaningfully reduce the amount of security‑related code developers must write, and what trade‑offs this entails.

Key Contributions

• Empirical side‑by‑side comparison of 12 functionally equivalent contracts written in Solidity and Move by the same development team.
• Quantitative security‑overhead metric (security‑check density) showing a 60 % reduction when using Move (6.7 % vs. 16.8 %).
• Code‑size analysis revealing that Move contracts are on average 47 % larger (more boilerplate) while keeping cyclomatic complexity unchanged.
• Developer perception survey (11 participants) indicating higher confidence in Move’s safety guarantees and a majority preference for Move in security‑critical projects despite its younger ecosystem.
• Statistical validation (p = 0.002, large effect sizes) that the observed differences are unlikely to be due to chance.

Methodology

1. Controlled contract development – A single team built 12 pairs of contracts (e.g., token, escrow, voting) that perform identical business logic, one version in Solidity and the other in Move.
2. Metric extraction – For each contract the authors measured:
   • Security‑check density: proportion of lines that explicitly perform safety checks (e.g., require, assert).
   • Lines of code and cyclomatic complexity to gauge overall size and structural complexity.
3. Statistical analysis – Paired t‑tests compared the two languages, reporting p‑values and Cohen’s d effect sizes.
4. Developer survey – 11 developers with experience in both languages answered Likert‑scale questions on learning difficulty, confidence in safety, and language preference for high‑risk contracts.
5. Mixed‑methods synthesis – Quantitative results were contextualized with qualitative feedback from the survey (e.g., comments on tooling, documentation).

Results & Findings

• Security‑check density dropped from 16.8 % in Solidity to 6.7 % in Move (p = 0.002, d = ‑1.75), indicating that Move’s type system and resource model automatically enforce many checks that Solidity developers must write manually.
• Code size grew from an average of 84 LOC (Solidity) to 124 LOC (Move) (p = 0.002, d = 1.90). The increase stems mainly from Move’s explicit resource annotations and module boilerplate.
• Cyclomatic complexity remained statistically indistinguishable, suggesting that the added lines do not make the control flow harder to understand.
• Developer confidence: Median safety‑confidence rating of 6/7 for Move, with 10 of 11 participants rating it above neutral.
• Preference: 55 % of surveyed developers would choose Move for security‑critical contracts, despite acknowledging that Move’s tooling, libraries, and community are less mature than Solidity’s.

Practical Implications

• Language choice as a security lever – Teams building high‑value contracts (e.g., DeFi, custodial services) can obtain compile‑time safety guarantees by adopting a resource‑oriented language, potentially reducing the need for extensive runtime checks and audits.
• Tooling investment – The larger code footprint in Move highlights the need for better scaffolding tools (code generators, IDE plugins) to keep developer productivity high.
• Training & onboarding – While developers reported moderate learning difficulty, the payoff in safety confidence suggests that organizations should allocate time for Move training when security is a primary concern.
• Ecosystem considerations – Move’s current ecosystem gaps (fewer libraries, less community support) mean that early adopters may need to build custom modules or rely on internal tooling, which could affect time‑to‑market.
• Audit focus shift – Auditors can concentrate more on business‑logic correctness rather than hunting for missing runtime checks, potentially lowering audit costs for Move‑based projects.

Limitations & Future Work

• Sample size – The study examined only 12 contract pairs and surveyed 11 developers, limiting the generalizability of the findings.
• Controlled environment – All contracts were written by the same team; results may differ with diverse development teams or open‑source contributions.
• Ecosystem maturity – The analysis does not account for long‑term maintenance costs associated with a less mature Move ecosystem.
• Future directions – The authors plan to expand the dataset (more contract types, larger developer pool), evaluate runtime performance and gas costs, and investigate how tooling improvements could narrow the code‑size gap.

Authors

• Matteo Vaccargiu
• Andrea Pinna
• Maria Ilaria Lunesu
• Giuseppe Destefanis

Paper Information

• arXiv ID: 2604.26727v1
• Categories: cs.SE, cs.PL
• Published: April 29, 2026
• PDF: Download PDF