Pith. sign in

REVIEW 5 major objections 5 minor 41 references

Belobog is a type-graph-guided fuzzer that claims to detect all audited critical vulnerabilities in Move smart contracts by generating only well-typed transactions.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

Belobog is a type-graph-guided fuzzer that generates well-typed transaction sequences for Move smart contracts and claims to reach 93 of 109 audited vulnerabilities, including all 9 critical ones.

T0 review reviewed 2026-08-03 challenge →

load-bearing objection A genuinely novel type-aware Move fuzzer with credible incident reproductions, but the detection numbers are partly circular and the well-typedness guarantee is under-specified. the 5 major comments →

arxiv 2512.02918 v3 pith:RZVY6HXZ submitted 2025-12-02 cs.CR cs.PLcs.SE

Belobog: Move Language Fuzzing Framework For Real-World Smart Contracts

Ziqiao Kong , Wanxu Xia , Zhengwei Li , Yi Lu , Pan Li , Liqun Yang , Yang Liu , Xiapu Luo
show 1 more author
Shaohua Li
This is my paper
classification cs.CR cs.PLcs.SE
keywords fuzzingMove languagesmart contract securitytype graphconcolic executionHot Potato objectstype parameterscoverage-guided testing
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The reading

Belobog is presented as the first fuzzing framework that can test real-world Move smart contracts, a language whose strong type system blocks existing fuzzers from producing valid transactions. The paper's central claim is that by building a type graph that encodes Move's object types, type parameters, and object-consumption rules, the fuzzer can generate and mutate transactions that are always well-typed. Evaluated against 109 audited Move projects, Belobog detects 100% of critical and 79% of major vulnerabilities known to human auditors, reproduces two major exploits without prior knowledge, and surfaces new bugs in projects under audit. If the claims hold, Move contracts—which manage billions of dollars on Sui and Aptos—can finally be tested automatically despite their type safety.

Core claim

The paper introduces Belobog and argues that its type-graph construction and concolic executor solve the three obstacles that made Move fuzzing impractical: objects cannot be forged but must be produced by legitimate calls; generic functions must be instantiated with concrete types; and 'Hot Potato' objects must be consumed by exactly one subsequent call. The type graph models these constraints as labeled edges between type and function nodes, and the fuzzer uses graph traces to synthesize call sequences that obey them. A concolic executor built on the Move virtual machine then solves the value checks that random mutation would rarely satisfy. In the paper's evaluation, every critical vulner

What carries the argument

The load-bearing mechanism is the type graph: a static structure whose nodes are Move types (primitive, default, or 'Hot Potato') and function definitions, and whose labeled edges record how functions consume and produce each type, including type-parameter substitution. The fuzzer finds a path through this graph whose sources and sinks are all default types, instantiates the type parameters, and turns the path into a transaction; the same graph guides mutations that add or remove calls while preserving type validity. The concolic executor is the second mechanism, used to satisfy hard-coded numeric conditions that type-valid random values would almost never meet.

Load-bearing premise

The load-bearing premise is that hand-writing an oracle for every vulnerability from the audit report is a fair way to evaluate a fuzzer; without those bespoke oracles, the reported detection rates may not be attainable.

What would settle it

Run Belobog on the same 37-project dataset using only its six predefined oracles and no vulnerability-specific oracle; if it fails to detect the majority of the nine critical bugs, then the 100% critical detection claim is not a property of the fuzzer alone but of the bespoke oracles.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Move smart contracts on both Sui and Aptos can be fuzzed automatically, allowing projects to test continuously without writing low-level fuzzing harnesses.
  • Because the type graph guarantees well-typed transactions, fuzzers can reach deeper code paths: the paper reports 55.6% average edge coverage versus 8.8% for an existing fuzzer, and ten times higher throughput.
  • Known exploits such as the Cetus and Nemo incidents are reproducible in under three hours using a generic profit oracle, implying that deployments can validate against historical incidents via forked blockchains.
  • Ablation results attribute most of the detection to the type graph and type-parameter support; removing the type graph leaves only 3 of 109 bugs found, so type awareness, not just concolic solving, drives the result.
  • With per-project oracles, the framework found 2 critical, 2 major, and 3 medium previously unknown vulnerabilities in three ongoing audits, all acknowledged by developers.

Where Pith is reading between the lines

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

  • The per-vulnerability oracles are hand-written from audit reports (about 15 lines each), so the 100%/79% figures measure reachability conditioned on a human-provided specification; an automated oracle could turn Belobog into a fully unattended scanner.
  • Because the type graph already models production/consumption constraints, the same structure could serve as a basis for generating formal test oracles or for symbolic verification of resource invariants in Move.
  • The type-graph approach may transfer to other strongly-typed resource languages, but the authors note that EVM/Solidity's hashed storage hides type information, so the benefit is specific to Move-like systems.
  • If Belobog's concolic executor can solve value constraints like the Cetus overflow check, it may also be extended to state-dependent bugs, which the paper lists as future work.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

5 major / 5 minor

Summary. The paper presents Belobog, a fuzzing framework for Move smart contracts. It constructs a type graph to model object types, type parameters, and 'Hot Potato' resources, and uses this graph to generate and mutate transactions that are claimed to be well-typed. A concolic executor on top of the MoveVM is added to handle strict value checks. The evaluation on two datasets (DS1 from audit reports, DS2 from MoveScan) reports detection of 100% of critical and 79% of major audited vulnerabilities, reproduction of the Cetus and Nemo incidents, and discovery of new vulnerabilities in three ongoing audits. The central claim is that type-graph-guided fuzzing makes Move smart contracts, previously difficult to fuzz with existing tools, effectively testable.

Significance. If the results hold, Belobog would be a meaningful step forward for Move smart contract testing. The type-graph abstraction is well motivated by the three challenges identified (type safety, type parameters, hot-potato objects), and the engineering effort is substantial: 17k lines of Rust, a forked-chain object pool, and a concolic executor. The ablation study is a good practice and helps isolate component contributions. The prevalence analysis of type parameters and hot-potato objects is also useful. However, the evaluation's reliance on per-vulnerability oracles written from ground-truth audit reports makes the headline detection numbers a measure of reachability with custom oracles rather than autonomous detection. The absence of a released artifact and the inconsistent vulnerability counts further undermine the current evidence. The core engineering contribution is plausible, but the evaluation and the well-typedness guarantee need substantial clarification before the stated claims can be accepted.

major comments (5)
  1. [Section 5, Dataset Construction; Table 3] The DS1 vulnerability counts are internally inconsistent. The prose says the dataset has '9 Critical, 43 Major, and 35 Medium' (87 total), but Table 3 lists Ground Truth as 9/53/47 (109 total), and Section 5.1 says 'Out of all 109 bugs'. The reported 100% critical (9) and 79% major (42/53) match Table 3, not the prose. Please reconcile the dataset description, the tables, and the abstract so that all reported percentages derive from a single consistent ground-truth set.
  2. [Section 5.1, RQ1] The oracle construction is circular with respect to the detection claim. The paper states: 'We thus implement the oracle for each smart contract, averaging 15 lines per vulnerability' using ground-truth audit reports. This means the oracle encodes the exact behavior of each known vulnerability, so the experiment measures whether Belobog can reach a state satisfying a hand-written, audit-derived condition, not whether it autonomously detects vulnerabilities. The abstract's 'detect 100% critical and 79% major' is therefore overstated. Please reframe the results as bug reachability with custom oracles, or provide evidence that the oracles were written without knowledge of the specific audit findings (e.g., pre-registered, or derived from generic invariants).
  3. [Section 3.3/3.4] The type graph construction and type substitution do not account for ability constraints on type parameters, such as `T: store`, `T: drop`, or `T: key`. The graph only distinguishes default type nodes (at least one of drop/store) from hot-potato nodes (neither) and annotates edges with K↦→T substitutions. For a function `fun consume<T: drop>(Box<T>)`, a type with no `drop` ability cannot be substituted for T, but the described heuristic substitution does not track this bound. Without this information, the claimed guarantee that 'all generated and mutated transactions are well-typed' is unsupported. Please specify how ability constraints are represented and enforced, or extend the type graph and substitution algorithm accordingly.
  4. [Section 4, Oracle; Section 5.4] The 'Earning Profits' oracle is defined as any increase in sender-owned coins after a generated transaction. In a forked chain where the sender owns assets, a legitimate swap or withdrawal would also increase the sender's balance, so this oracle is not by itself a sound vulnerability detector. The paper reports no false positives for this oracle, but this needs justification. Please state the precise invariant checked (e.g., net value change accounting for all input objects, or a prohibition on newly minted coins) and explain how benign balance increases were excluded in the Cetus, Nemo, and real-world application studies.
  5. [Section 9, Data Availability] The code, the DS1 dataset, and the concolic executor implementation details are only promised 'upon acceptance'; the supplementary materials are not available with the manuscript. The central experimental claims cannot be reproduced or independently checked from the submitted version. Please provide the artifact, or at least a detailed supplementary document, for the review process.
minor comments (5)
  1. [Abstract; Section 5.1] The abstract says '109 real-world Move smart contract projects' while Section 5.1 says 'Out of all 109 bugs'. These are different counts; use consistent terminology and clarify what the denominator is.
  2. [Table 1] The 'Total' row appears garbled: 'Total 93 9 42 423 (1FP)' is hard to parse. Please reformat the table so that the total counts align with the column headers.
  3. [Section 3.5] The concolic executor is a key component, but its implementation details are deferred to supplementary materials. The main text should at least summarize how symbolic expressions are tracked and how the MoveVM bytecode is instrumented.
  4. [Figure 7] Coverage results are presented per-project without any confidence intervals or variance, despite each campaign being repeated five times. Reporting mean+-std or a boxplot would help assess stability.
  5. [Section 2.1] The prevalence analysis claims to collect 'all two billion transactions on the Sui blockchain from November 2024 to November 2025'. No details are given on how packages are attributed to transactions or how the ranking was computed. Please add methodology details.

Circularity Check

1 steps flagged

Headline detection rates are partly circular: per-vulnerability oracles are hand-written from the same audit reports that define the detected bugs.

specific steps
  1. fitted input called prediction [Section 5, Dataset Construction; Abstract/§5.1 detection claims]
    "Luckily, we have the ground-truth audit reports for DS1. We thus implement the oracle for each smart contract, averaging 15 lines per vulnerability. To avoid overfitting, we invite two additional Move auditors with at least 1 year of full-time experience to review the implementation."

    The evaluation's target set is exactly the audit-report vulnerability set, and the detector (oracle) for each vulnerability is manually implemented from that same report. 'Belobog detects 100% critical / 79% major' is therefore not an autonomous prediction: it counts vulnerabilities for which the authors wrote a custom oracle encoding the known bug's condition, then checked whether the fuzzer reaches it. The oracle input (audit ground truth) is the same information that defines the claimed output (detected vulnerability). This does not make the type-graph generation itself circular, but it makes the headline detection result partly an artifact of the evaluation setup.

full rationale

No significant circularity in the type-graph derivation: the graph construction, trace generation, type substitution, and concolic execution are defined from the Move type system and function signatures, and are validated by ablations (Table 3) that remove each component; those comparisons are independent of the oracle issue. The MoveScan [26] citations and shared authors are self-citation but not load-bearing: [26] is an external empirical study used as a dataset/baseline/oracle source, and the central fuzzing design does not reduce to it. The skeptic's ability-constraint gap (type parameters without drop/store/key constraints) is a correctness risk for the 'all transactions well-typed' claim, not a circularity. The one genuine circularity is the evaluation oracle: a custom oracle per known vulnerability turns the reported detection rate into a reachability check of manually encoded bug conditions.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 0 invented entities

No invented physical or semantic entities are introduced. The main hand-chosen elements are the per-vulnerability oracles (about 15 lines per vulnerability, Section 5) and the "Earning Profits" oracle (Section 4), which I treat as evaluation design choices rather than fitted parameters; they are scored under circularity and flagged in red_flags.

axioms (4)
  • domain assumption MoveVM's typing, object ownership, and ability rules are fully captured by the statically constructed type graph.
    Sections 3.3-3.4 assume that graph traces which are type-valid are runtime-executable; if any ability or ownership constraint is not modeled, generated transactions may be rejected by MoveVM.
  • domain assumption Transactions can be modeled as a sequence of function calls without control flow without loss of generality.
    Definition 3.2 makes this claim, but Aptos scripts are a superset of PTBs with arbitrary control flow, so the model excludes control-flow-bearing scripts.
  • ad hoc to paper The "Earning Profits" oracle is a valid vulnerability oracle: any increase in sender-owned coins during a generated transaction indicates an exploitable bug.
    Section 4 lists this oracle and asserts no coins are minted, but legitimate financial gains (swap profits, fee rewards) can also increase balances; the oracle is a heuristic used to find the Cetus/Nemo exploits.
  • ad hoc to paper The heuristic type substitution always finds a valid concrete instantiation for generic type parameters.
    Section 3.4 Step 2 assumes types are usually fewer than 10 and does not prove completeness or that all ability constraints are respected for every chosen instantiation.

reviewed 2026-08-03 · how reviews work

0 comments
Cite this review

Pith. "Pith review of Belobog: Move Language Fuzzing Framework For Real-World Smart Contracts." pith.science (2026). https://pith.science/paper/RZVY6HXZ

@misc{pith2026251202918,
  author       = {Pith},
  title        = {Pith review of: Belobog: Move Language Fuzzing Framework For Real-World Smart Contracts},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RZVY6HXZ}},
  note         = {Machine review of arXiv:2512.02918}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

Move is a resource-oriented programming language designed for secure and verifiable smart contract development and has been widely used in managing billions of digital assets in blockchains, such as Sui and Aptos.Move features a strong static type system and explicit resource semantics to enforce safety properties such as the prevention of data races, invalid asset transfers, and entry vulnerabilities. However, smart contracts written in Move may still contain certain vulnerabilities that are beyond the reach of its type system. It is thus essential to validate Move smart contracts. Unfortunately, due to its strong type system, existing smart contract fuzzers are ineffective in producing syntactically or semantically valid transactions to test Move smart contracts. This paper introduces the first fuzzing framework, Belobog, for Move smart contracts. Belobog is type-aware and ensures that all generated and mutated transactions are well-typed. More specifically, for a target Move smart contract, Belobog first constructs a dependency graph based on Move's type system, and then generates or mutates a transaction based on the graph trace derived from the dependency graph. In order to overcome the complex checks in Move smart contracts, we further design and implement a concolic executor in Belobog. We evaluated Belobog on 109 real-world Move smart contract projects. The experimental results show that Belobog is able to detect 100% critical and 79% major vulnerabilities manually audited by human experts. We further selected two recent notorious incidents in the Move ecosystem, i.e., Cetus and Nemo. Belobog successfully reproduced full exploits for both of them, without any prior knowledge. Moreover, we applied Belobog on three ongoing auditing projects and found 2 critical, 2 major, and 3 medium new vulnerabilities, all acknowledged by the project developers.

Figures

Figures reproduced from arXiv: 2512.02918 by Liqun Yang, Pan Li, Shaohua Li, Wanxu Xia, Xiapu Luo, Yang Liu, Yi Lu, Zhengwei Li, Ziqiao Kong.

Figure 1
Figure 1. Figure 1: A constructed Move smart contract (left) and the built type graph for it (right). [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. Figure 3: Ratio of the packages having type parameters [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: A constructed Move smart contract (left) and the built type graph for it (right). [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Illustrative transaction generation starting from a graph trace (left), then concretizing type parameters [PITH_FULL_IMAGE:figures/full_fig_p008_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: A Precision Loss defect of the starswap-core-aptos project in DS2 [PITH_FULL_IMAGE:figures/full_fig_p013_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Edge coverage of Belobog and ItyFuzz on the projects from DS1 [PITH_FULL_IMAGE:figures/full_fig_p014_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: The simplified smart contract from the buggy [PITH_FULL_IMAGE:figures/full_fig_p015_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: A simplified code snippet of a real-world bug that allows anyone to drain pool rewards. [PITH_FULL_IMAGE:figures/full_fig_p017_9.png] view at source ↗

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

41 extracted references · 1 canonical work pages

  1. [1]

    ERC-20: Token Standard

    2015. ERC-20: Token Standard. https://eips.ethereum.org/EIPS/eip-20

    2015

  2. [2]

    Move Lint

    2021. Move Lint. https://github.com/BeosinBlockchainSecurity/Move-Lint

    2021

  3. [3]

    Solidity

    2021. Solidity. https://www.soliditylang.org/

    2021

  4. [4]

    Sui-Fuzzer

    2024. Sui-Fuzzer. https://github.com/FuzzingLabs/sui-fuzzer

    2024

  5. [5]

    Aptos Move

    2025. Aptos Move. https://aptos.dev/build/smart-contracts/book

    2025

  6. [6]

    2025. Artemis. https://app.artemisanalytics.com/chains. Accessed on 28 Jan, 2026

    2025

  7. [7]

    Cetus Incident Report: May 22, 2025 Attack Disclosure

    2025. Cetus Incident Report: May 22, 2025 Attack Disclosure. https://cetusprotocol.notion.site/Cetus-Incident-Report- May-22-2025-Attack-Disclosure-1ff1dbf3ac8680d7a98de6158597d416

    2025

  8. [8]

    2025. Foundry. https://github.com/foundry-rs/foundry

    2025

  9. [9]

    Move Subtyping

    2025. Move Subtyping. https://move-language.github.io/move/tuples.html

    2025

  10. [10]

    Nemo Security Incident: Cause, Process, and Fund Tracing Report V1.1

    2025. Nemo Security Incident: Cause, Process, and Fund Tracing Report V1.1. https://olivine-hydrofoil-637.notion. site/Nemo-Security-Incident-Cause-Process-and-Fund-Tracing-Report-V1-1-26a6b8723d8a80e29cb8cb48fe1390f2

    2025

  11. [11]

    Jaeseung Choi, Doyeon Kim, Soomin Kim, Gustavo Grieco, Alex Groce, and Sang Kil Cha. 2021. Smartian: Enhancing smart contract fuzzing with static and dynamic data-flow analyses. In2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 227–239. doi:10.1109/ASE51524.2021.9678888

    arXiv 2021

  12. [12]

    Yu Feng, Ruben Martins, Yuepeng Wang, Isil Dillig, and Thomas W Reps. 2017. Component-based synthesis for complex APIs. InProceedings of the 44th ACM SIGPLAN Symposium on Principles of Programming Languages. 599–612

    2017

  13. [13]

    Andrea Fioraldi, Dominik Christian Maier, Dongjia Zhang, and Davide Balzarotti. 2022. LibAFL: A Framework to Build Modular and Reusable Fuzzers. InProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security(Los Angeles CA USA, 2022-11-07). ACM, 1051–1065. doi:10.1145/3548606.3560602

    arXiv 2022

  14. [14]

    Harrison Green and Thanassis Avgerinos. 2022. Graphfuzz: Library api fuzzing with lifetime-aware dataflow graphs. InProceedings of the 44th International Conference on Software Engineering. 1070–1081

    2022

  15. [15]

    Gustavo Grieco, Will Song, Artur Cygan, Josselin Feist, and Alex Groce. 2020. Echidna: effective, usable, and fast fuzzing for smart contracts. InProceedings of the 29th ACM SIGSOFT international symposium on software testing and analysis. 557–560

    2020

  16. [16]

    Timotej Kapus and Cristian Cadar. 2019. A segmented memory model for symbolic execution. InProceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering(Tallinn, Estonia)(ESEC/FSE 2019). Association for Computing Machinery, New York, NY, USA, 774–784. doi:10.1145/3338906...

    arXiv 2019

  17. [17]

    Ziqiao Kong, Cen Zhang, Maoyi Xie, Ming Hu, Yue Xue, Ye Liu, Haijun Wang, and Yang Liu. 2025. Smart Contract Fuzzing Towards Profitable Vulnerabilities.Proceedings of the ACM on Software Engineering2, FSE (2025), 153–175

    2025

  18. [18]

    Zihao Li, Jianfeng Li, Zheyuan He, Xiapu Luo, Ting Wang, Xiaoze Ni, Wenwu Yang, Xi Chen, and Ting Chen. 2023. Demystifying DeFi MEV Activities in Flashbots Bundle. Cryptology ePrint Archive, Paper 2023/1855. doi:10.1145/ 3576915.3616590

    arXiv 2023

  19. [19]

    Ruichao Liang, Jing Chen, Cong Wu, Kun He, Yueming Wu, Ruochen Cao, Ruiying Du, Ziming Zhao, and Yang Liu. 2025. Vulseye: Detect smart contract vulnerabilities via stateful directed graybox fuzzing.IEEE Transactions on Information Forensics and Security(2025)

    2025

  20. [20]

    David Mandelin, Lin Xu, Rastislav Bodík, and Doug Kimelman. 2005. Jungloid mining: helping to navigate the API jungle. InProceedings of the 2005 ACM SIGPLAN Conference on Programming Language Design and Implementation(Chicago, IL, USA)(PLDI ’05). Association for Computing Machinery, New York, NY, USA, 48–61. doi:10.1145/1065010.1065018

    arXiv 2005

  21. [21]

    Tai D Nguyen, Long H Pham, Jun Sun, Yun Lin, and Quang Tran Minh. 2020. sfuzz: An efficient adaptive fuzzer for solidity smart contracts. InProceedings of the ACM/IEEE 42nd International Conference on Software Engineering. 778–788. doi:10.1145/3377811.3380334

    arXiv 2020

  22. [22]

    Kaihua Qin, Liyi Zhou, Benjamin Livshits, and Arthur Gervais. 2021. Attacking the defi ecosystem with flash loans for fun and profit. InInternational conference on financial cryptography and data security. Springer, 3–32

    2021

  23. [23]

    Gabriel Sherman and Stefan Nagy. 2025. No Harness, No Problem: Oracle-guided Harnessing for Auto-generating C API Fuzzing Harnesses. In2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE Computer Society, 775–775

    2025

  24. [24]

    Chaofan Shou, Jing Liu, Doudou Lu, and Koushik Sen. 2024. Llm4fuzz: Guided fuzzing of smart contracts with large language models.arXiv preprint arXiv:2401.11108(2024)

    Pith/arXiv arXiv 2024

  25. [25]

    Chaofan Shou, Shangyin Tan, and Koushik Sen. 2023. ItyFuzz: Snapshot-Based Fuzzer for Smart Contract. InProceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis(Seattle WA USA, 2023-07-12). ACM, 322–333. doi:10.1145/3597926.3598059

    arXiv 2023

  26. [26]

    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, 2024-09-1...

    arXiv 2024

  27. [27]

    Thodoris Sotiropoulos, Stefanos Chaliasos, and Zhendong Su. 2024. API-Driven Program Synthesis for Testing Static Typing Implementations.Proc. ACM Program. Lang.8, POPL, Article 62 (Jan. 2024), 32 pages. doi:10.1145/3632904

    work page doi:10.1145/3632904 2024

  28. [28]

    Christof Ferreira Torres, Antonio Ken Iannillo, Arthur Gervais, and Radu State. 2021. Confuzzius: A data dependency- aware hybrid fuzzer for smart contracts. In2021 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 103–119. doi:10.1109/EuroSP51992.2021.00018

    arXiv 2021

  29. [29]

    Adam Welc and Sam Blackshear. 2023. Sui move: Modern blockchain programming with objects. InCompanion Proceedings of the 2023 ACM SIGPLAN International Conference on Systems, Programming, Languages, and Applications: Software for Humanity. 53–55

    2023

  30. [30]

    Dr Gavin Wood. 2024. ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER SHANG- HAI VERSION. https://ethereum.github.io/yellowpaper/paper.pdf. (2024)

    2024

  31. [31]

    Cong Wu, Jing Chen, Ziwei Wang, Ruichao Liang, and Ruiying Du. 2024. Semantic sleuth: Identifying ponzi contracts via large language models. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering. 582–593

    2024

  32. [32]

    Siwei Wu, Zhou Yu, Dabao Wang, Yajin Zhou, Lei Wu, Haoyu Wang, and Xingliang Yuan. 2023. Defiranger: Detecting defi price manipulation attacks.IEEE Transactions on Dependable and Secure Computing21, 4 (2023), 4147–4161

    2023

  33. [33]

    Maoyi Xie, Ming Hu, Ziqiao Kong, Cen Zhang, Yebo Feng, Haijun Wang, Yue Xue, Hao Zhang, Ye Liu, and Yang Liu

  34. [34]

    Zhiwu Xu, Bohao Wu, Cheng Wen, Bin Zhang, Shengchao Qin, and Mengda He. 2024. RPG: Rust library fuzzing with pool-based fuzz target generation and generic support. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering. 1–13

    2024

  35. [35]

    Yishun Zeng, Yue Wu, and Chao Zhang. [n. d.]. TypeNFuzz: Dynamic Type-aware Object Dependence Graph Guided Fuzzing for JavaScript Library Bug Discovery.ACM Transactions on Software Engineering and Methodology([n. d.])

  36. [36]

    2021.{APICraft}: Fuzz driver generation for closed-source{SDK} libraries

    Cen Zhang, Xingwei Lin, Yuekang Li, Yinxing Xue, Jundong Xie, Hongxu Chen, Xinlei Ying, Jiashui Wang, and Yang Liu. 2021.{APICraft}: Fuzz driver generation for closed-source{SDK} libraries. In30th USENIX Security Symposium (USENIX Security 21). 2811–2828

    2021

  37. [37]

    Yehong Zhang, Jun Wu, and Hui Xu. 2025. Rumono: Fuzz driver synthesis for rust generic apis.ACM Transactions on Software Engineering and Methodology34, 6 (2025), 1–28. Belobog: Move Language Fuzzing Framework For Real-World Smart Contracts 21

    2025

  38. [38]

    Jingyi Emma Zhong, Kevin Cheang, Shaz Qadeer, Wolfgang Grieskamp, Sam Blackshear, Junkil Park, Yoni Zohar, Clark Barrett, and David L. Dill. 2020. The Move Prover. InComputer Aided Verification, Shuvendu K. Lahiri and Chao Wang (Eds.). Vol. 12224. Springer International Publishing, 137–150. doi:10.1007/978-3-030-53288-8_7 Series Title: Lecture Notes in Co...

    doi:10.1007/978-3-030-53288-8_7 2020

  39. [39]

    Chijin Zhou, Quan Zhang, Mingzhe Wang, Lihua Guo, Jie Liang, Zhe Liu, Mathias Payer, and Yu Jiang. 2022. Minerva: browser API fuzzing with dynamic mod-ref analysis. InProceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 1135–1147

    2022

  40. [40]

    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. doi:10.1145/3558535.3559780 Received 20 February 2007; revised 12 March 2009; accepted 5 June 2009

    arXiv 2023

  41. [2024]

    InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis(Vienna, Austria)(ISSTA 2024)

    DeFort: Automatic Detection and Analysis of Price Manipulation Attacks in DeFi Applications. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis(Vienna, Austria)(ISSTA 2024). Association for Computing Machinery, New York, NY, USA, 402–414. doi:10.1145/3650212.3652137

    arXiv 2024

This paper was first reviewed by deepseek-v4-flash on August 3, 2026.