Analyzing the Impact of Copying-and-Pasting Vulnerable Solidity Code Snippets from Question-and-Answer Websites (2025)

2.1. Solidity and Smart Contracts

Ethereum Virtual Machine (EVM)[54] smart contracts are typically written in Solidity[18], a high-level language with static typing, multiple inheritance, complex types, as well as nestable contract constructs (e.g., comparable to class in OO programming languages).Since we analyze Solidity on source code level, we do not explain the translation of code into EVM bytecode.1 highlights concepts used in Solidity to implement smart contracts.Constructors initialize contracts on deployment.In Line 4, the owner is set to the address of the Ethereum account that is deploying the smart contract (i.e., msg.sender). This is a common design pattern using Ethereum addresses as identity for access control. Line 10 declares a contract with the constructor keyword, which is mandatory since Solidity 0.5 to avoid issues when misspelling function names. In Line 12, the contract declares a default function that is called when users invoke the contract without specifying a function name. The contents of the state variables, e.g. state_var, are persisted after every transaction and represent the program state. The address in owner is used to control access to critical functionality. In Line 15, all funds of a contract are sent to the caller and the modifier onlyOwner declared in Line 18 is wrapped around some functions to ensure only the owner can execute them successfully. If the require in Line 19 fails, the transaction fails, and all changes to involved contract are rolled back.

2.2. Smart Contract Vulnerabilities

The Ethereum blockchain is essentially a decentralized computer that stores information, executes functionality, and manages an internal currency (i.e., ether). The nature of a vulnerability, therefore, is a lack of integrity protection that allows an attacker to illicitly extract either ether from a smart contract, prevent the execution of contract functionality, or tamper with the information stored in a contract’s program state. A number of such vulnerabilities have been presented in the past years [3, 36].The Decentralized Application Security Project (DASP)[53] categorizes the 10 most common smart contract vulnerabilities: lacking restrictions to sensitive functionality(Access Control); over- and underflows(Arithmetic); use of predictable values for randomness(Bad Randomness); operations that allow attackers to hinder contract execution(Denial of Service); operations that can benefit a malicious user by preempting someone else’s transactions(Front Running); predictable code effects due to miners choosing the transactions’ timestamp(Time Manipulation); repeated/nested execution of a contract due to external contract calls(Reentrancy); functions vulnerable to padding attacks in transaction addresses(Short Addresses); unchecked return values of critical functions(Unchecked Low Level Calls); and remaining vulnerabilities(Unknown Unknowns).Table6 in our evaluation uses these categories to argue about the performance of our queries and limitations of the analysis.

2.3. Code Property Graphs

Other edges are added for reference resolution, call targets, and the programs type system.The resulting interconnected tree is persisted into a graph database and queried against specific vulnerability patterns. Figure2 shows an example graph when persisting if(msg.sender == owner){}. The EOG edges in green show that msg.sender is evaluated before the reference to the owner, and then are compared at == to evaluate the condition for the branching IF. The DFG edges in blue show how both references are used as input to evaluate == and are finally used to influence the branching IF. The remaining edges in gray show specific AST information. LHS shows the left-hand side and RHS shows the right-hand side of == that serves as CONDITION to the IF-statement.

2.4. Code Clones

Code clones are code fragments that are similar with respect to a clone type.A code fragment is a contiguous segment of source code, with or withoutcomments.Fragments may contain any number of lines, statements, or functions.To differentiate between different types of clones, we use the categorization of Roy and Cordy[37]:

Type I, II, and III clones indicate textual similarity, Type IV clones indicate semantic similarity.Our focus is to detect code clones up to Type III, i.e. textual similarity, as these are related to SODD.

3.1. Limitations

Our approach identifies code clones by comparing the similarity of snippets and deployed contracts. This method cannot prove that the snippet was copied from a Q&A website. We reduce the likelihood of confusing causal directions in Section6.3. It is, however, still possible that a third source was responsible for the Q&A snippet and the deployed contract. However, this limitation is shared with other works in the field and considered unlikely[16]. Proper operationalization to analyze causality can only be done by engaging in unethical dissemination of marked vulnerable code fragments and is, therefore, not done.

4.1. Grammar Modifications

Language grammars represent a syntactically valid program that follows a program’s structured hierarchy. Therefore, we have to modify an existing Solidity ANTLR grammar[44] to parse snippets:

While these changes could lead to the incorrect parsing of valid Solidity code, we did not encounter such cases.

4.2. Translation of Smart Contracts

We use the ANTLR parser with the modified grammar to get an AST which we translate into CPG nodes of the used library. To do so, we implement a language-specific translation component, the Solidity Language Frontend, supplementing the library. In this component, we translate a variety of expressions, statements, and declarations into their respective graph nodes. The declaration of contract and state variables are translated into Record and FieldDeclaration as they are similar to the object-oriented concept of Classes and class-instance fields.When a snipped is parsed, and the outer declarations of a contract or function are missing, our frontend complements the translated AST with the inferred declarations.In the following, we will present further peculiarities of the Solidity language and how we translated them into the CPG.

4.3. Query Design

We implement our search for vulnerable smart contract snippets as queries in the Cypher Query Language [31]. With this declarative language, we can express graph patterns containing code syntax and semantics to find code that is considered problematic in its syntax or behavior. The following simplified query returns function parameters containing data that, at some point is written to a smart contract field, i.e., is persisted across transaction execution: MATCH (p:Parameter)-[:DFG*]->(:Field) RETURN p.We conceptualized the following query components:

4.4. Modeling Vulnerabilities

We implemented 17 queries in a best-effort approach to cover vulnerability patterns mappable to the 10 DASP categories mentioned in Section2.2. Instead of learning vulnerable patterns from code done by previous work[16], we write rule-based queries describing the underlying issues.In our query methodology, we build the above-mentioned base pattern from program patterns that can lead to the vulnerability described in the DASP category. We had to implement more than one query for a category if the base pattern could not be unified. We then considered what additional program behavior needs to be around the base pattern to constitute a potential implementation issue, e.g., external calls or sending of ether. Finally, we added patterns to exclude cases where the surrounding program behavior prevents the issue to the best of our knowledge.We will now show one of our queries and explain the query creation and the applied pattern concepts presented in Section4.3.

The query shown in Listing2 identifies the vulnerability pattern. The first part constitutes the base pattern: A program path in a default function was found that does persist its results, i.e., does not end in a Rollback node and calls another contract through delegatecall. The second part of the query forms the condition of relevancy: the caller can control the call target through the values in msg.data. The final part shows how finding a mitigation technique leads to not producing a false positive: Along the path, there is a check on the content of message data that leads to an alternative path avoiding the call or leading to a rollback.

Note that Listing2 is simplified for better readability. The full queries used in this work are listed in AppendixB.

4.5. Limitations

Our vulnerability detection is limited to Solidity source code as we try to analyze snippets that are generally not compilable. Only 3.6% of snippets contain assembly, which we therefore did not model. Our approach is specifically developed to handle incomplete code, which needs analysis on the source code level. While pattern-based analysis on CPGs can leverage data flow and control flow information in addition to syntax, the results are more prone to false positives than specialized detection tools using symbolic execution and SAT-solving. However, more sophisticated tools are not applicable to snippet analysis.

4.6. Evaluating CCC

We evaluate the performance of CCC against other well-established smart contract analysis tools using a dataset of labeled smart contract vulnerabilities.Moreover, we assess CCC’s ability to detect vulnerabilities within Solidity code snippets.

5.1. Parsing

As a first step, we need to parse the smart contract source code. To deal with code clones of Type I, we remove all whitespaces, new lines, and comments from the Solidity source code.Afterwards, we leverage our own parser that uses a custom Solidity ANTLR grammar that is capable of parsing incomplete Solidity source code (i.e., code snippets, see Section 4.1). The parser generates an AST, which is essentially an XML parse tree that provides a structural representation of the smart contract.

5.2. Normalization

After generating the AST we normalize the source code by traversing the AST and renaming any identifiers such as contract declarations, variable names, parameters, etc.All contract declarations are renamed to “c”, all library names are renamed to “l”, all function names are renamed to “f”, and all modifiers are renamed to “m”. All parameters and variables are renamed according to their declared type. For code snippets with missing type declarations we simply use the default type uint. For example, the following code snippet:

Moreover, we replace string literals with the keyword stringLiteral. Numeric constants are left untouched since a difference in these may have an impact on whether the smart contract is vulnerable or not, thus normalizing numeric constants could yield false positives when matching. Finally, we also normalize function visibility, such as public or view, by simply removing them.The renaming of identifiers, string literals, and function visibility allows us to deal with code clones of Type II, where developers copied some code blocks but modified the names of the variables or functions.

5.3. Tokenization

In this step, we split the normalized source code into tokens. We ignore state variable declarations as well as event declarations and only focus on contract declarations and function declarations as well as function-level statements.Afterwards, we simply divide the code based on symbols (e.g., “+”, “-”, “;”, or brackets). This allows us to only preserve the context that is relevant to us. For example, the following statement: msg.sender.transfer(uint) is tokenized into the following six tokens: ‘msg’, ‘.’, ‘sender’, ‘.’, ‘transfer’, ‘uint’. These tokens are then used to generate a unique fingerprint.

5.4. Fingerprint Generation

We leverage fuzzy hashing [26] to condense the normalized and tokenized source code to a so-called fingerprint, a much shorter representation of the original source code. We then calculate the edit distance between two fingerprints to measure their similarity and to identify if they are code clones or not.Unlike traditional hash functions, fuzzy hashing first splits a sequence into smaller pieces and usesa piece-wise hash function to compute a hash for each piece. The final fingerprint is generated by concatenating the piece-wise hashes together.As opposed to a traditional hash function where one little change in the input results in an entirely different hash, in the case of fuzzy hashing, only the modified pieces will result indifferent piece-wise hashes, hence, the resulting fingerprint will not be entirely different but will still look very similar. Figure 5 provides a concrete example of two similar code snippets. We observe that the newly added line (highlighted in yellow) only modifies a part of the fingerprint and that the rest remains the same.Fuzzy hashing reduces memory usage and computation time as the matched sequences are much smaller.

One of the main challenges of fuzzy hashing is to determine the optimal boundary of each piece. One of the most widely used fuzzy hashing tools is ssdeep [22], which splits by default any sequence of bytes into chunks (i.e., pieces) of seven bytes.We leverage ssdeep to transform our tokenized source code into a fingerprint. However, instead of concatenating all tokens together and feeding them directly as one sequence to ssdeep, we feed each token one by one to ssdeep and concatenate the resulting fuzzy hash to a final fingerprint. This allows us to enforce context on the fuzzy hashes and hence the final fingerprint. The final fingerprint is a sequence of base-64characters, where function code is separated from one another using a period (i.e., “.”) and contracts are separated using a colon (i.e., “:”). This is useful later when matching fingerprints of functions and contracts, irrespective of their order in the code (see Section 5.5).

5.5. Fingerprint Matching

To solve the second challenge, we do not directly compute the edit distance on two given fingerprints. We split each fingerprint into several sub-fingerprints. As described in Section 5.4, our fingerprints contain non-base-64 characters such as “.” and “:” in order to separate function implementations and contract definitions. The idea is to individually match fingerprints of function implementations irrespective of their order across code snippets.We compute the similarity score for two sub-fingerprints $s_{1}$ and $s_{2}$ as follows:

5.6. Limitations

Our approach is not capable of detecting semantic code clones (i.e., clones of Type IV). However, it is able to detect syntactically similar code clones (i.e., clone of Type I, II, and III.). We argue that this is sufficient for the scope of this paper as we aim to detect code snippets which have been copied and pasted by developers and where we assume they might have added comments, changed variable names, or even slightly modified the code snippets by adding or removing some lines of code from the original snippet. However, we do not assume that developers created syntactically entirely different code from code on Q&A websites.

5.7. Evaluating CCD

We evaluate the performance of CCD by comparing it to SmartEmbed [19], a state-of-the-art clone detection tool for smart contracts that leverages structural code embeddings. Please note that, as opposed to CCD, SmartEmbed requires complete code that compiles and cannot analyze incomplete code snippets out-of-the-box.

6.1. Data Collection

We gather Solidity code snippets posted on developer Q&A websites by crawling Stack Overflow [35] and the Ethereum Stack Exchange [13] for posts created until June 30, 2023 with the tag “solidity”. Overall, we collect 39,434 code snippets across 25,653 posts, where 12,111 snippets originate from 7,370 posts on Stack Overflow and 27,323 snippets originate from 18,283 posts on the Ethereum Stack Exchange (see Table 4). However, not all snippets are necessarily Solidity code snippets. Some contain JavaScript code or some form of pseudo-code that has been tagged as “solidity” by the author.

We filter out snippets that are not related to Solidity by checking if they include unique Solidity keywords. JavaScript has $124$ keywords, whereas Solidity has $251$ keywords. However, both languages have several keywords in common such as “var” or “public”.After removing common keywords, we are left with $166$ unique Solidity keywords.After filtering out snippets that do not include at least one of the $166$ keywords, we are left with 25,725 snippets, 7,116 from Stack Overflow and 18,609 from Ethereum Stack Exchange.

Despite using a modified grammar that allows to parse incomplete code, some snippets simply cannot be parsed, because they include text that is not valid Solidity code (e.g., a mix of pseudocode with valid Solidity keywords). Hence, we filter out all snippets, which cannot be parsed using our grammar. This results in 19,870 parsable snippets, where 5,305 are from Stack Overflow and 14,565 are from the Ethereum Stack Exchange. Our grammar manages to parse 3,133 more snippets than the standard Solidity grammar.Majority of the parsed snippets contain contract definitions (54,2%), followed by snippets with only function definitions (38%), and finally snippets that contain only statements (7.8%).Moreover, the maximum number of lines of code of the parsed snippets is 775, whereas the mean is 22, the median 12, and the minimum is 1.Lastly, we removed all duplicates and were left with a total of 18,660unique snippets that can be used for our study, of which 5,187 are from Stack Overflow and 13,473 are from the Ethereum Stack Exchange.

Our final goal is to map vulnerable snippets to deployed smart contracts. We leverage the Ethereum Smart Contract Sanctuary [34] dataset, which contains the source code of deployed smart contracts that are verified on Etherscan.The dataset consists of 323,328 smart contracts with Solidity source code deployed until July 14, 2023.Most of the contracts (59%) were deployed using v0.8 of the Solidity compiler, 16% using v0.6, 13% using v0.4, 7.4% using v0.5, and roughly 4% using v0.7. Between May and June of 2023, majority (91%) were deployed using v0.8 (latest version), while 9% were deployed using an older version, which makes the latter susceptible to vulnerabilities (e.g., integer overflows [43]).

6.2. Popularity and Appearance Frequency

In this section, we analyze whether a snippet in a popular Q&A post has an increased likelihood of appearing in a real-world smart contract. We define the popularity as the number of views v on a Q&A post. If an effect exists that leads to developers adopting snippets from Q&A websites, we expect to see a correlation between the number of views v and the number of contracts containing the snippet. If no correlation is measured, either no effect can be assumed, or a different variable determines whether a snippet is copied into a contract.

We want to differentiate between snippets that are more or less likely to be postings of already deployed contracts or third-party sources. Snippets that are more likely to be postings of other sources should have a weaker correlation between v and nr than those that are less likely and, therefore, are more likely to represent cases of copy&paste code from the snippet to contract. Consequently, we expect higher correlation as the temporal restrictions between snippets-contract pairings increase in the following sets:

Of the 323,328 contracts in our smart contract sanctuary dataset, 135,408 contain code similar to a snippet posted on a Q&A website. 113,308 contracts show this relation to a (disseminator) snippet that was posted before their deployment. 47,099 contracts show similarity to a (source) snippet that has no embeddings in previously deployed contracts.To keep all three groups comparable we measure the impact of increased views on increased occurrences by only using snippets with at least one embedding contract (i.e., $\textit{nr}>0$).To properly quantify developer adoption of snippets, we measure the correlation between v and the number of contracts deployed from unique contract codes containing the snippet nr.We do not use the Pearson’s coefficient as our data is not normally distributed. This could be due to modern search engines recommending highly viewed posts, therefore leading to even more views and more adaptations by developers. We therefore compute the Spearman’s rank coefficient $\rho$, a nonparametric correlation used to measure monotonic relationships, i.e., high v comes with a high nr.

Table5, shows our results of computing the coefficient $\rho$ to compare the three groups. No correlation was measured between the views of all snippets and their appearance in contracts. However, with a p-value lower than 0.001 for both disseminator and source snippets, the measured correlation is significantly different from 0. The views v of disseminator snippets show only a low correlation of $\rho=0.139$ to the number of newer containing contracts nr. For source snippets, the correlation is low to medium with $\rho=0.282$. It is crucial to mention that measuring a correlation is still no prove of a causal relationship. External sources and factors may influence the number of views on a post and the appearance of code in a contract to the same extent. While the correlation is low, we observed several cases of snippets having a high number of views but no identified clones. We therefore suspect that, beside views, other factors play a role in the adoption of snippets. More extensive data crawling and multivariate correlation analysis are necessary to further investigate this issue. However, the presence of a low and low to medium correlation when it comes to disseminator and source snippets supports the decision to investigate them both in the following section.

6.3. Experiment

Figure6, depicts our experiment pipeline that aims to identify whether or not vulnerable code snippets posted on popular Q&A websites lead to vulnerabilities in Ethereum smart contracts.First, we leverage CCD to identify smart contracts that contain clones of the 18,660snippets.To produce results with high confidence, we chose conservative parameters: an N-gram size of $3$, an $\eta$ threshold of $0.5$, and an $\epsilon$ threshold of $0.9$.Next, we run the 18,660snippets through CCC, using the same configuration as in section 4.6, to identify which snippets are vulnerable.Afterwards, we map the vulnerable snippets to deployed smart contracts using our mapping produced by CCD.We restrict our analysis to disseminator and source snippets as defined in Section6.2 to reduce the impact of third-party sources and remove all duplicate smart contracts by comparing the source code after removing comments to account for slight changes that do not alter program behavior.This allows us to reduce the cost of the final step and specify how many unique contract implementations are vulnerable.In our two phased validation, we first run all contracts that were identified to contain vulnerable snippets, through CCC, to validate that the vulnerability is also present in the deployed contract. To avoid counting other vulnerabilities, we run CCC by checking only against the vulnerability that has been previously identified in the vulnerable snippet. In the second phase, we rerun all contract validations that ran into a timeout with modified queries that iteratively reduce the maximal length of data flows. This method finds more true positives by avoiding path explosion problems and does not increase false negatives as the analysis was not terminating previously. This path reduction is only allowed in the second phase of the validation and only in the parts of the query that are not in negated existential subqueries, as they would ignore valid vulnerability mitigations.

6.4. Results

Table7 shows the result of running our experiment pipeline on the collected snippets and contracts. From the 18,660snippets that were parsable using our modified grammar, we found 4,596to be vulnerable. Our conservative configuration of CCD aimed at finding code clones with high confidence, found contracts containing 723 vulnerable snippets. By eliminating contracts that were deployed before the snippet posting we further reduced the amount of snippets to 602 that could have led to SODD. This left us with 26,565contracts to verify on whether they are vulnerable after including the vulnerable snippets. After filtering duplicate contracts, we remained with 24,451unique contract clones. 227of these potential disseminators of vulnerabilities are source snippets and have 4,828unique contracts to be verified, shown in parenthesis in Table7.

In the validation step, we run CCC for all 24,451deployed contracts that are candidates for containing vulnerabilities introduced by using vulnerable code snippets. For the execution we set a timeout of 1,800 seconds per contract and configured the analysis to rerun the vulnerability search that identified a vulnerability in the code snippet. The validation completed for 19,992contracts successfully, while it encountered issues such as stack overflows in the Neo4j persistency layer or exceeding the timeout of the analysis for the remaining contracts. With the path reduction method in the second phase, we managed to increase the number of successfully analyzed contracts to 21,047.CCC found 17,852of the contracts to be vulnerable and 616of the 602vulnerable snippets to have vulnerable contracts including them. Table6 shows the distribution of vulnerability categories across vulnerable snippets and contracts, where multiple snippets and contracts contain more than one vulnerability pattern. It is noteworthy that arithmetic and short address vulnerabilities constitute a large number of validated contracts as they are less relevant for the future. Arithmetic bugs are protected against in versions >=0.8, and addresses have to be sanitized on the client side. Front running issues are mostly low impact but can lead to losses in some cases, and denial of service vulnerabilities can have an impact but are hard to exploit.

6.5. Manual Validation

We select 100contracts that were flagged vulnerable by CCC for our manual analysis. The contracts were equally sampled from all DASP categories when possible, but randomly chosen within the category. This small sample allows us to uncover some qualitative issues of our analysis but does not allow for extrapolation. We manually review: 1) if the original snippet was vulnerable; 2) if the contract was indeed a code clone; 3) if the contract contains the vulnerability. Figure 7 depicts a screenshot of a vulnerable snippet containing a potential reentrancy vulnerability posted on the Ethereum Stack Exchange. Figure 8 shows a screenshot from Etherscan of a deployed smart contract that includes the vulnerable snippet depicted in Figure 7.We backtrack every contract to a unique vulnerable snippet they are supposed to be clones of. Both contracts and snippets are unique among each other to create randomized variety. The results of our manual review can be seen in Table8. 48of the manually analyzed pairings confirmed to be a vulnerable snippet that had a vulnerable contract identified as a clone. 3contracts contained a confirmed vulnerable snippet, but had mitigating circumstance, while in 1case a vulnerable contract contained a wrongly flagged snippet. In 22cases CCC incorrectly identified a snippet as vulnerable. In 26cases the code clone detection matched a snippet to a contract that we did not consider sufficiently similar. While in 3cases the vulnerable snippet had a wrongly identified vulnerability of the same type, in 15cases CCC found a vulnerability of the same category that we then confirmed valid. In 7cases we flagged snippet and contract incorrectly as vulnerable and clones of each other. In two cases, the snippets were wrongly identified as vulnerable, but the correctly or incorrectly associated contract contained a vulnerable pattern of the same type.

We performed a qualitative analysis of all snippet contract pairings where we either manually identified the snippet or the contract to be a false positive. The result of this qualitative analysis allows us to discuss our limitations when analyzing real-world snippets and contracts. We encountered 37 false positives. This may be due to our small sample size or the unrestricted counting of false positives, see Section4.6.3. We encountered 2 cases of false positives that we have seen in the benchmark analysis. Most other false positives were due to issues we previously did not encounter: 7 FP in the category Access Control, 2 due to complex access controls, one legitimate comparison tx.origin != msg.sender, and 4 cases of proper functionality isolation within the contract initialization; 1 case of a legitimate block number use incorrectly flagged as Bad Randomness; 4 cases of misreported Reentrancy due to different shortcomings of CCC; 6 cases of falsely reported Denial of Service issues where 3 cases were converging loops; 10 cases of harmless patterns to delegate allowances of money transfers being reported asFront Running issues; in 2 cases of Arithmetic issues we did not identify the prevention of the issue through compilation with Solidity 0.8 or greater, and 7 cases where the mitigation for overflows in a SafeMath library was implemented differently than expected. Especially the latter two categories represent some of the more prevalent DASP categories measured in Table6. While extrapolation from such a small sample is not reliable, this could be explained by a high false positive rate over the entire category or the small sample size, requiring further manual investigation. We argue that, even outside of these categories, sufficient snippets and contracts appear to contain vulnerability patterns to raise concerns. In the future, new patterns should be incorporated to account for additional mitigation techniques, e.g., a larger variety of multi-owner, over-underflow checks, and patterns to ignore allowances. Furthermore, graph-based pattern matching should supplemented with techniques to recognize converging loops and unrealistic overflows, e.g., constraint solving and edge case analysis.

6.6. Discussion and Limitations

Our automated analysis identified a concerning number of vulnerable snippets on Q&A websites. However, many were flagged to be vulnerable to Over-Underflows, Front Running or Short Address attacks. These vulnerabilities depend on the program’s context and knowledge of the contract’s purpose.This relation can also be seen within the subset of source snippets. The results of our analysis are not complete as several validations ran into timeouts. We partially mitigated this issue by limiting the length of explored data flow paths for contracts where we received a timeout. This method increased the number of validated patterns in contracts from 17,278to 17,852while not influencing the precision of our results. Only a fraction of the vulnerable snippets has made it into deployed smart contracts. Nonetheless, this small amount of snippets was found in 24,451contracts, of which 17,852did not mitigate the vulnerability.

6.7. Mitigations

In our opinion, the use of snippets from online resources to solve implementation problems cannot be prevented. It is, therefore, necessary to improve the quality and prevalence of pre-deployment static code analysis and steer developers towards more trustworthy sources for examples on how to implement a solution. Providers of Q&A websites can flag code snippets that are considered problematic by tools like CCC or show high similarity with code reported as part of a vulnerability. Organizations can use static code analysis tools, including tools like CCC, to catch suspicious code fragments in the early development cycle.Organizations and companies can provide documentation on the state-of-the-art snippet template to solve frequent problems. The decision on which recommendations are necessary can be made based on the most viewed posts on Q&A websites. Deviations from whitelisted patterns can be prevented or caught for review in a CI/CD pipeline.

7.1. Smart Contract Vulnerability Detection

The interest in finding vulnerabilities in smart contracts has been growing in the last few years.SmartCheck[46] translates Solidity source code into an XML-based representation and is checked against XPath patterns.Slither[15] uses its own intermediate representation (IR) to transform code into a single static assignment form including data-flow analysis to detect vulnerabilities.Oyente[29] uses symbolic execution to find vulnerabilities and was extended[48] to detect arithmetic vulnerabilities.Mythril[30] combines symbolic execution with taint analysis to reduce false positives, while MAIAN[32] leverages symbolic execution to find vulnerabilities across multiple transactions.Conkas[33] also leverages symbolic execution but builds up on Rattle’s IR [9]. ConFuzzius[47] presents a hybrid fuzzer that combines symbolic execution with fuzzing. HoneyBadger[7] uses symbolic execution to identify smart contract scams.Sendner et al.[40] performed a large-scale analysis of several vulnerability detection tools and found the state-of-the-art insufficient in tackling the challenge of detecting vulnerabilities.Giesen et al.[20] developed a compiler for smart contracts (HCC) which translates smart contracts into a CPG to patch reentrancy and integer bugs. While the underlying concept of using a CPG is similar, CCC’s CPG has been developed with to analyze code snippets an full smart contracts. In fact, the aforementioned tools either only operate on bytecode or are not able to analyze incomplete code such as snippets.

7.2. Code Clone Detection

A plethora of tools have been proposed to detect smart contract code clones at bytecode or source code level.EClone[28] compares contracts based on their symbolic transaction sketches and extended their approach by introducing birthmarking[27].Eth2Vec[2] uses natural language processing on Ethereum bytecode to argue on the similarity of code.Zhu et al.[58] uses neural networks to detect similar bytecode while being resilient to different compiler versions and later used pattern matching over control-flow graphs to detect similarity [57].Deckard[23] presents an efficient algorithm to cluster syntax sub-trees of C and Java, and was adapted for Solidity. SmartEmbed[19] uses structural code embeddings to detect code clones in Solidity source code. White et al.[52] used a deep learning approach to detect code clones with higher accuracy than Deckard.Kondo et al.[25] used Deckard to identify code clones among contracts listed on Etherscan and compared if they contained code blocks from OpenZeppelin [56].Chen et al.[8] studied code reuse among contracts on Etherscan. Similar to CCD, they parse Solidity with ANTLR and tokenize the AST, but compare on a contract level, the contract name and a rigid token sequence.Volcano[39] uses the tool NiCad [38] to find vulnerable smart contracts by comparing their code on a function level with known vulnerable contracts.Most aforementioned tools are either designed to detect bytecode similarity or are not specifically designed to detect clones of code snippets, making them unable to parse code snippets.Similar to us, He et al.[21] uses fuzzy hashing to compare smart contracts. However, the authors analyze bytecode, while we compare source code and thus normalize and tokenize with a different techniques. Moreover, we only preserve code order for atomic code blocks, and our approach is more efficient due to the pre-filtering via n-grams.

7.3. Implications of Q&A Websites

Fischer et al.[16] presented the first automated approach to detect security-relevant code snippets from a Q&A website in Android Applications. Their approach uses machine learning based classification to get a security score and abstract interpretation on program dependence graphs to identify the presence of snippets.Ayman et al.[4] studied discussions related to Ethereum smart contracts posted on Stack Overflow but did not analyze security implications of vulnerable code snippets.Soud et al.[45] conducted an empirical study on smart contract related vulnerabilities found on Stack Overflow and GitHub, but they performed a manual analysis and did not evaluate the impact on deployed contracts.Our work, is the first to analyze the transfer of vulnerable code snippets to real-world smart contracts in a fully automated fashion.