Self-Auditing Smart Contracts with ChatGPT

When auditing smart contracts, a wide range of issues need to be covered to ensure that the code is secure. These questions cover various aspects including access control, asset management, data management, assumptions, dependencies, and security checklists. Below we provide a detailed checklist and instructions for ChatGPT queries to guide you through the smart contract auditing process.

If you want to investigate a smart contract yourself for vulnerabilities and hidden scamming techniques, the first step is a correctly crafted ChatGPT prompt.

A useful query for ChatGPT would be the following command:

Provide a comprehensive list of all problems and vulnerabilities in the following smart contract. Describe the problems and possible vulnerabilities in detail. Provide one exploitation scenario for each vulnerability. Output as a valid table in markdown format with a list of objects, each with columns 'description', 'action', 'severity', 'actors', 'scenario', 'type' and 'line'. 'type' where can be 'usability', 'vulnerability', 'optimization' or 'suggestion'. 'actors' is a list of actors involved. 'severity' can be 'low', 'medium' or 'high'. 'row' is the row number of the problem. Make sure that all fields in the table are filled in.

Then use the following questions to explore the smart contract in more depth.

Utilization Scenarios:

1. Who are the actors in the system?


2. What actions does the system have?


3. What are the limitations of the system?


4. What are some potential ways to break the system?


5. What defenses are used to counter the attacks?


6. Describe, based on the constraints, the state changes of each function.


7. Provide information about the Solidity and DeFi templates used.


8. Write positive and negative axioms based on information about the system.


9. List ways to optimize and modify code to make it more reliable (with code snippets).


10. List the hidden scam methods used in the code (with code snippets).

Tip: Visual representation of data often provides a clearer understanding of system operation. When working with ChatGPT, it is recommended that you request visualizations of output data, such as state modifications in the form of ASCII character diagrams. While not all visualizations may make sense, some can provide very valuable insight into the operation of a smart contract.

In fact, while ChatGPT cannot replace a human auditor, it significantly complements the auditing process by providing a clearer understanding of protocol state transitions, constraints, invariants, and compatibility. This tool is particularly effective for understanding protocol state transitions and constraints.

Tip: Before starting an audit, providing the chatbot with documentation on the protocol being audited can greatly improve the accuracy and relevance of the responses. Just mention, "This is the documentation that provides the best context for the 'protocol_name' I am auditing," and insert the document.

It can be said that ChatGPT is a powerful assistant for auditors, providing a structured and in-depth approach to auditing smart contracts. However, it should be kept in mind that ChatGTP (and similar services) are just complex interpretations of machine analysis working with probabilities, so it often produces errors and inaccuracies. Accordingly, the ChatGPT result cannot be fully relied upon - it is only a good tool in the right hands and a "starting point" in smart contract research.

Therefore, in order to protect yourself from possible risks, smart contracts should be examined more carefully for possible vulnerabilities and fraudulent schemes.

How to perform an in-depth smart contract audit? Top 100 requests to ChatGPT

Above we have considered a general query (prompt) to ChatGPT, from which you can start analyzing a smart contract. But, of course, the detailed analysis is not limited to the introductory prompt.

Scammers are constantly improving their tactics, so you need to be informed and cautious in many aspects - these are essential strategies to protect your token investment.

Let's take a look at a list of the top 100 queries that will give you a professional approach to a smart contract audit:

1. Does the code compile successfully?
2. What version of Solidity is used in the code? Is it the current stable version?
3. Are clear comments explaining the purpose of functions and variables present?
4. Does the contract use an "Ownable" scheme? If yes, for which functions?
5. Are state variables correctly allocated using visibility modifiers?
6. Are events used for proper logging?
7. Are user-friendly error messages provided?
8. Is the return value of low-level calls checked?
9. Are there scenarios where the owner can authorize themselves that could lead to rug-pulling?
10. Who has control over privileged accounts and what are the control mechanisms?
11. What governance mechanisms exist in the contract, and is governance fully open or limited?
12. Are other contracts used in the system and what roles do they fulfill (e.g. proxy contract)?
13. Is there a time locking mechanism and can it be bypassed?
14. Is there adequate documentation available?
15. Are there potential vulnerabilities to DoS or reentrancy attacks in the code?
16. Are all functions internal except those that are explicitly required to be public/external?
17. No arithmetic overflows/underflows in math operations?
18. Is the secure OpenZeppelin library being used?
19. Ether or tokens can't be accidentally sent to a null address (0x0)?
20. Conditions are checked with require before operations and state changes?
21. Is the state set before and during the execution of actions?
22. Is protection against reentry (reentry) attacks (A calls B calls A) used?
23. Is the ERC20 interface properly implemented?
24. Is the modifier used in multiple places only if it is really necessary?
25. Are all types set explicitly (e.g. uint256 is used instead of uint)?
26. Are all methods and cycles within the maximum allowable gas limit?
27. No unnecessary initializations in the constructor (remember default values are set)?
28. There is complete test coverage: every smart contract method and all possible input data types are tested?
29. Has fuzz testing been performed using random inputs?
30. Are all possible states that a contract can be in tested?
31. The default amounts of ether and tokens are specified in units of wei?
32. Does the crowdsale end block/time come after the start block/time (start / enable trading)?
33. Is the exchange/conversion rate of crowdsale tokens set correctly?
34. Is there a soft/hard crowdsale limit set?
35. Is the minimum/maximum allowable contribution to crowdsale set and tested?
36. Has crowdsale whitelisting functionality been tested?
37. Has the crowdsale refund logic been verified?
38. Do crowdsale participants receive a proportional number of tokens or can they claim their contribution?
39. Is the duration of each stage of the crowdsale (e.g., pre-sale, public sale) properly configured?
40. Does it specify which functions should only be controlled by the owner (e.g., pausing the crowdsale, moving to another stage of the crowdsale, enabling token distribution, etc.)?
41. Has the crowdsale vesting (vesting) logic checked out?
42. Crowdsale has a fail-safe mode that, when enabled by the owner, limits feature calls and includes a refund feature?
43. Crowdsale has a fallback feature if it makes reasonable sense.
44. Have the imported libraries been pre-checked and do not contain unwanted parts that may be replaced in future versions and could be used for malicious purposes?
45. Token transfer methods (transfer) wrapped in require?
46. Are require and assert used correctly? The assert method is only used for things that should never happen, usually it is used to check the state after changes have been made.
47. Is there a defense against recursive call attacks?
48. Are the lengths of arbitrary strings in the input limited?
49. Where possible avoid using arrays and use mappings instead?
50. Are block hashes not used to handle random values (miners can affect this)?
51. Doesn't use tx.origin anywhere?
52. Array elements are shifted down when an element is deleted so as not to leave gaps?
53. Is revert used instead of throw?
54. Functions terminate immediately if conditions are not met?
55. Have the compiler warnings been resolved?
56. Is the SafeMath library used in calculations?
57. Are any memory slots (storage slots) read more than once?
58. Are any unbounded loops/arrays being used that could cause DoS?
59. Is block.timestamp only used for long intervals?
60. Not using block.number to calculate elapsed time?
61. Is the delegatecall call avoided, especially for external (even if trusted) contracts?
62. Doesn't the length of the array get updated while iterating over it?
63. Are signatures protected from replay with nonce and block.chainid?
64. Make sure that all signatures are using the EIP-712?
65. The output of abi.encodePacked() should not be hashed if more than 2 dynamic types are used. In general it is preferable to use abi.encode().
66. Carefully check assembly code insertions.
67. Avoid insufficient gas consumption (gas griefing).
68. Is all private data truly private?
69. Updating a structure/array in memory (memory) will not change it in storage (stage)?
70. Are stage variables overshadowed?
71. Is calculating the value of a variable on the fly cheaper than storing it?
72. Are all state variables read from the correct contract (master vs. clone)?
73. Are the comparison operators (>, <, >=, <=) used correctly, especially to prevent off-by-one errors?
74. Are logical operators (==, !=, &&, ||, !) used correctly, especially to prevent off-by-one errors?
75. Is multiplication always performed before division (unless multiplication can overflow)?
76. Are magic numbers replaced by a constant with an intuitive name?
77. If an ETH recipient has a fallback (fallback ) function that can be reverted, could this lead to a DoS?
78. Is the SafeERC20 standard used and are the return values checked in a safe manner?
79. Is it assumed that the msg.sender is always a relevant user?
80. Isn't tx.origin used for authorization?
81. Isn't address.transfer() or address.send() used instead of .call.value()?
82. When using low-level calls, make sure that a contract exists before the call.
83. Is assembly code used to access chainid or contract code/size/hash instead of Solidity syntax?
84. Is the delete keyword used when setting a variable to a null value (0, false, "", etc.)?
85. Expressions passed to logical operators/comparisons (&&/||/>=/==/etc) must not have side effects.
86. When dealing with multiple addresses, ask yourself what happens if they are the same?
87. How well documented is the code? Are comments and examples provided wherever non-standard code is used?
88. If External Call is used, make sure that an external contract call is really necessary?
89. Is the result of the External Call checked and are errors handled?
90. What happens if External Call uses all of the gas provided?
91. If External Call calls a specific function, make sure that the function actually exists (phantom functions).
92. Make sure that no external calls are used in the modifiers (modifiers)
93. Are events issued for each function that modifies storage?
94. Check your assumptions about what the external contracts used in the main do and return.
95. Watch out for tokens that use too many or too few decimals. Ensure that the maximum and minimum supported values are documented.
96. Is the authority associated with the roles documented?
97. What are the risks when access rights are violated and how can this affect the various components of the system?
98. Can the owner manipulate tokens and ETH within the contract?
99. How is the oracle (Oracle) address set and what is the process behind it? Are there spare oracles for backup?
100. How are similar functions implemented in other projects, have best practices been taken into account?

This checklist will help you ensure that you conduct a thorough security audit of Solidity smart contracts. It covers a wide range of critical aspects to identify and mitigate potential vulnerabilities and risks in the code and related systems.

 

We hope these examples have helped you better understand the smart contract audit methodology.

Since all information in the blockchain is open (provided, of course, that the source code of the contract is verified), armed with this knowledge you can independently study smart contracts and identify various scam schemes.

However, we've already done it all for you! Sign up for a premium subscription and get access to exclusive filters on smart contracts features and fresh analytics. Increase your chances of successfully investing in profitable tokens.

Regards, Lotus Market team.

All posts