Pith. sign in

REVIEW 5 major objections 6 minor 33 references

Micro-Patterns in Solidity Code

T0 review · 5 major / 6 minor · reviewed 2026-08-16 · deepseek-v4-flash

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

Pith's one-line read A catalog of 18 Solidity micro-patterns, defined in first-order logic and automatically detectable, appears in 99% of smart contracts across five blockchains.

desk verdict A useful first catalog of Solidity micro-patterns, but the headline prevalence numbers are not trustworthy because of vacuous pattern matching and missing artifacts. read the letter →

arxiv 2505.01282 v1 pith:RB43UG3Z submitted 2025-05-02 cs.SE cs.PL

Luca Ruschioni , Robert Shuttleworth , Rumyana Neykova , Barbara Re , Giuseppe Destefanis This is my paper · ORCID
classification cs.SEcs.PL
keywords micro-patternsSoliditysmartcontractsstaticanalysisfirst-orderlogicblockchainpatterndetectionempiricalstudy
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

Micro-patterns are small, recurring design structures that capture intentional coding choices. The paper adapts this idea from object-oriented languages to Solidity, the dominant smart-contract language, and defines a catalog of 18 patterns in five categories: Security, Functional, Optimization, Interaction, and Feedback. Each pattern is given a first-order logic specification so a static-analysis tool can detect it mechanically. Applying that tool to 23,258 verified contracts from Ethereum, Polygon, Arbitrum, Fantom, and Optimism, the paper finds that 99% of contracts exhibit at least one pattern, with an average of 2.76 per contract, and that the Storage Saver pattern alone covers 84.62% of eligible entities. A sympathetic reader would care because the catalog turns the largely unstructured practice of smart-contract development into a measurable vocabulary, enabling cross-platform comparison and future work on quality and security.

What carries the argument

The load-bearing machinery is the catalog of 18 micro-patterns, each given a formal definition in first-order logic. For example, Storage Saver is defined as $\forall v \in \text{stateVars}(C): \neg \text{wasteSpace}(v)$, meaning every state variable must be packed into a non-wasted storage slot. These formulas make detection mechanical and unambiguous, and the paper implements them as abstract-syntax-tree traversals on top of the Slither static-analysis library. Coverage and prevalence metrics summarize how often each pattern matches eligible entities, while the Phi coefficient quantifies pairwise correlation between patterns.

What would settle it

Manually inspect a random sample of contracts flagged as Storage Saver and compute the fraction that have zero state variables or that use unpacked storage layouts; if most Storage Saver matches are trivial or the detector misinterprets wasteSpace, the 84.62% coverage claim collapses.

Watch

Extended reading notes

Core claim

The paper claims that Solidity development can be characterized by a compact catalog of 18 micro-patterns—recurring structural and behavioral choices such as Ownable access control, Borrower library use, and Storage Saver variable packing. Using first-order logic definitions and an AST-based detector, it reports that 99% of contracts in its five-chain dataset implement at least one pattern, with an average of 2.76 patterns per contract. The Storage Saver pattern shows the highest coverage at 84.62% mean across chains, while security patterns like Reentrancy Guard (0.19%) and Pull Payment (0.15%) are rare but consistent. Statistical tests with Bonferroni correction identify significant platform-specific differences in Payable, Borrower, Delegator, Implementer, and Storage Saver adoption. Most pattern pairs are weakly correlated ($\phi < 0.15$ for over 115 pairs per chain), which the paper reads as evidence that the catalog captures independent, non-overlapping dimensions of contract design.

Load-bearing premise

The central claim rests on the assumption that the formal pattern definitions are interpreted correctly and non-vacuously by the detector; in particular, the Storage Saver definition depends on an undefined wasteSpace predicate, so entities with no state variables satisfy it trivially, and if the detector counts such trivial matches as real adoptions, the 84.62% and 99% figures are measurement artifacts rather than evidence of development practice.

Editorial extensions

If this is right

  • The catalog gives smart-contract researchers a fixed vocabulary: any contract can be summarized by its 18-bit pattern profile, and those profiles can be compared across chains, compiler versions, and time.
  • The near-universal adoption of Storage Saver indicates that gas-cost optimization is a default design consideration in verified contracts, not an optional refinement.
  • Security micro-patterns such as Reentrancy Guard and Pull Payment are rare (under 0.2% coverage), so if the catalog is right, most deployed contracts do not implement these specific protections, a point of concern for ecosystem security.
  • The predominantly weak correlations among patterns support the use of micro-patterns as independent features in downstream tasks like defect prediction or clone detection.
  • Significant cross-chain differences in Payable, Borrower, Delegator, Implementer, and Storage Saver suggest that blockchain platform characteristics shape development practices in ways this method can measure.

Reading between the lines

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

  • Inference: If the Storage Saver coverage is not a vacuous artifact, it implies that most contract authors or their templates already treat storage packing as mandatory, making the pattern more a platform constraint than a deliberate design choice; a study could distinguish these by checking whether Storage Saver correlates with contract age or compiler version.
  • Inference: The 18-bit pattern profile is a ready feature set for predicting contract vulnerability; because the patterns are nearly orthogonal, logistic regression on the profile could test whether pattern combinations predict reentrancy or access-control bugs, an experiment the paper does not run.
  • Inference: The cross-chain differences could serve as a signal of community norms; tracking how pattern adoption changes on a chain after major gas-price or compiler updates would give a quasi-experimental test of the claim that platform constraints shape development.
  • Inference: The five-category organization may be more editorial than empirical; clustering the 18 binary patterns across the dataset could reveal whether the categories reflect actual co-occurrence structure or whether a data-driven grouping differs.
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

5 major / 6 minor

Summary. This paper proposes a catalog of 18 micro-patterns for Solidity smart contracts, organized into five categories (Security, Functional, Optimization, Interaction, Feedback), with formal first-order logical definitions and an automated detection framework built on the Slither AST. The authors apply the detector to 23,258 verified contracts from five EVM blockchains (Ethereum, Polygon, Arbitrum, Fantom, Optimism) and report that 99% of entities exhibit at least one pattern with an average of 2.76 patterns per entity, that Storage Saver is the most widespread pattern (84.62% mean coverage), that several patterns differ significantly across chains, and that most pattern pairs are weakly correlated.

Significance. If the empirical claims were supported, this would be a valuable contribution: it adapts the established micro-pattern concept to a language with distinctive storage and security semantics, provides a reusable detection framework and replication package, and constitutes the first large-scale cross-chain characterization of Solidity design patterns. The strengths are the size and multi-chain nature of the dataset, the explicit FOL formalization, the cross-chain statistical analysis (with Bonferroni correction and effect-size thresholds), and the stated threats to validity. However, the central measurements currently rest on an under-specified predicate, potentially vacuous pattern matches, and an unvalidated detector, so the headline numbers cannot be accepted as evidence without substantial revision.

major comments (5)
  1. [Table 4, Figure 6, Table 3] Storage Saver is defined as ∀v∈stateVars(C): ¬wasteSpace(v), but wasteSpace is never defined algorithmically; the prose definition in Figure 6 ("True if v can be placed in a previously non-full slot") does not specify how storage slots are computed or what "previously non-full" means. Moreover, the formula is vacuously true for contracts with no state variables, and the paper does not report the proportion of eligible contract entities with at least one state variable. Because Storage Saver is the headline pattern (84.62% coverage, Table 3), the top-level empirical claim is not currently supported.
  2. [Section 4] The claimed 93% success rate is a compilation/processing rate, not a detection accuracy metric. The manuscript states that correctness was "validated through testing against known pattern examples" but gives no precision, recall, or F1 numbers, no manual validation set, and no comparison to a gold standard. Since the paper's findings are aggregate detection counts, the absence of any accuracy evaluation means the reported coverage and prevalence figures (Table 3) are uninterpretable.
  3. [Section 6.1 and Abstract] The paper conflates contracts and entities. The abstract and conclusion state that "99% of contracts" exhibit at least one pattern and that there are 2.76 patterns per contract, but Figure 3 and Section 6.1 define the analysis over entities, which include abstract contracts, interfaces, and libraries in addition to concrete contracts. Table 2 shows 361,807 entities derived from 23,258 deployed contracts, so the entity-level and contract-level statistics differ by more than an order of magnitude; the reported percentages and averages must be recomputed per deployed contract or reworded as per-entity metrics.
  4. [Section 6.2] The RQ3 claim of practically significant cross-platform differences is under-evidenced. The paper sets Cramer's V ≥ 0.10 as the threshold for practical significance, but the evaluation reports only selected chi-square statistics and p-values; it does not provide a table of Cramer's V for the five patterns and ten platform pairs. Without this, the reader cannot verify which differences meet the paper's own effect-size criterion.
  5. [Section 5.2 and Section 7] The sampling protocol for the 23,258 analyzed contracts is not reported precisely. Section 5.2 states that "we collected an adequate number of verified smart contracts per platform" and the threats section refers to "the most recent contracts per chain," but the selection rule (most recent by deployment time, random sample, etc.) and any exclusion criteria are not specified. The paper also does not assess whether the 1,742 contracts that failed processing differ systematically from the analyzed set, which leaves open the possibility of selection bias in all downstream statistics.
minor comments (6)
  1. [Table 4] Table 4 contains malformed quantifiers such as "∃,𝑚∈stateVars(𝐶)" and "∃,𝑓∈functions(𝐶)"; these appear to be typos that should be corrected.
  2. [Table 4] The Reentrancy Guard formula in Table 4 is written as "checksVar(𝑚,𝑣) ⇒ setVar(𝑚,𝑣) ⇒ execute(𝑓) ⇒ setVar(𝑚,𝑣)", which is not a well-formed FOL formula; the intended ordering of events should be expressed with a clearer formalism or explained in prose.
  3. [Table 3] Table 3's "Total Coverage (%)" row is not defined in the metrics of Figure 3; the paper should state whether it is the fraction of entities with at least one pattern.
  4. [Section 1 and Section 5.3] The link to the replication package appears as the placeholder text "replication packagelink" in the introduction and in Section 5.3; a working URL should be provided.
  5. [Abstract] The abstract refers to "Storage Optimization patterns" while the catalog names "Storage Saver"; the terminology should be made consistent.
  6. [Table 2] Table 2 lists counts such as "4.855" and "23.258" without specifying that they are in thousands; the units should be stated explicitly.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: prevalence results are measured from a separately collected dataset by an AST detector, not derived from the pattern definitions or from self-citations by construction.

full rationale

The paper's derivation chain is: define 18 micro-patterns in FOL (Table 4), implement a Slither-based AST detector (Section 4), collect verified contracts from five chains (Section 5), and count matches (Figure 3, Table 3). No fitted parameter is renamed as a prediction, and no first-principles result is invoked; the headline statistics are direct empirical counts. The 99% and 2.76 figures are not consequences of the FOL definitions alone, since the catalog is not constructed to guarantee a per-contract match and the paper reports many rare patterns (Reentrancy Guard mean 0.19%, Pull Payment 0.15%). The Section 3.1 iterative refinement process, in which patterns were pruned by observed frequency, is the only possible circularity, but the paper does not reduce the measured prevalence to that pruning: the evaluation uses a separately described verified-contract dataset, and no equation forces the reported coverage from the selection criterion. Self-citations [6] and [9] appear only in related work and do not carry the central argument. A distinct validity concern, not a circularity, is that universal patterns such as Storage Saver (∀v∈stateVars(C):¬wasteSpace(v)) are vacuously true for entities with no state variables; if such entities are in the eligible denominator, the 84.62% headline is inflated. That would be a measurement artifact, and the paper provides no stateless-entity fraction, so the figure is not shown to be forced by construction. Under the strict quote-and-reduction rule, no circular step is established.

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

The analysis rests on the correctness of the parser (Slither), the representativeness of verified contracts, and the author-defined pattern semantics. The most load-bearing assumption is that the patterns are non-vacuously implemented; because several patterns use universal quantification over state variables or functions, entities that lack these elements match by default, which can inflate coverage.

free parameters (2)
  • Cramer's V practical significance threshold = 0.10
    Chosen to flag practically significant platform differences; not derived from data, affects RQ3 conclusions.
  • Phi coefficient interpretation thresholds = 0.50 (moderate) and 0.15 (weak)
    Used to classify correlation strength in RQ4; these cutoffs are conventions from the behavioral sciences literature, not derived in this paper.
assumptions (3)
  • domain assumption Slither correctly parses Solidity code and resolves dependencies for compiler versions 0.4.x to 0.8.x.
    The entire detection pipeline relies on Slither's AST; the paper gives no independent accuracy check of the underlying parser.
  • domain assumption Verified contracts from blockchain explorers are representative of all smart contracts on those chains.
    The sample is drawn only from verified sources; Section 7 acknowledges that security-critical contracts may be underrepresented.
  • ad hoc to paper The FOL pattern definitions, including auxiliary predicates such as wasteSpace, implement the intended design concepts.
    The predicates are author-defined; wasteSpace is not defined in the paper, so the Storage Saver criterion is not fully specified.
invented entities (2)
  • 18 Solidity micro-patterns
    purpose: Taxonomy of recurring code structures for automated detection and empirical analysis.
    The catalog is author-defined and iteratively refined on the same type of data it measures; no external ground truth is available.
  • wasteSpace(v) predicate
    purpose: Core criterion for the Storage Saver pattern.
    Appears in the FOL definition (Table 4) but is never defined, so the most reported prevalence number is not reproducible.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Micro-Patterns in Solidity Code." pith.science (2026). https://pith.science/paper/RB43UG3Z

@misc{pith2026250501282,
  author       = {Pith},
  title        = {Pith review of: Micro-Patterns in Solidity Code},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RB43UG3Z}},
  note         = {Machine review of arXiv:2505.01282}
}
read the original abstract

Solidity is the predominant programming language for blockchain-based smart contracts, and its characteristics pose significant challenges for code analysis and maintenance. Traditional software analysis approaches, while effective for conventional programming languages, often fail to address Solidity-specific features such as gas optimization and security constraints. This paper introduces micro-patterns - recurring, small-scale design structures that capture key behavioral and structural peculiarities specific to a language - for Solidity language and demonstrates their value in understanding smart contract development practices. We identified 18 distinct micro-patterns organized in five categories (Security, Functional, Optimization, Interaction, and Feedback), detailing their characteristics to enable automated detection. To validate this proposal, we analyzed a dataset of 23258 smart contracts from five popular blockchains (Ethereum, Polygon, Arbitrum, Fantom and Optimism). Our analysis reveals widespread adoption of micro-patterns, with 99% of contracts implementing at least one pattern and an average of 2.76 patterns per contract. The Storage Saver pattern showed the highest adoption (84.62% mean coverage), while security patterns demonstrated platform-specific adoption rates. Statistical analysis revealed significant platform-specific differences in pattern adoption, particularly in Borrower, Implementer, and Storage Optimization patterns.

Figures

Figures reproduced from arXiv: 2505.01282 by the authors.

Figure 1
Figure 1. Micro-Pattern Detection Framework 3.2 Micro-Patterns Catalog After following the identification process, we defined 18 micro￾patterns reported in [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Data Collection Method modifiers, and external dependencies to ensure accurate results. Dependencies such as imported contracts and external libraries are automatically resolved and analyzed alongside the provided contracts, ensuring that all necessary components are available for micro-pattern detection. For each analyzed entity, the tool collects and outputs detailed information as in [PITH_FULL_IMAGE:figures/ful… view at source ↗
Figure 3
Figure 3. Analysis framework. Left: E captures entities (contracts, interfaces, libraries) from these projects, MP defines micro-patterns, ValidTypes maps patterns to applicable entity types, and M is the matching function. Right: Core metrics measure pattern occurrence (Frequency), adoption rate among eligible entities (Coverage), and relative dominance (Prevalence). contracts per blockchain. We chose to collect at least 400… view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Pattern relationships analysis showing: (a) highly correlated pattern pairs, (b) low correlation pattern pairs (excluding zero correlations), [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Cross-Chain Pattern similarity The findings suggested two key insights for smart contract de￾velopment. First, the widespread weak correlations (𝜙 < 0.15 for >115 micro-pattern pairs per platform) indicated that most micro￾patterns represent independent design choices …
Figure 6
Figure 6. Figure 6: Representative Subset of Auxiliary Functions and Predicates [PITH_FULL_IMAGE:figures/full_fig_p011_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

33 extracted references · 15 canonical work pages

  1. [1]

    2018.Mastering ethereum: building smart contracts and dapps

    Andreas M Antonopoulos and Gavin Wood. 2018.Mastering ethereum: building smart contracts and dapps. O’reilly Media

    work page 2018

  2. [2]

    Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli. 2017. A survey of at- tacks on ethereum smart contracts (sok). InPrinciples of Security and Trust: 6th International Conference, POST 2017, Held as Part of the European Joint Confer- ences on Theory and Practice of Software, ETAPS 2017, Uppsala, Sweden, April 22-29, 2017, Proceedings 6. Springer, Sprin...

    doi:10.1007/978-3-662-54455-6_8 2017

  3. [3]

    Huashan Chen, Marcus Pendleton, Laurent Njilla, and Shouhuai Xu. 2020. A survey on ethereum systems security: Vulnerabilities, attacks, and defenses.ACM Computing Surveys (CSUR)53, 3 (2020), 1–43. https://doi.org/10.1145/3391195

    doi:10.1145/3391195 2020

  4. [4]

    Zadia Codabux, Kazi Zakia Sultana, and Byron J Williams. 2017. The Relationship between Traceable Code Patterns and Code Smells. InSEKE. Knowledge Systems Institute Graduate School, 444–449. https://doi.org/10.18293/SEKE2017-121

    work page doi:10.18293/seke2017-121 2017

  5. [5]

    2013.Statistical power analysis for the behavioral sciences

    Jacob Cohen. 2013.Statistical power analysis for the behavioral sciences. Routledge. 567 pages. https://doi.org/10.4324/9780203771587

    doi:10.4324/9780203771587 2013

  6. [6]

    Giulio Concas, Giuseppe Destefanis, Michele Marchesi, Marco Ortu, and Roberto Tonelli. 2013. Micro patterns in agile software. InAgile Processes in Software Engineering and Extreme Programming: 14th International Conference, XP 2013, Vienna, Austria, June 3-7, 2013. Proceedings 14. Springer, 210–222. https://doi. org/10.1007/978-3-642-38314-4_15

    work page doi:10.1007/978-3-642-38314-4_15 2013

  7. [7]

    Chris Dannen and Chris Dannen. 2017. Solidity programming.Introducing Ethereum and Solidity: Foundations of Cryptocurrency and Blockchain Program- ming for Beginners(2017), 69–88. https://doi.org/10.1007/978-1-4842-2535-6_4

    work page doi:10.1007/978-1-4842-2535-6_4 2017

  8. [9]

    Giuseppe Destefanis, Roberto Tonelli, Ewan Tempero, Giulio Concas, and Michele Marchesi. 2012. Micro Pattern Fault-Proneness. In2012 38th Euromicro Conference on Software Engineering and Advanced Applications. IEEE, Cesme, Turkey, 302–

    work page 2012

Show all 33 references
  1. [10]

    Vikram Dhillon, David Metcalf, Max Hooper, Vikram Dhillon, David Metcalf, and Max Hooper. 2021. Unpacking ethereum.Blockchain Enabled Applications: Understand the Blockchain Ecosystem and How to Make it Work for You(2021), 37–72. https://doi.org/10.1007/978-1-4842-6534-5_4

    2021 doi

  2. [11]

    Thomas Durieux, João F Ferreira, Rui Abreu, and Pedro Cruz. 2020. Empir- ical review of automated analysis tools on 47,587 ethereum smart contracts. InProceedings of the ACM/IEEE 42nd International conference on software engi- neering. Association for Computing Machinery, New ...

    2020

  3. [12]

    Josselin Feist, Gustavo Grieco, and Alex Groce. 2019. Slither: A Static Analysis Framework for Smart Contracts. In2019 IEEE/ACM 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB). IEEE, Montreal, QC, Canada, 8–15. https://doi.org/10.1...

    2019

  4. [13]

    Norman E Fenton and Martin Neil. 1999. Software metrics: successes, failures and new directions.Journal of Systems and Software47, 2-3 (1999), 149–157. https://doi.org/10.1016/S0164-1212(99)00035-7

    1999 doi

  5. [14]

    Asem Ghaleb and Karthik Pattabiraman. 2020. How effective are smart contract analysis tools? evaluating smart contract static analysis tools using bug injection. InProceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis. Association for Com...

    2020

  6. [15]

    Joseph (Yossi) Gil and Itay Maman. 2005. Micro patterns in Java code. InPro- ceedings of the 20th Annual ACM SIGPLAN Conference on Object-Oriented Pro- gramming, Systems, Languages, and Applications(San Diego, CA, USA)(OOP- SLA ’05). Association for Computing Machinery, New Yo...

    2005

  7. [16]

    James Whitehead

    Sunghun Kim, Kai Pan, and E. James Whitehead. 2006. Micro pattern evolution. InProceedings of the 2006 International Workshop on Mining Software Repositories (Shanghai, China)(MSR ’06). Association for Computing Machinery, New York, NY, USA, 40–46. https://doi.org/10.1145/1137...

    2006

  8. [17]

    Chunmiao Li. 2021. Gas estimation and optimization for smart contracts on ethereum. In2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 1082–1086. https://doi.org/10.1109/ASE51524.2021. 9678932

    2021

  9. [18]

    1983.Measures of association

    Albert M Liebetrau. 1983.Measures of association. Vol. 32. Sage. https://doi.org/ 10.4135/9781412984942

    1983 doi

  10. [19]

    Stefano Maggioni and Francesca Arcelli. 2010. Metrics-based detection of micro patterns. InProceedings of the 2010 ICSE Workshop on Emerging Trends in Software Metrics(Cape Town, South Africa)(WETSoM ’10). Association for Computing Machinery, New York, NY, USA, 39–46. https://...

    2010

  11. [20]

    Nathan Mantel. 1967. The detection of disease clustering and a generalized regression approach.Cancer research27, 2_Part_1 (1967), 209–220. https://doi. org/10.1136/bmj.3.5668.473-a

    1967 doi

  12. [21]

    Mark Mossberg, Felipe Manzano, Eric Hennenfent, Alex Groce, Gustavo Grieco, Josselin Feist, Trent Brunson, and Artem Dinaburg. 2019. Manticore: A user- friendly symbolic execution framework for binaries and smart contracts. In2019 34th IEEE/ACM International Conference on Auto...

    2019

  13. [22]

    Yvonne Murray and David A. Anisi. 2019. Survey of Formal Verification Methods for Smart Contracts on Blockchain. In2019 10th IFIP International Conference on New Technologies, Mobility and Security (NTMS). 1–6. https://doi.org/10.1109/ NTMS.2019.8763832

    2019

  14. [23]

    Sidney Siegel. 1957. Nonparametric statistics.The American Statistician11, 3 (1957), 13–19. https://doi.org/10.1080/00031305.1957.10501091

    1957 arXiv

  15. [24]

    Amritraj Singh, Reza M Parizi, Qi Zhang, Kim-Kwang Raymond Choo, and Ali Dehghantanha. 2020. Blockchain smart contracts formalization: Approaches and challenges to address vulnerabilities.Computers & Security88 (2020), 101654. https://doi.org/10.1016/j.cose.2019.101654

    2020

  16. [25]

    Charles Spearman. 1961. The proof and measurement of association between two things.International Journal of Epidemiology(1961). https://doi.org/10.1037/ 11491-005

    1961

  17. [26]

    Williams

    Kazi Zakia Sultana and Byron J. Williams. 2017. Evaluating micro patterns and software metrics in vulnerability prediction. In2017 6th International Workshop on Software Mining (SoftwareMining). IEEE, Urbana, IL, USA, 40–47. https: //doi.org/10.1109/SOFTWAREMINING.2017.8100852

    2017

  18. [27]

    Kazi Zakia Sultana, Byron J Williams, and Tanmay Bhowmik. 2019. A study examining relationships between micro patterns and security vulnerabilities. Software Quality Journal27 (2019), 5–41. https://doi.org/10.1007/s11219-017- 9397-z

    2019 doi

  19. [28]

    Sergei Tikhomirov, Ekaterina Voskresenskaya, Ivan Ivanitskiy, Ramil Takhaviev, Evgeny Marchenko, and Yaroslav Alexandrov. 2018. Smartcheck: Static analysis of ethereum smart contracts. InProceedings of the 1st international workshop on emerging trends in software engineering f...

    2018

  20. [29]

    Palina Tolmach, Yi Li, Shang-Wei Lin, Yang Liu, and Zengxiang Li. 2021. A Survey of Smart Contract Formal Specification and Verification.ACM Comput. Surv.54, 7, Article 148 (July 2021), 38 pages. https://doi.org/10.1145/3464421

    2021 doi

  21. [30]

    Anna Vacca, Andrea Di Sorbo, Corrado A Visaggio, and Gerardo Canfora. 2021. A systematic literature review of blockchain and smart contract development: Techniques, tools, and open challenges.Journal of Systems and Software174 (2021), 110891. https://doi.org/10.1016/j.jss.2020.110891

    2021

  22. [31]

    Fernando Richter Vidal, Naghmeh Ivaki, and Nuno Laranjeiro. 2024. Vulnerability detection techniques for smart contracts: A systematic literature review.Journal of Systems and Software(2024), 112160. https://doi.org/10.1016/j.jss.2024.112160

    2024

  23. [32]

    Eric W Weisstein. 2004. Bonferroni correction.https://mathworld. wolfram. com/ (2004)

    2004

  24. [33]

    fallback

    Maximilian Wohrer and Uwe Zdun. 2018. Smart contracts: security patterns in the ethereum ecosystem and solidity. In2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE). IEEE, Campobasso, Italy, 2–8. https: //doi.org/10.1109/IWBOSE.2018.8327565 Micro...

    2018

  25. [306]

    https://doi.org/10.1109/SEAA.2012.63

    2012 doi

Pith tools

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