A Systematic Classification of Vulnerabilities in MoveEVM Smart Contracts (MWC)

Sel\c{c}uk Topal

REVIEW 4 major objections 5 minor 23 references

A Systematic Classification of Vulnerabilities in MoveEVM Smart Contracts (MWC)

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Hybrid Move-EVM contracts harbor flaws that standard tools miss.

desk verdict The taxonomy has some useful hybrid categories, but the empirical validation never actually exercises MoveEVM, and the category definitions contradict each other; this needs major surgery before it can be taken seriously. read the letter →

arxiv 2505.19047 v1 pith:X7SC22Z3 submitted 2025-05-25 cs.CR

Selçuk Topal This is my paper · ORCID

classification cs.CR

keywords MoveEVMsmartcontractsecurityvulnerabilitytaxonomyMWChybridexecutionSWCregistryformalverificationAI-assistedauditing

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This paper argues that a hybrid execution environment, in which Move's resource-oriented language runs inside an EVM-compatible runtime, creates a distinct class of smart-contract vulnerabilities that existing classification systems and analysis tools do not capture. To name that class, it introduces the MoveEVM Weakness Classification (MWC): 37 vulnerability types organized into six semantic frames, covering bytecode model inconsistencies, inter-module invariant violations, state reentrancy, meta-transaction spoofing, gas-semantics manipulation, and unsafe framework abstractions. Supporting the taxonomy, the author reviews 42 contracts from Aptos, Sui, and hybrid bridges, reports 21 distinct vulnerabilities, and says 11 of them align with MWC categories that the traditional SWC registry does not cover; Slither, Mythril, and the Move Prover allegedly missed eight of those eleven. If this is right, a substantial slice of hybrid smart-contract risk is currently invisible to standard EVM and Move tooling, and a shared vocabulary like MWC would give developers, auditors, and automated agents a way to find and talk about it. The paper also sketches how formal verification and LLM-based audit agents could use MWC categories as their organizing structure.

What carries the argument

The central object is the frame-based MWC classification: six semantic frames, named Bytecode Model Inconsistencies, Inter-Module Invariant Violations, State Reentrancy and Synchronization Bugs, Meta-Transaction and Signature Spoofing, Gas Semantics Manipulation, and Framework Logic Errors and Unsafe Abstractions, which organize the 37 individual MWC codes. The frames do the argument's work by giving a labelling scheme for bugs that arise where Move's resource invariants meet EVM calldata, ABI decoding, gas metering, callbacks, and cross-domain signatures, so that a concrete failure can be assigned to a frame and then targeted by formal tools or LLM agents.

What would settle it

Run the paper's case studies, or a fresh sample of MoveEVM contracts, through current Slither, Mythril, and Move Prover with the MWC labels stripped, and check whether the 11 claimed SWC-invisible vulnerabilities are detected or already have SWC entries; if most are detected or already covered, the new-taxonomy claim collapses.

Watch

Extended reading notes

Core claim

The paper's central claim is that MoveEVM, defined as Move's resource-oriented semantics executed inside an EVM-compatible environment, exhibits hybrid vulnerabilities that neither the SWC registry nor existing analyzers are built to handle. It presents MWC as a taxonomy of 37 codes (MWC-100 to MWC-136) grouped into six semantic frames, and reports that in a review of 42 contracts it found 21 distinct vulnerabilities, of which 11 map to MWC categories absent from SWC; current static tools such as Slither, Mythril, and the Move Prover were reportedly unable to identify eight of those eleven. The paper concludes that this demonstrates a real tooling gap and proposes MWC as a common basis for audits, formal verification, and LLM-driven audit pipelines.

Load-bearing premise

The taxonomy presupposes that MoveEVM is a stable, well-specified hybrid execution environment; if that platform is not well-defined or does not exist as described, the 37 categories have no clear target and the 21-vulnerability counts do not apply.

Editorial extensions

If this is right

Auditors and tool builders would need to add MWC frames to their checklists, because SWC alone will miss hybrid bugs such as ABI deserialization mismatches and signature replay across domains.
Formal verification of Move contracts would need to be extended to EVM ABI-conformant entrypoints, since the paper finds Move Prover specifications often do not cover the fallback dispatch path.
LLM-based audit agents could use the 37 MWC codes as structured prompt tasks, making audits more repeatable and more comparable across contracts and tools.
If the reported tooling gap holds, current EVM security tooling gives false confidence for MoveEVM deployments until hybrid-aware detectors are built.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A testable extension of the paper's claim would be to build concrete detection predicates for each MWC-XXX code and measure inter-auditor agreement, since a taxonomy label without a decision procedure is hard to apply consistently.
The frame-based idea may transfer to other hybrid runtimes, such as zkEVM-Move or Rust-based EVM bridges, because the underlying phenomenon is that source-language safety guarantees do not survive crossing a bytecode boundary.
The empirical counts are probably an upper bound on the phenomenon, because the sample is small and partly drawn from public incident reports; the true prevalence of MWC-only flaws in production MoveEVM contracts remains open.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Here's the short version: this paper proposes a vulnerability taxonomy for 'MoveEVM' but the evidence it presents for that taxonomy never actually involves MoveEVM. The 42 reviewed contracts are from Aptos and Sui, which are native Move chains, plus a prototype bridge. None of them run in an EVM-compatible Move runtime. So the 21 vulnerabilities and the 8-of-11 tool-miss rate are not evidence about MoveEVM at all. That is a load-bearing problem. The taxonomy itself also contradicts itself: MWC-101 is defined as uninitialized state in Section 3, as unsafe struct encoding in Section 4, and as something else again in Section 6. MWC-120 appears twice with different meanings. The paper needs substantial rework before the classification can be trusted.

What's genuinely new: the six-frame grouping and some of the hybrid categories (ABI deserialization mismatches, dual-layer gas metering, cross-domain signature reuse) are not in SWC or MoveScan. If the authors had scoped the taxonomy to 'risks in hybrid Move/EVM designs' and backed it with a real MoveEVM implementation or even a well-specified threat model, it would be a useful organizational contribution.

The paper does not ship a dataset, tool versions, or per-case writeups for the empirical claims. The circularity the reader points out is real: the categories were derived from the same incidents used for validation. That needs an independent holdout to mean anything.

Who is this for? Auditors and tool builders working on hybrid Move/EVM stacks might mine the category list for ideas, but they should not cite the empirical results.

For peer review: I would send it to a journal with a request for major revision, not reject out of hand. The taxonomy idea is publishable if the authors fix the internal contradictions, add a clear definition of MoveEVM, and either supply real data or drop the empirical claims entirely. As it stands, the paper is not ready but it is not worthless.

Referee Report

4 major / 5 minor

Summary. The paper introduces the MoveEVM Weakness Classification (MWC), a taxonomy of 37 vulnerability codes (MWC-100 to MWC-136) grouped into six semantic frames, intended for smart contracts that combine the Move language with EVM-compatible execution. The central claims are that existing taxonomies such as SWC miss a distinct class of hybrid Move-EVM vulnerabilities, that analysis of 42 real-world contracts from Aptos and Sui found 21 distinct vulnerabilities, that 11 of these align with new MWC categories, and that Slither, Mythril, and the Move Prover missed 8 of those 11. The paper also discusses how formal verification and LLM-based auditing agents could use the MWC taxonomy. The empirical and taxonomic claims are the load-bearing elements of the manuscript.

Significance. If the empirical claims were supported, the taxonomy would give auditors and tool builders a shared vocabulary for hybrid Move/EVM vulnerabilities, and the reported tool-gap would motivate new analyzers. The paper also makes a useful connection to LLM-based auditing and is honest in Section 11.3 that no labeled MoveEVM benchmark corpus currently exists. However, the manuscript does not provide the dataset, per-case evidence, tool configurations, or a concrete MoveEVM reference implementation needed to support the central claims; as submitted, the work is an internally inconsistent taxonomy with unsupported empirical counts.

major comments (4)

[Sec. 7.4, with Secs. 7.1-7.3 and 8.1-8.3] The empirical validation does not exercise a MoveEVM environment. The contracts described in Section 7 are a 'Sui-based lending contract' and an 'Aptos-EVM bridge,' and Section 8 analyzes an Aptos NFT minting issue, a Sui-based DEX, and a 'MoveEVM-to-EVM bridge adapter prototype'; Aptos and Sui are native Move chains, not hybrid Move-EVM runtimes, and the prototype is not described as a MoveEVM platform. No artifact, dataset, or per-case writeup is supplied for the 42 reviewed contracts, and no tool versions, configurations, or individual tool outputs are reported. Consequently, the central numbers in Section 7.4 (21 vulnerabilities, 11 MWC-aligned, 8 tool misses) are unsubstantiated, and the claim that existing tools cannot detect MoveEVM-specific vulnerabilities is untested.
[Secs. 3.1, 4.2, 5, 7, and 8] The taxonomy is internally inconsistent: MWC-101 is 'Undefined state behavior when contract state variables are uninitialized' in Section 3.1, 'Unsafe encoding of Move structs in raw calldata' in Section 4.2, and 'Uninitialized State' in Section 5; MWC-120 is 'Weak signature verification' in Section 3.4 and 'Move Prover incompleteness on EVM ABI-conformant entrypoints' in Section 4.2; MWC-130 is 'Algorithm bias in AI-based smart contracts' in Section 3.6, 'Emission of inconsistent event structures' in Section 4.2, and 'Hybrid Reentrancy' in Section 8.3; and MWC-112 is 'Token supply overflow' in Section 3.3 but 'Cross-Module Resource Leakage' in Section 7.1 and 'Module Boundary Escapes' in Section 8.2. A classification system whose codes have multiple inconsistent meanings cannot serve as a repeatable audit framework.
[Secs. 1 and 4.4] The target platform is underspecified. MoveEVM is introduced only through a single citation to Abrahimi (2023), with no reference implementation, bytecode semantics, gas model, or ABI definition. Section 4.4 scopes the taxonomy to 'MoveEVM contracts and hybrid runtime behaviors' as though the platform were well-defined, while Section 7.4 lumps 'Aptos, Sui, and hybrid bridges' into 'MoveEVM-enabled environments.' This conflation makes it unclear whether the taxonomy classifies a real execution environment or a hypothetical one, and it undermines the applicability of the empirical counts.
[Secs. 2.6, 7, and 8] The validation appears circular. The taxonomy is presented as empirically derived, but the case studies in Sections 7 and 8 classify previously reported incidents (e.g., the Aptos NFT minting issue and the Sui DEX exploit) into MWC codes, and no held-out corpus, independent benchmark, or inter-rater assessment is described. Because the taxonomy seems to have been built from the same class of incidents used for validation, Section 7.4's statement that the findings 'validate the necessity of the MWC taxonomy' is not supported by the evidence presented.

minor comments (5)

[Sec. 6 and Table .1] The paper states that SWC is 'a flat listing of more than 100 categories,' while Table .1 lists SWC granularity as '36 categories with varying detail'; the same table also introduces names such as MWC-101 'Numeric Edge Conditions' and MWC-110 'Linear Resource Violations' that do not match the definitions in Section 3.
[Sec. 10.1] The Move Prover is attributed to Bartoletti et al. (2025), but the primary Move Prover references appear correctly in Section 2.4 as Zhong et al. (2020) and Dill et al. (2022); the Section 10.1 citation should be corrected.
[Sec. 2.4] Section 2.4 contains two nearly identical paragraphs describing Slither, Securify, Mythril, Echidna, Manticore, and the Move Prover; one copy should be removed.
[Sec. 5] Many code listings contain space-inserted identifiers (e.g., 'wi th draw', 't ra nsf er', 'Ex te rna l'), which makes the examples difficult to read; the listings should be cleaned and, where possible, compiled or type-checked.
[General] The title page states 'Preprint submitted to Results in Physics,' which appears mismatched with the cs.CR content; the authors should verify the intended submission venue and update the metadata.

Circularity Check

2 steps flagged · score 6.0 of 10

Empirical counts and tool-gap claim reduce to the taxonomy's own definitions; no held-out validation.

fitted input called prediction [Section 7.4 (Summary of Findings); cf. Sections 2.6, 6, 7.1-7.3, 8.1-8.3]
"We found 21 distinct vulnerabilities across 42 reviewed contracts across di fferent MoveEVM-enabled environments (such as Aptos, Sui, and hybrid bridges), of which 11 directly aligned with newly proposed MWC categories that are not captured by the traditional SWC registry. This supports the central claim of this paper, which is that the hybrid execution model of MoveEVM presents new and non-trivial vulnerability surfaces that go beyond the purview of current EVM-centric taxonomies."

This 'empirical' count is produced by the same authors classifying a small set of public Aptos/Sui incidents and a prototype bridge into their own MWC codes (Sec 7.1-7.3, 8.1-8.3). The MWC taxonomy was defined in Sec 3-4 as the MoveEVM-specific complement of SWC, and Sec 6 explicitly says 'Traditional SWC codes are unable to identify new vulnerability surfaces brought about by this fusion.' Hence any vulnerability labeled with a new MWC code is, by construction, 'not captured by the traditional SWC registry'; the 11/21 alignment is a restatement of the labeling, not an independent empirical test. No held-out corpus, independent annotators, or pre-registered mapping is provided.
self definitional [Section 7.4, tool-gap paragraph; cf. Section 4.2 (F1-F6) and Section 6]
"Crucially, current static analysis tools like Slither, Mythril, or the Move Prover, which are made for Solidity or pure Move environments, were unable to identify eight of the eleven MWC-classified vulnerabilities. Future development of hybrid-aware auditing and verification frameworks must address this significant tooling gap."

The MWC frames in Sec 4.2 (e.g., F1 'Bytecode Model Inconsistencies', F5 'Gas Semantics Manipulation') are defined as hybrid Move-EVM phenomena, and Sec 6 states that SWC and EVM-centric tooling cannot represent such phenomena. Slither and Mythril are Solidity/EVM analyzers, and the Move Prover is a pure-Move verifier, so by the taxonomy's own definitions these tools cannot detect hybrid-only MWC categories. The 'eight of eleven tools missed them' result is therefore entailed by the category definitions rather than demonstrated by documented tool runs. No tool versions, configurations, input corpus, or per-case outputs are given, so the empirical content is not independently checkable.

full rationale

The paper does not rely on a self-citation chain; the author cites no prior work of his own, so the usual self-citation circularity patterns are absent. The taxonomy itself contains some genuinely hybrid categories and is not wholly vacuous. The circularity lies in the validation narrative: the paper defines MWC categories as the MoveEVM-specific, non-SWC complement, then confirms the taxonomy by classifying a small set of public Aptos/Sui incidents into those same categories and counting how many are 'not captured by SWC' or 'missed' by non-hybrid tools. Those two headline results reduce to the definition of the categories. Separately, the corpus behind '42 reviewed contracts' is never listed, and no contract is shown to run in a concrete MoveEVM runtime; Aptos and Sui are native Move chains and the bridge is a prototype. These are evidence problems, but the specific circular reduction is the fitting of the taxonomy's own inputs into its own labels before calling them empirical findings. Score 6 reflects partial circularity: the central empirical claims are forced by construction, while the taxonomy retains some independent organizational content.

Assumptions & free parameters 3 free parameters · 4 assumptions · 2 invented entities

The paper's central contribution rests on hand-chosen categories, an assumed MoveEVM platform, and an unverifiable empirical count; there are no free parameters in the physics sense, but each design choice and each stated count is effectively a fitted choice made to support the narrative.

free parameters (3)

MWC category set (MWC-100 to MWC-136) = 37 hand-selected categories
The categories and their boundaries were chosen by the author without algorithmic derivation, inter-rater validation, or a sampling protocol; several categories overlap or are defined inconsistently across sections.
Six semantic frames (F1 to F6)
The grouping of the 37 codes into frames is a manual design choice with no demonstrated explanatory or predictive power.
Empirical counts (21 vulnerabilities, 42 contracts, 11 MWC-aligned, 8 tool-misses) = 21/42, 11/21, 8/11
These numbers appear in Sec 7.4 with no artifact, sampling frame, or tool configuration; they function as fitted claims that ground the paper's validation narrative.

assumptions (4)

domain assumption Move's linear type system and resource safety carry over to MoveEVM
Sec 2.2 and Sec 4.1 assume that Move's guarantees (no duplication or loss of resources) hold inside the hybrid EVM runtime, which is exactly what the paper later disputes; this premise is asserted, not demonstrated for the hybrid model.
domain assumption MoveEVM is a well-defined, stable execution environment
The paper cites only Abrahimi (2023) for MoveEVM and gives no reference implementation, yet the whole taxonomy is scoped to 'MoveEVM' as if it were a single platform (Sec 1, 4.4).
ad hoc to paper Aptos and Sui contracts, plus a prototype bridge adapter, are representative MoveEVM deployments
Sec 7 and 8 use Aptos/Sui contracts and a 'bridge adapter prototype' as evidence, but Aptos and Sui are not EVM-compatible in the same runtime, and the prototype is not a production system; this representativeness is assumed to make the empirical claim.
ad hoc to paper Existing tools (Slither, Mythril, Move Prover) were applied correctly and are comparable for MoveEVM
Sec 7.4 claims these tools missed 8 of 11 vulnerabilities, but no tool versions, arguments, or false-positive and false-negative analysis are provided; the assertion assumes the tools were used appropriately for a target they were not designed for.

invented entities (2)

MoveEVM (as a coherent, well-specified hybrid environment)
purpose: Target platform for the MWC taxonomy and its empirical validation
The paper references only a thesis for 'MoveEVM' and provides no public implementation or specification; several categories (e.g., MWC-113 gas metering, MWC-126 ABI serialization) presuppose specific hybrid behaviors that the cited literature does not establish.
Six semantic frames (F1 to F6)
purpose: Organizing structure for classifying vulnerabilities
The frame decomposition (BMI, IMI, SRS, MTS, GSM, FLA) is asserted as the natural division of MoveEVM risks without a derivation or validation; the codes within frames overlap (e.g., MWC-106 and MWC-130 both describe hybrid reentrancy).

how reviews work

0 comments

Cite this review

Pith. "Pith review of A Systematic Classification of Vulnerabilities in MoveEVM Smart Contracts (MWC)." pith.science (2026). https://pith.science/paper/X7SC22Z3

@misc{pith2026250519047,
  author       = {Pith},
  title        = {Pith review of: A Systematic Classification of Vulnerabilities in MoveEVM Smart Contracts (MWC)},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/X7SC22Z3}},
  note         = {Machine review of arXiv:2505.19047}
}

read the original abstract

We introduce the MoveEVM Weakness Classification (MWC) system -- a dedicated vulnerability taxonomy for smart contracts built with Move and executed in EVM-compatible environments. While Move was originally designed to prevent common security flaws via linear resource types and strict ownership, its integration with EVM bytecode introduces novel hybrid vulnerabilities not captured by existing systems like the SWC registry. Our taxonomy spans 37 categorized vulnerability types (MWC-100 to MWC-136) across six semantic frames, addressing issues such as hybrid gas metering, capability misuse, meta-transaction spoofing, and AI-integrated logic. Through analysis of real-world contracts from Aptos and Sui, we demonstrate that current verification tools often miss these hybrid risks. We also explore how formal methods and LLM-based audit agents can operationalize this classification, enabling scalable, logic-aware smart contract auditing. MWC lays the foundation for more secure and verifiable contracts in next-generation blockchain systems. (Shortened Abstract)

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

23 extracted references · 18 canonical work pages

[3]

Available at: https://blockworks.co/news/suis-decentralization-dex-put-to-the-test

Dex exploit. Available at: https://blockworks.co/news/suis-decentralization-dex-put-to-the-test. Accessed: 2025-05-23. Buterin, V .,

work page 2025
[5]

Available at: https://developers.libra.org/docs/assets/papers/the-libra-blockchain.pdf

Libra white paper. Available at: https://developers.libra.org/docs/assets/papers/the-libra-blockchain.pdf. Feist, J., Grieco, G., Groce, A., 2019a. Slither: a static analysis frame- work for smart contracts, in: 2019 IEEE /ACM 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB), IEEE. pp. 8–15. Feist, J., Grieco, ...

work page 2019
[7]

arXiv preprint arXiv:2502.18515

A multi-agent framework for automated vulnerability detection and repair in solidity and move smart contracts. arXiv preprint arXiv:2502.18515 . Keilty, E., Nelaturu, K., Wu, B., Veneris, A.,

work page arXiv
[9]

Available at: https://python.langchain.com/docs/introduction/

Langchain. Available at: https://python.langchain.com/docs/introduction/. Accessed: 2024-9-12. Li, W., Bu, J., Li, X., Peng, H., Niu, Y ., Zhang, Y .,

work page 2024
[12]

Deferred Objects to Enhance Smart Contract Programming with Optimistic Parallel Execution

Deferred objects to en- hance smart contract programming with optimistic parallel execution. arXiv preprint arXiv:2405.06117 . Mossberg, M., Manzano, F., Hennenfent, E., Groce, A., Grieco, G., Feist, J., Brunson, T., Dinaburg, A.,

work page Pith review arXiv
[13]

Manticore: A user-friendly symbolic exe- cution framework for binaries and smart contracts, in: 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE), IEEE. pp. 1186–1189. Nikoli´c, I., Kolluri, A., Sergey, I., Saxena, P., Hobor, A.,

work page 2019
[14]

Robust safety for move, in: 2023 IEEE 36th Computer Security Foundations Symposium (CSF), IEEE. pp. 308–

work page 2023
[15]

Ieee Access 8, 24416–24427

Smart contract: Attacks and protections. Ieee Access 8, 24416–24427. Security, Z., 2023a. Move fast and break things, aptos. https://www.zellic.io/blog/move-fast-and-break-things-pt-1. Accessed: 2024-11-12. Security, Z., 2023b. Move fast and break things, sui. https://www.zellic.io/blog/move-fast-break-things-move-security-part-2. Accessed: 2024-11-12. Sh...

work page 2024

Show all 23 references

[16]

The swc-based security analysis tool for smart contract vulnerability detection, in: 2022 6th International Conference on Information Technology (InCIT), IEEE. pp. 74–77. Soud, M., Liebel, G., Hamdaqa, M.,

2022
[17]

https://swcregistry.io/

Swc registry: Smart contract weakness classification and test cases. https://swcregistry.io/. Accessed: 2024-04-12. Szabo, N.,

2024
[19]

arXiv preprint arXiv:2404.00689

Llm-smartaudit: Collaborative multi-agent contract analysis. arXiv preprint arXiv:2404.00689 . Werner, S.M., Perez, D., Gudgeon, L., Klages-Mundt, A., Knottenbelt, W., Livshits, B.,

arXiv
[20]

arXiv preprint arXiv:2308.08155

Autogen: Enabling next-gen llm applications via multi-agent conversation framework. arXiv preprint arXiv:2308.08155

arXiv
[21]

arXiv preprint arXiv:2504.07419

Exploring vulnerabilities and concerns in solana smart contracts. arXiv preprint arXiv:2504.07419 . Xia, S., Shao, S., He, M., Yu, T., Song, L., Zhang, Y .,

arXiv
[22]

arXiv preprint arXiv:2404.04306

Auditgpt: Auditing smart contracts with chatgpt. arXiv preprint arXiv:2404.04306 . Zhang, X., Li, Y ., Sun, M.,

arXiv
[23]

Towards a formally verified evm in produc- tion environment, in: Coordination Models and Languages: 22nd IFIP WG 6.1 International Conference, COORDINATION 2020, Held as Part of the 15th International Federated Conference on Distributed Computing Tech- niques, DisCoTec 2020, V...

2020
[2016]

Making smart contracts smarter, in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, ACM. pp. 254–269. Mitenkov, G., Kabiljo, I., Li, Z., Spiegelman, A., Vusirikala, S., Xiang, Z., Zlateski, A., Lopes, N.P., Gelashvili, R.,

2016
[2018]

Securify: Practi- cal security analysis of smart contracts, in: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS), pp. 67–82. Wei, Z., Kumar, N.,

2018
[2019]

Accessed: 2025-05-12

Diem developers.https://diem.github.io/move/introduction.html. Accessed: 2025-05-12. Dill, D., Grieskamp, W., Park, J., Qadeer, S., Xu, M., Zhong, E.,

2025
[2020]

arXiv preprint arXiv:2002.08099

The defi ecosystem: Chal- lenges, opportunities and vulnerabilities. arXiv preprint arXiv:2002.08099 . Bartoletti, M., Crafa, S., Lipparini, E.,

2002 arXiv
[2022]

A model-checking frame- work for the verification of move smart contracts, in: 2022 IEEE 13th In- ternational Conference on Software Engineering and Service Science (IC- SESS), IEEE. pp. 1–7. Labs, M., 2022a. Sui white paper. https://docs.sui.io/paper/sui.pdf. 18 Labs, N.C., 2...

2022
[2023]

https://hackenproof.com/reports/sui-node-crash-move

Sui vulnerability: Crafted bytecode causes node crash. https://hackenproof.com/reports/sui-node-crash-move. Ac- cessed: 2025-05-12. He, W., Xia, Y ., Zhang, Z., Wang, W.,

2025
[2024]

arXiv preprint arXiv:2405.02580

Proper- tygpt: Llm-driven formal verification of smart contracts through retrieval- augmented property generation. arXiv preprint arXiv:2405.02580 . Luu, L., Chu, D.H., Olickel, H., Saxena, P., Hobor, A.,

arXiv
[2025]

arXiv preprint arXiv:2502.13929

Formal verification in so- lidity and move: insights from a comparative analysis. arXiv preprint arXiv:2502.13929 . Bauer, D.P.,

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [3]

Available at: https://blockworks.co/news/suis-decentralization-dex-put-to-the-test

Dex exploit. Available at: https://blockworks.co/news/suis-decentralization-dex-put-to-the-test. Accessed: 2025-05-23. Buterin, V .,

work page 2025

[2] [5]

Available at: https://developers.libra.org/docs/assets/papers/the-libra-blockchain.pdf

Libra white paper. Available at: https://developers.libra.org/docs/assets/papers/the-libra-blockchain.pdf. Feist, J., Grieco, G., Groce, A., 2019a. Slither: a static analysis frame- work for smart contracts, in: 2019 IEEE /ACM 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB), IEEE. pp. 8–15. Feist, J., Grieco, ...

work page 2019

[3] [7]

arXiv preprint arXiv:2502.18515

A multi-agent framework for automated vulnerability detection and repair in solidity and move smart contracts. arXiv preprint arXiv:2502.18515 . Keilty, E., Nelaturu, K., Wu, B., Veneris, A.,

work page arXiv

[4] [9]

Available at: https://python.langchain.com/docs/introduction/

Langchain. Available at: https://python.langchain.com/docs/introduction/. Accessed: 2024-9-12. Li, W., Bu, J., Li, X., Peng, H., Niu, Y ., Zhang, Y .,

work page 2024

[5] [12]

Deferred Objects to Enhance Smart Contract Programming with Optimistic Parallel Execution

Deferred objects to en- hance smart contract programming with optimistic parallel execution. arXiv preprint arXiv:2405.06117 . Mossberg, M., Manzano, F., Hennenfent, E., Groce, A., Grieco, G., Feist, J., Brunson, T., Dinaburg, A.,

work page Pith review arXiv

[6] [13]

Manticore: A user-friendly symbolic exe- cution framework for binaries and smart contracts, in: 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE), IEEE. pp. 1186–1189. Nikoli´c, I., Kolluri, A., Sergey, I., Saxena, P., Hobor, A.,

work page 2019

[7] [14]

Robust safety for move, in: 2023 IEEE 36th Computer Security Foundations Symposium (CSF), IEEE. pp. 308–

work page 2023

[8] [15]

Ieee Access 8, 24416–24427

Smart contract: Attacks and protections. Ieee Access 8, 24416–24427. Security, Z., 2023a. Move fast and break things, aptos. https://www.zellic.io/blog/move-fast-and-break-things-pt-1. Accessed: 2024-11-12. Security, Z., 2023b. Move fast and break things, sui. https://www.zellic.io/blog/move-fast-break-things-move-security-part-2. Accessed: 2024-11-12. Sh...

work page 2024