Pith. sign in

REVIEW 4 major objections 6 minor 63 references

Mutation Testing for Ethereum Smart Contract

T0 review · 4 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

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

Pith's one-line read Mutation testing, applied to Ethereum smart contracts through fifteen Solidity-specific mutation operators, evaluates test-suite adequacy more effectively than line or branch coverage, retaining 96.01% of defect detection versus 55.68%…

desk verdict A solid operator-design and empirical-study paper whose headline metric is a mutation-score retention ratio, not a real defect detection rate; worth refereeing but needs re-labeling and artifacts. read the letter →

arxiv 1908.03707 v1 pith:KI3PVL4B submitted 2019-08-10 cs.SE

Haoran Wu , Xingya Wang , Jiehui Xu , Weiqin Zou , Lingming Zhang , Zhenyu Chen This is my paper · ORCID
classification cs.SE
keywords mutationtestingEthereumsmartcontractSolidityoperatorstestadequacyequivalentmutantscoverage-basedsecurity
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

Smart contracts on Ethereum manage digital assets and cannot be repaired after deployment, so tests must be strong before release. This paper argues that mutation testing—seeding small artificial faults into contracts and checking whether tests detect them—judges test-suite adequacy for Ethereum smart contracts better than line or branch coverage. The authors built an abstract-syntax-tree-based mutation framework for Solidity, added fifteen operators tailored to Ethereum-specific language features such as visibility keywords, ether and time units, global variables, and require/assert handling, and report that test subsets chosen to match the full suite's mutation score retain 96.01% of its defect detection, while subsets chosen to match its coverage retain only 55.68%. They also report that 117 of 729 real-world bug reports map to their new operators, evidence that the seeded faults resemble authentic smart-contract defects.

What carries the argument

The central mechanism is a set of 25 mutation operators applied at the abstract-syntax-tree level: ten general operators adapted from JavaScript mutation testing, plus fifteen new Solidity-specific operators in four families—keyword changes, global variable and function changes, variable unit changes, and error-handling changes. The engine parses each contract into an AST, creates one mutant per faulty rewrite, builds a fresh Ethereum testnet for every mutant so that blockchain state does not affect results, compiles and deploys each mutant, executes the test suite, and computes the mutation score as $\frac{\text{non-equivalent mutants} - \text{surviving mutants}}{\text{non-equivalent mutants}} \times 100\%$. This score is the adequacy measure that the paper claims predicts defect detection better than coverage.

What would settle it

Have two independent teams manually classify all 2,032 generated mutants as equivalent or non-equivalent and recompute the scores; if their classifications disagree substantially or the reclassification changes which test-selection method scores higher on the verification set, the reported advantage is an artifact of the equivalence filter.

Watch

Extended reading notes

Core claim

On its own terms, the paper establishes that mutation testing can serve as a stronger adequacy criterion than coverage for Ethereum smart contracts: a test suite is adequate insofar as it kills non-equivalent mutants. In paired comparisons across 26 contracts from four DApps, test subsets selected to preserve the original suite's mutation score killed 96.01% of the mutants in a held-out verification set, whereas test subsets selected to preserve the original suite's line and branch coverage killed only 55.68%. The paper further claims that the fifteen Solidity-specific mutation operators are effective: they generate non-equivalent mutants at rates comparable to general operators and 117 of 729 collected bug reports correspond to the operator categories. The authors conclude that mutation testing's extra cost is acceptable for Ethereum because deployed contracts are immutable, making pre-deployment adequacy evaluation the only practical safety net.

Load-bearing premise

The load-bearing premise is that the manual identification of equivalent mutants is correct, because every mutation score—including the 96.01% versus 55.68% comparison—is computed after excluding those mutants, and the authors state they cannot ensure all equivalent mutants were excluded.

Editorial extensions

If this is right

  • Smart-contract test suites should be judged by mutation score rather than by line or branch coverage if the 96.01% versus 55.68% result holds beyond the four studied DApps.
  • The fifteen operators give testers a concrete checklist of Solidity-specific weakness classes, including visibility mistakes, data-location errors, unit conversions, and unchecked require/assert paths.
  • Mutation testing becomes an affordable pre-deployment practice for Ethereum because contracts cannot be patched after deployment, so the cost of running mutants is paid before any irreversible transaction.
  • The low mutation scores on specific operators such as assert deletion (10.5) indicate that current DApp test suites rarely exercise failing-assert paths, a concrete gap in test quality.

Reading between the lines

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

  • If the mapping of 117 bug reports to the fifteen operators is stable, mutation scores could double as a prioritization signal for security audits: contracts whose mutants resemble known vulnerability patterns would be flagged for manual review first.
  • Because the Solidity-specific operators have a lower average mutation score than general operators (35.2 versus 42.6), automated test generators that target these operator classes are likely to raise defect detection more than coverage-guided fuzzing would.
  • The per-mutant testnet construction is the main scalability bottleneck; replacing it with in-process EVM execution or parallelized testnet creation would make mutation testing practical for continuous integration, an engineering extension the paper does not explore.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. The paper proposes a mutation testing framework for Ethereum smart contracts (ESCs), introducing 15 Solidity-specific mutation operators alongside a set of general JavaScript-derived operators. The framework mutates the contract's AST, deploys each mutant on a fresh testnet, executes the given test suite, and computes mutation scores. An empirical study on 26 smart contracts from four DApps compares mutation-based test adequacy with coverage-based adequacy: the authors randomly split the useful mutants into a training set M1 and a held-out set M2, then select a coverage-equivalent subset (T_SCov) and a mutation-score-equivalent subset (T_S^M1) of the original test suite, and evaluate both on M2. The paper reports that T_S^M1 retains 96.01% of the full suite's mutation score on M2 versus 55.68% for T_SCov, and a separate manual survey of 729 bug reports finds 117 reports that the authors map to their proposed operators.

Significance. The work is a timely contribution to smart contract testing: it provides one of the first systematic mutation testing tools for Solidity, a set of domain-specific mutation operators, and an evaluation protocol that uses random splits, ten independent runs, and a paired Wilcoxon test. The held-out mutant design is a sound approach for comparing test adequacy criteria, and the mutant generation statistics give useful empirical data about Solidity-specific fault types. However, the headline claim that mutation testing outperforms coverage on 'defect detection rate' is not supported by the measured metric, which is mutant-kill retention relative to the full suite, not detection of real defects. The operator-effectiveness survey is also potentially circular because the operators and the bug-report classification share the same design sources. With appropriate re-framing and additional controls, the contribution could be valuable to the smart contract and mutation testing communities.

major comments (4)
  1. [Abstract and Section 5.3.2] The abstract and RQ1 state that the approach 'outperform[s] the coverage-based approach on defect detection rate (96.01% vs. 55.68%)'. However, these numbers are computed in Section 5.3.2 as MS2(T_S^M1)/MS2(T_S) and MS2(T_SCov)/MS2(T_S) using Table 19, where MS2 is the mutation score on the held-out mutant set M2. This is a ratio of mutant-killing ability relative to the full test suite, not a detection rate of real defects. Experiment 1 does not inject or measure real faults. The claim should be reworded to 'mutant detection retention' or 'mutation score retention'; as written, the headline overstates the result's external validity.
  2. [Section 5.3.1] The comparison between T_SCov and T_S^M1 does not control for test suite size. T_SCov is a random subset of T_S that satisfies the same line and branch coverage as T_S, while T_S^M1 is a random subset with the same mutation score on M1. The paper does not report the number of tests in either subset. If T_S^M1 contains substantially more tests, the higher held-out mutation score may reflect additional test effort rather than the superiority of the mutation criterion. To support the 'outperform' conclusion, the authors should report subset sizes and, ideally, include an effort-controlled comparison (e.g., equal-size subsets) or cost-effectiveness curves.
  3. [Section 4 and Section 5.4] The operators in Section 4 are designed by consulting Solidity documentation, GitHub issues, and Stack Exchange (stated at the start of Section 4). Experiment 2 then collects 729 bug reports from GitHub, DASP, and PeckShield and manually classifies them into the same operator categories, reporting that 117 are 'related to' the operators. This is not an independent validation: the classification categories are identical to the design sources, and the manual mapping is potentially biased by the authors' prior categorization. The claim that 'ESC mutation operators are effective to reveal real defects' is therefore not established by this survey. The authors should either provide an independent validation (e.g., checking whether the corresponding mutants are killed by the test suites) or substantially weaken the claim.
  4. [Section 6] Section 6 acknowledges that 'the identification of equivalent mutants is performed manually, so we can not ensure that all equivalent mutants are excluded.' This is load-bearing because all mutation scores and the 96.01% versus 55.68% ratios are computed after removing equivalent mutants (Section 5.3.1). Misclassification of equivalent mutants as non-equivalent, or vice versa, could change the reported scores and the comparison. The authors should quantify the sensitivity of the results to equivalent-mutant misclassification or use an automated equivalence detection method as a cross-check.
minor comments (6)
  1. [Section 5.3.1] The text says 'total of 25 mutation operators, of which 10 are general mutation operators' but Table 3 and Table 20 list nine general operators (AOR, AOI, ROR, COR, LOR, ASR, SDL, RVR, CSC). Please correct the count for consistency.
  2. [Table 15] In the RSD example, line s3 reads 'uint balanceBefore == this.balance;' which appears to be a typo for 'uint balanceBefore = this.balance;'.
  3. [Table 19] The table caption and column headers use MS1 and MS2 without defining them; please define MS1 and MS2 in the caption or in the text of Section 5.3.1.
  4. [Section 5.3.2] The Wilcoxon test result is reported as '0.005'; please state explicitly that this is the p-value, and report the number of paired observations or the test statistic.
  5. [Section 3 step (2)] The text says 'thirteen new ESC mutation operators' but Section 4.5 states 15; please correct the number.
  6. [Section 5.4.2] The sentence 'The 10 traditional mutation operators generate a total of 1451 mutants' should likely read 'nine' given the list in Table 20.

Circularity Check

1 steps flagged · score 4.0 of 10

Operator-effectiveness claim is partly circular: the 117/729 bug-report count reuses the defect taxonomy from which the operators were designed; the central mutation-vs-coverage comparison is independent but is mislabeled as 'defect detection rate'.

  1. self definitional [Section 4 (operator design) and Section 5.4.2 / Experiment 2 (operator effectiveness survey)]
    "We read the Solidity documentation and look over the issues related to smart contracts on GitHub and Stack Exchange to design the mutation operators for the specific defects that may be generated by smart contracts. ... Among 729 reports, 117 are related to our mutation operator, including 41 Keyword Operators bugs, 35 Global Variables and Functions Operators bugs, 9 Variable Unit Operators bugs and 32 Error Handling Operators bugs."

    The operators are defined from the same defect taxonomy that is later used to validate them. Section 4 says the mutation operators were designed by reading Solidity issues on GitHub and Stack Exchange. Experiment 2 then collects 729 defect reports from GitHub, DASP, and PeckShield and 'determined' each report into one of these operator types. The operator categories themselves were built from the same SWC/DASP-style defect classes (e.g., DLR maps to SWC-109, AVR/RSD/RSC to DASP#item-2), so classifying reports under those categories and counting matches is a re-application of the design taxonomy rather than an independent test of whether the mutants represent real faults. The 117/729 count is therefore partly a restatement of the design input, not an external confirmation.

full rationale

The central comparison in Experiment 1 is not circular: TSM1 is selected using the held-in mutant set M1, and its quality is evaluated on the held-out set M2; no parameter is fitted to M2, so the finding that TSM1 retains 96.01% of TS's mutation score on M2 while TSCov retains 55.68% is a genuine internal generalization. However, the abstract and RQ1 call this a 'defect detection rate,' which overstates the evidence: the measured quantities are mutation-score retention ratios, not rates of detecting real defects in the 26 subject contracts. The operator-effectiveness claim in Experiment 2 is more directly circular, as explained in the step above, because the operators were designed from the very defect-report categories used to count the 117 related reports. There is no load-bearing self-citation chain: reference [5] is from the same group but only explains why automated test generators were not used, and no uniqueness theorem or ansatz is smuggled in via citation. The manual equivalent-mutant identification is a validity threat, not a circularity. Overall, the paper contains one partly self-definitional evaluation, while the main mutation-versus-coverage result has independent content; the headline metric is mislabeled but not circular by construction.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claims rest on standard mutation testing hypotheses from prior literature and on manual classifications that are not independently verifiable from the paper. No free parameters are fit; the empirical comparison uses random splits and manual equivalence detection.

assumptions (4)
  • domain assumption Competent programmer hypothesis: real faults are small syntactic deviations from correct code.
    Section 7.1 cites DeMillo et al. [52]; used to justify that small syntactic mutations simulate real programmer errors.
  • domain assumption Coupling effect hypothesis: complex faults are coupled with simple faults, so test suites that detect simple mutants will detect complex faults.
    Section 7.1 cites Offutt [54]; used to justify mutation testing as a proxy for real fault detection.
  • domain assumption Mutants are representative of real faults in the studied context.
    Section 7.1 cites Andrews et al. [24] and Do et al. [59]; the paper's own bug-report survey in Section 5.4 attempts to support this but relies on manual classification.
  • domain assumption The four selected DApps and their test suites are representative of real-world Ethereum smart contracts.
    Section 5.2 describes subject selection; Section 6 acknowledges external validity cannot be guaranteed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Mutation Testing for Ethereum Smart Contract." pith.science (2026). https://pith.science/paper/KI3PVL4B

@misc{pith2026190803707,
  author       = {Pith},
  title        = {Pith review of: Mutation Testing for Ethereum Smart Contract},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KI3PVL4B}},
  note         = {Machine review of arXiv:1908.03707}
}
read the original abstract

Smart contract is a special program that manages digital assets on blockchain. It is difficult to recover the loss if users make transactions through buggy smart contracts, which cannot be directly fixed. Hence, it is important to ensure the correctness of smart contracts before deploying them. This paper proposes a systematic framework to mutation testing for smart contracts on Ethereum, which is currently the most popular open blockchain for deploying and running smart contracts. Fifteen novel mutation operators have been designed for Ethereum Smart Contracts (ESC), in terms of keyword, global variable/function, variable unit, and error handling. An empirical study on 26 smart contracts in four Ethereum DApps has been conducted to evaluate the effectiveness of mutation testing. The experimental results show that our approach can outperform the coverage-based approach on defect detection rate (96.01% vs. 55.68%). The ESC mutation operators are effective to reveal real defects and we found 117 out of 729 real bug reports are related to our operators. These show the great potential of using mutation testing for quality assurance of ESC.

Figures

Figures reproduced from arXiv: 1908.03707 by the authors.

Figure 1
Figure 1. ESC Deployment and Execution Ethereum users rely on accounts to carry out transac￾tions. There are two types of accounts, External Account (EA) and Contract Account (CA), in Ethereum. The for￾mer is controlled by the users with private keys, and the latter is controlled by ESC code [20]. Both EA and CA record the state information such as account balance, and CA has an additional unchanged field, codeHash, which poi… view at source ↗
Figure 2
Figure 2. Performing Mutation Analysis on Smart Contracts [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

63 extracted references · 61 canonical work pages

  1. [1]

    Blockchain challenges and opportunities: A survey,

    Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang, “Blockchain challenges and opportunities: A survey,” International Journal of Web and Grid Services, vol. 14, no. 4, pp. 352–375, 2018

    work page 2018

  2. [2]

    Bitcoin: A peer-to-peer electronic cash system,

    S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008

    2008

  3. [3]

    Making smart contracts smarter,

    L. Luu, D.-H. Chu, H. Olickel, P . Saxena, and A. Hobor, “Making smart contracts smarter,” in Proceedings of the 23rd ACM SIGSAC Conference on Computer and Communications Security (CCS) , 2016, pp. 254–269

    work page 2016

  4. [4]

    An empirical analysis of smart contracts: Platforms, applications, and design patterns,

    M. Bartoletti and L. Pompianu, “An empirical analysis of smart contracts: Platforms, applications, and design patterns,” in Pro- ceedings of the 21st International Conference on Financial Cryptography and Data Security (FC), 2017, pp. 494–509

    work page 2017

  5. [5]

    Towards generating cost- effective test-suite for Ethereum smart contract,

    X. Wang, H. Wu, W. Sun, and Y. Zhao, “Towards generating cost- effective test-suite for Ethereum smart contract,” in Proceedings of the 26th IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), Hangzhou, China, 2019, pp. 549–553

    work page 2019

  6. [6]

    Finding the greedy, prodigal, and suicidal contracts at scale,

    I. Nikoli ´c, A. Kolluri, I. Sergey, P . Saxena, and A. Hobor, “Finding the greedy, prodigal, and suicidal contracts at scale,” in Proceed- ings of the 34th Annual Computer Security Applications Conference (ACSAC), San Juan, PR, USA, 2018, pp. 653–663

    work page 2018

  7. [7]

    Blockchain technology: What is it good for?

    S. Ammous, “Blockchain technology: What is it good for?” 2016

    work page 2016

  8. [8]

    Software testing: A research travel- ogue (2000–2014),

    A. Orso and G. Rothermel, “Software testing: A research travel- ogue (2000–2014),” in Proceedings of the 2nd Workshop on Future of Software Engineering (FOSE), Hyderabad, India, 2014, pp. 117–132

    work page 2000

Show all 63 references
  1. [9]

    Assessment of C++ object-oriented mutation operators: A selective mutation approach,

    P . Delgado-P ´erez, S. Segura, and I. Medina-Bulo, “Assessment of C++ object-oriented mutation operators: A selective mutation approach,” Software Testing, Verification and Reliability , vol. 27, no. 4-5, p. e1630, 2017

    2017

  2. [10]

    Mutation testing advances: An analysis and survey,

    M. Papadakis, M. Kintis, J. Zhang, Y. Jia, Y. Le Traon, and M. Har- man, “Mutation testing advances: An analysis and survey,” in Advances in Computers, 2019, vol. 112, pp. 275–378

    2019

  3. [11]

    An empirical study on mutation, statement and branch coverage fault revelation that avoids the unreliable clean program assumption,

    T. T. Chekam, M. Papadakis, Y. Le Traon, and M. Harman, “An empirical study on mutation, statement and branch coverage fault revelation that avoids the unreliable clean program assumption,” in Proceedings of the 39th IEEE/ACM International Conference on Software Engineering (I...

    2017

  4. [12]

    Assessment of class mutation operators for C++ with the MuCPP mutation system,

    P . Delgado-P ´erez, I. Medina-Bulo, F. Palomo-Lozano, A. Garc ´ıa- Dom´ınguez, and J. J. Dom ´ınguez-Jim´enez, “Assessment of class mutation operators for C++ with the MuCPP mutation system,” Information and Software Technology, vol. 81, no. 2017, pp. 169–184, 2017

    2017

  5. [13]

    Pitest: State of the art mutation testing system for the jvm,

    “Pitest: State of the art mutation testing system for the jvm,” http: //pitest.org/, 2019

    2019

  6. [14]

    Efficient javascript mutation testing,

    S. Mirshokraie, A. Mesbah, and K. Pattabiraman, “Efficient javascript mutation testing,” in Proceedings of the 6th IEEE Inter- national Conference on Software Testing, Verification and Validation (ICST), Luxembourg, 2013, pp. 74–83

    2013

  7. [15]

    Inter-class mutation operators for Java,

    Y.-S. Ma, Y.-R. Kwon, and J. Offutt, “Inter-class mutation operators for Java,” in Proceedings of the 13th International Symposium on Software Reliability Engineering (ISSRE), 2002, pp. 352–363

    2002

  8. [16]

    MuCheck: An extensible tool for mutation testing of haskell programs,

    D. Le, M. A. Alipour, R. Gopinath, and A. Groce, “MuCheck: An extensible tool for mutation testing of haskell programs,” in Proceedings of the 23rd International Symposium on Software Testing and Analysis (ISSTA), 2014, pp. 429–432

    2014

  9. [17]

    An exploratory study of higher order mutation testing in aspect-oriented programming,

    E. Omar and S. Ghosh, “An exploratory study of higher order mutation testing in aspect-oriented programming,” in Proceedings of the 23rd IEEE International Symposium on Software Reliability Engineering (ISSRE), 2012, pp. 1–10

    2012

  10. [18]

    Smart contract languages,

    “Smart contract languages,” https://www.ethereum.org/build/, 2019

    2019

  11. [19]

    Smart contracts: Building blocks for digital markets,

    N. Szabo, “Smart contracts: Building blocks for digital markets,” 1996

    1996

  12. [20]

    Ethereum white paper: A next-generation smart con- tract and decentralized application platform,

    V . Buterin, “Ethereum white paper: A next-generation smart con- tract and decentralized application platform,” 2014

    2014

  13. [21]

    Ethereum: A secure decentralised generalised transac- tion ledger,

    G. Wood, “Ethereum: A secure decentralised generalised transac- tion ledger,” Ethereum project yellow paper, pp. 1–32, 2014

    2014

  14. [22]

    A measure of test case completeness (software, engineering),

    P . J. Walsh, “A measure of test case completeness (software, engineering),” 1985

    1985

  15. [23]

    All-uses vs mutation testing: An experimental comparison of effectiveness,

    P . G. Frankl, S. N. Weiss, and C. Hu, “All-uses vs mutation testing: An experimental comparison of effectiveness,” Journal of Systems and Software, vol. 38, no. 3, pp. 235–253, 1997

    1997

  16. [24]

    Is mutation an appropriate tool for testing experiments?

    J. H. Andrews, L. C. Briand, and Y. Labiche, “Is mutation an appropriate tool for testing experiments?” in Proceedings of the 27th International Conference on Software Engineering (ICSE) , St. Louis, Missouri, USA, 2005, pp. 402–411

    2005

  17. [25]

    Are mutants a valid substitute for real faults in software testing?

    R. Just, D. Jalali, L. Inozemtseva, M. D. Ernst, R. Holmes, and G. Fraser, “Are mutants a valid substitute for real faults in software testing?” in Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE) , 2014, pp. 654–665. 12

    2014

  18. [26]

    Mutation opera- tors for testing android apps,

    L. Deng, J. Offutt, P . Ammann, and N. Mirzaei, “Mutation opera- tors for testing android apps,” Information and Software Technology, vol. 81, pp. 154–168, 2017

    2017

  19. [27]

    Guided muta- tion testing for JavaScript Web applications,

    S. Mirshokraie, A. Mesbah, and K. Pattabiraman, “Guided muta- tion testing for JavaScript Web applications,” IEEE Transactions on Software Engineering, vol. 41, no. 5, pp. 429–444, 2015

    2015

  20. [28]

    solidity-parser-antlr,

    “solidity-parser-antlr,” https://github.com/federicobond/ solidity-parser-antlr, 2019

    2019

  21. [29]

    Introduce a real constant keyword and rename the cur- rent behaviour,

    “Introduce a real constant keyword and rename the cur- rent behaviour,” https://github.com/ethereum/solidity/issues/ 992, 2016

    2016

  22. [30]

    State variable default visibility,

    “State variable default visibility,” https://smartcontractsecurity. github.io/SWC-registry/docs/SWC-108, 2019

    2019

  23. [31]

    MuJava: An automated class mutation system,

    Y.-S. Ma, J. Offutt, and Y. R. Kwon, “MuJava: An automated class mutation system,” Software Testing, Verification and Reliability, vol. 15, no. 2, pp. 97–133, 2005

    2005

  24. [32]

    Solidity data location,

    “Solidity data location,” https://solidity.readthedocs.io/en/v0.5. 8/types.html#data-location, 2019

    2019

  25. [33]

    Uninitialized storage pointer,

    “Uninitialized storage pointer,” https://smartcontractsecurity. github.io/SWC-registry/docs/SWC-109, 2019

    2019

  26. [34]

    Alert: New batchoverflow bug in multiple erc20 smart contracts,

    “Alert: New batchoverflow bug in multiple erc20 smart contracts,” https://blog.peckshield.com/2018/04/22/batchOverflow/, 2018

    2018

  27. [35]

    Special variables and functions,

    “Special variables and functions,” https://solidity. readthedocs.io/en/v0.5.8/units-and-global-variables.html# special-variables-and-functions, 2019

    2019

  28. [36]

    Solidity mathematical and cryptographic functions,

    “Solidity mathematical and cryptographic functions,” https: //solidity.readthedocs.io/en/v0.5.8/units-and-global-variables. html#mathematical-and-cryptographic-functions, 2019

    2019

  29. [37]

    Solidity ether units,

    “Solidity ether units,” https://solidity.readthedocs.io/en/v0.5.8/ units-and-global-variables.html#ether-units, 2019

    2019

  30. [38]

    Solidity time units,

    “Solidity time units,” https://solidity.readthedocs.io/en/v0.5.8/ units-and-global-variables.html#time-units, 2019

    2019

  31. [39]

    Solidity error handling: Assert, require, revert and exceptions,

    “Solidity error handling: Assert, require, revert and exceptions,” https://solidity.readthedocs.io/en/v0.5.8/control-structures. html#error-handling-assert-require-revert-and-exceptions, 2019

    2019

  32. [40]

    Skincoin,

    “Skincoin,” http://www.britchicks.com/, 2019

    2019

  33. [41]

    Smartidentity,

    “Smartidentity,” http://www.deloitte.co.uk/smartid/, 2019

    2019

  34. [42]

    Airswap,

    “Airswap,” https://www.airswap.io/, 2019

    2019

  35. [43]

    Cryptofin,

    “Cryptofin,” https://cryptofinlabs.github.io/cryptofin-solidity/, 2019

    2019

  36. [44]

    Contractfuzzer: Fuzzing smart contracts for vulnerability detection,

    B. Jiang, Y. Liu, and W. Chan, “Contractfuzzer: Fuzzing smart contracts for vulnerability detection,” in Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineer- ing (ASE), 2018, pp. 259–269

    2018

  37. [45]

    Examples of solidity security issues,

    “Examples of solidity security issues,” https://github.com/ crytic/not-so-smart-contracts, 2019

    2019

  38. [46]

    Smart contract weakness classification and test cases,

    “Smart contract weakness classification and test cases,” https:// smartcontractsecurity.github.io/SWC-registry/, 2019

    2019

  39. [47]

    Uscc-submissions-2017,

    “Uscc-submissions-2017,” https://github.com/Arachnid/uscc/ tree/master/submissions-2017, 2019

    2017

  40. [48]

    Ethereum-solidity-issues,

    “Ethereum-solidity-issues,” https://github.com/ethereum/ solidity/issues, 2019

    2019

  41. [49]

    Ethereum-goethereum-issues,

    “Ethereum-goethereum-issues,” https://github.com/ethereum/ go-ethereum/issues, 2019

    2019

  42. [50]

    Decentralized application security project,

    “Decentralized application security project,” http://www.dasp. co/#item-1, 2019

    2019

  43. [51]

    Peckshield,

    “Peckshield,” https://blog.peckshield.com/, 2019

    2019

  44. [52]

    Hints on test data selection: Help for the practicing programmer,

    R. A. DeMillo, R. J. Lipton, and F. G. Sayward, “Hints on test data selection: Help for the practicing programmer,” Computer, vol. 11, no. 4, pp. 34–41, 1978

    1978

  45. [53]

    Mutation testing for the new century,

    A. J. Offutt and R. H. Untch, “Mutation testing for the new century,” 2001, ch. Mutation 2000: Uniting the orthogonal, pp. 34– 44

    2001

  46. [54]

    Investigations of the software testing coupling ef- fect,

    A. J. Offutt, “Investigations of the software testing coupling ef- fect,” ACM Transactions on Software Engineering and Methodology , vol. 1, no. 1, pp. 5–20, 1992

    1992

  47. [55]

    Object-oriented mutation ap- plied in common intermediate language programs originated from C#,

    A. Derezinska and K. Kowalski, “Object-oriented mutation ap- plied in common intermediate language programs originated from C#,” in Proceedings of the 4th IEEE International Conference on Soft- ware Testing, Verification and Validation Workshops (ICSTW) , 2011, pp. 342–350

    2011

  48. [56]

    Mutation testing in practice using Ruby,

    N. Li, M. West, A. Escalona, and V . H. Durelli, “Mutation testing in practice using Ruby,” in Proceedings of the 8th IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW), 2015, pp. 1–6

    2015

  49. [57]

    Applying mutation testing to Web applications,

    U. Praphamontripong and J. Offutt, “Applying mutation testing to Web applications,” in Proceedings of the 3rd International Conference on Software Testing, Verification, and Validation Workshops (ICSTW) , 2010, pp. 132–141

    2010

  50. [58]

    Mutating database queries,

    J. Tuya, M. J. Su ´arez-Cabal, and C. De La Riva, “Mutating database queries,” Information and Software Technology, vol. 49, no. 4, pp. 398– 417, 2007

    2007

  51. [59]

    On the use of mutation faults in empirical assessments of test case prioritization techniques,

    H. Do and G. Rothermel, “On the use of mutation faults in empirical assessments of test case prioritization techniques,” IEEE Transactions on Software Engineering , vol. 32, no. 9, pp. 733–752, 2006

    2006

  52. [60]

    Rethinking blockchain security: Position paper,

    V . Chia, P . Hartel, Q. Hum, S. Ma, G. Piliouras, D. Reijsbergen, M. van Staalduinen, and P . Szalachowski, “Rethinking blockchain security: Position paper,” arXiv, 2018

    2018

  53. [61]

    Mutation testing support for solidity,

    “Mutation testing support for solidity,” https://github.com/ ethereum/solidity/issues/1172, 2016

    2016

  54. [62]

    A mutation testing tool for solidity contracts,

    “A mutation testing tool for solidity contracts,” https://github. com/federicobond/eth-mutants, 2018

    2018

  55. [63]

    An extensible, regular-expression-based tool for multi-language mu- tant generation,

    A. Groce, J. Holmes, D. Marinov, A. Shi, and L. Zhang, “An extensible, regular-expression-based tool for multi-language mu- tant generation,” in Proceedings of the 40th IEEE/ACM International Conference on Software Engineering: Companion (ICSE-Companion) , 2018, pp. 25–28

    2018

Pith tools

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