Taxonomy Construction

In this paper, we presented a hierarchical taxonomy for smart contract vulnerabilities. The taxonomy is up-to-date according to the current state of the practice and is prepared to handle future modifications and evolution. To build the taxonomy we began by analyzing current vulnerability classification schemes for blockchain, we also analyzed announced detection capabilities of research on smart contract vulnerability detection, and we followed an iterative process to structure the taxonomy. We analyzed the existing taxonomy characteristics and coverage against the state of the practice. In particular, we analyzed the claimed detection ability of current industry-level tools（detection rules）and mapped it to the different identified vulnerabilities. 

1. Steps for constructing our proposed taxonomy

We constructed a new vulnerability taxonomy for smart contracts from five perspectives as follows: 

1. We began by addressing the outdated and incomplete nature of existing taxonomies, such as the DASP Top 10 and SWC Registry. We removed outdated categories like the "Short Addresses" and added newly discovered vulnerability categories "Storage and Memory" to ensure a comprehensive representation of known smart contract vulnerabilities. 

2. We reorganized the taxonomy by analyzing the root causes of vulnerabilities, such as those in Block Manipulation and Cryptographic, to create a more structured approach in line with the ETSI smart contract standard. 

3. To resolve ambiguity and granularity issues in existing taxonomies, we combined overlapping categories and carefully analyzed their parent-child relationships. This step was to diminish ambiguity and redundancy, ensuring a clear and concise classification of vulnerabilities. For instance, we reorganized the category "Access Control" by merging "Unchecked Low-Level Calls" into it because of the containing relationship between them.

4. Meanwhile, to ensure our taxonomy’s relevance and practicality, we also considered the supported vulnerability types among state-of-the-art SAST tools such as Slither and Securify2 by examining their detection rules and aligning them with the categories in our taxonomy. This step was crucial to guarantee the applicability of our taxonomy to real-world tools and practices. 

5. Lastly, since our primary concern is vulnerabilities in smart contracts, we removed entries related solely to code quality, such as "unused variables" and "floating pragma".

This construction process was carried out by our three co-authors, each with five years of expertise in smart contract auditing. We employed the open card sorting method [1], involving the following key steps:

Collaborative and Iterative Analysis: Each co-author independently categorized different vulnerability types in each iteration. This step involved an in-depth analysis and careful labeling of each type, based on its unique characteristics and security implications.

Consensus Building through Discussion: After the initial analysis, they engaged in cross-validation and discussions to achieve consensus. Any disagreements were thoroughly deliberated, ensuring a consensus-based approach to decision-making.

Refinement and Convergence: Thanks to the iterative nature of this process, we were able to refine and enhance our taxonomy over three rounds. This approach led to a convergence in the categorization of vulnerabilities, indicating the robustness and reliability of our taxonomy.

The entire process spanned three person-months, and ensured our taxonomy was comprehensive, up-to-date, and aligned with both academic and industry standards in smart contract security.

2. The hierarchy of our proposed taxonomy

3. Detailed information for our taxonomy

The details for each vulnerability type such as description and related remediation recommendation is listed in the CSV file as follows:

[1] Donna Spencer and T Warfel. 2004. Card Sorting. Boxes and arrows 7 (2004).