ChatGPT prompts for smart contract security are becoming a practical way to speed up early security review tasks like threat modeling, vulnerability discovery, and remediation drafting. Evidence from public experiments suggests LLMs can identify many common issues in small to medium Solidity codebases, but they still miss novel bugs and can produce false positives. That makes these prompts most valuable when used alongside static analysis, fuzzing, and experienced human review - not as a replacement for them.

This article explains what ChatGPT can and cannot do in smart contract security today, then provides 25 copy-paste prompts you can integrate into your workflow.

Current State of ChatGPT for Smart Contract Security

What ChatGPT Does Well

LLMs perform best when the task matches known patterns and the prompt constrains the output format.

Pattern-based vulnerability detection in small to medium contracts: OpenZeppelin tested GPT-4 against Ethernaut challenges and found it could solve many older levels but struggled on newer ones requiring more novel reasoning. The takeaway is clear: pattern familiarity matters.
Natural language explanations and remediation ideas: LLMs can explain why a pattern is risky, how it might be exploited, and what a typical fix looks like - for example, reentrancy mitigations, access control tightening, or safer upgrade patterns.
Auxiliary artifacts: When explicitly requested, ChatGPT can draft proof-of-concept interaction scripts, test scaffolds, and refactoring suggestions that make manual review more efficient.
First-pass scanning: Security teams such as MixBytes have described using GPT-4 to pre-scan isolated functions or smaller contracts to surface red flags, with the understanding that the output is not authoritative.

Where It Struggles

Novel and complex vulnerabilities: Performance drops sharply on unseen patterns, especially those requiring deep EVM semantics or multi-contract reasoning.
False positives and missed issues: Industry and academic research both report that naive use can lead to misclassification of benign patterns and missed subtle bugs. Treat findings as hypotheses to validate, not confirmed findings.
Non-determinism and prompt sensitivity: Results can vary based on phrasing, context length, and iterative prompting. Reproducibility is limited compared to deterministic tooling.
No formal guarantees: LLMs cannot prove the absence of vulnerabilities. Tools like Slither, Mythril, Echidna, Foundry fuzzing, and formal verification remain essential for any meaningful security assurance.

How to Use ChatGPT Prompts Responsibly in a Security Workflow

Use these prompts as part of an AI-augmented audit workflow:

Start with threat modeling: clarify assets, trust assumptions, and attacker goals.
Run focused vulnerability passes: reentrancy, access control, arithmetic, oracles, upgradeability, and MEV.
Validate with tools: static analysis, unit tests, fuzzing, property testing, and manual review.
Use fix prompts to draft patches: then confirm fixes with regression tests and exploit reproduction attempts.

25 ChatGPT Prompts for Smart Contract Security

Each prompt below is designed to be copied as-is. For best results, provide concrete context: the Solidity code, protocol description, assumptions (admin keys, upgrade model, oracle details), and the intended invariants.

Threat Modeling Prompts (1-8)

1. High-Level Protocol Threat Model

Copy-paste prompt:

Act as a senior smart contract security engineer.
I will describe a DeFi protocol at a high level.
Step 1: Summarize the core assets, actors, and trust assumptions.
Step 2: Identify critical security objectives (e.g., prevent fund loss, preserve invariants, avoid governance capture).
Step 3: Produce a structured threat model using STRIDE or a similar framework, with concrete examples for each category that are specific to this design.
Step 4: Rank the threats by impact and likelihood and suggest which should be prioritized for detailed review.

2. Contract-Level Threat Model from Code

Act as a smart contract auditor.
Here is a Solidity contract.
1) Identify the main roles and permissions.
2) Describe the value flows and critical state variables.
3) Create a threat model focused on:
- Reentrancy
- Access control and role abuse
- Price manipulation and oracle risks
- Economic exploits (e.g., sandwich, MEV, flash loans)
- Upgradeability or governance misuse (if applicable).
Output in a table with columns: Threat, Attack preconditions, Potential impact, Mitigating controls (present or missing).

3. Threat Model for Upgradeable Contracts

You are analyzing an upgradeable proxy-based system (e.g., OpenZeppelin Transparent or UUPS Proxy pattern).
Given the following proxy and implementation contracts, produce a threat model focused on:
- Initialization and reinitialization risks
- Admin key compromise
- Logic self-destruction or brick risk
- Storage layout collisions
- Insecure upgrades or backdoored implementations.
For each risk, state how an attacker could exploit it and what on-chain or off-chain controls can mitigate it.

4. Governance and DAO Threat Model

Act as a DAO governance security specialist.
Given this governance contract and token model, identify:
- Possible vote-buying or flash-loan governance attacks
- Proposal execution race conditions or front-running
- Parameter change risks that can de facto seize or freeze funds
- Centralization or admin backdoors in the governance process.
Suggest on-chain safeguards and process-level controls for each risk.

5. Cross-Chain Bridge Threat Model

I will provide the design of a cross-chain bridge and the Solidity code for the on-chain component.
Generate a threat model that covers:
- Message verification failures
- Replay attacks
- Oracle or relayer compromise
- Liquidity draining scenarios
- Chain re-org and finality assumptions.
For each threat, explain the exact sequence of steps an attacker would take and the contractual weaknesses they would exploit.

6. NFT and Royalty System Threats

Consider this NFT contract and royalty mechanism.
Identify threats related to:
- Unauthorized minting or airdrops
- Royalty bypassing on secondary markets
- Metadata manipulation (including off-chain dependencies)
- Misuse of operator and approval flows.
Output: a bullet list with attack narrative and mitigation suggestions.

7. Stablecoin or Collateralized Lending Protocol

Given the contracts for this collateralized lending or stablecoin protocol, provide:
- A list of key economic invariants that must always hold (e.g., solvency, collateral ratio constraints).
- A threat model focused on invariant breaks: how might price manipulation, oracle lag, or rounding issues break these invariants.
- Any design patterns that historically led to incidents in similar protocols and whether they appear here.

8. Threat Model Comparison Across Implementations

I will give you two different smart contract implementations that claim to implement the same protocol.
Produce a comparative threat model:
- Identify where their trust assumptions differ.
- List threats that exist in one implementation but not the other.
- Highlight any safer patterns in one implementation that could be ported to the other.

Vulnerability Discovery Prompts (9-18)

9. Focused Vulnerability Scan (General)

Act as a professional Solidity security auditor.
Analyze the following contract for vulnerabilities.
1) First, give a concise summary of what the contract does.
2) Then list potential vulnerabilities categorized by severity (Critical, High, Medium, Low, Informational).
3) For each vulnerability, include:
- Code snippet and line reference
- Exploit scenario (step by step)
- Conditions required for exploitation.
Assume an untrusted, financially motivated attacker.

10. Reentrancy-Focused Analysis

Review the following Solidity contract specifically for reentrancy and related issues.
- Identify all external calls that may be reentered (e.g., call, delegatecall, token transfers).
- For each, determine whether it is protected by checks-effects-interactions, reentrancy guards, or other patterns.
- Propose at least three concrete reentrancy attack scenarios if any exist, including possible combinations of functions and contracts.
If you believe there is no exploitable reentrancy, explain why.

11. Access Control and Authorization Review

Analyze this contract with a focus on access control.
- Enumerate all privileged roles (e.g., owner, admin, guardians) and the functions they can call.
- Identify any functions that should be restricted but are not, or that are too broadly accessible.
- Flag any single points of failure where one key or role can unilaterally compromise user funds or protocol integrity.
- Suggest principle-of-least-privilege modifications.

12. Integer and Arithmetic Safety

Review this Solidity contract for arithmetic-related issues:
- Integer overflows or underflows (including in Solidity 0.8.x if using unchecked blocks).
- Rounding errors that may cause imbalance in accounting logic.
- Division-by-zero risks or misuse of fixed-point math.
- Fee calculation or share-distribution bugs.
Provide examples of specific input values that would trigger problematic behavior.

13. Invariant and State Machine Analysis

Treat this contract as a state machine.
1) Identify its distinct states and transitions.
2) List invariants that should always hold between functions and across states.
3) Check whether there are any functions that can break these invariants.
4) Report any such violations as vulnerabilities, with concrete call sequences.

14. Upgradeability and Storage Layout Issues

This contract uses an upgradeable proxy pattern.
Analyze it for:
- Storage layout errors (variable order changes, new variables inserted in the middle, missing storage gaps).
- Incorrectly implemented initializer or reinitializer logic.
- Functions that can accidentally reinitialize or reset critical state.
- Any possibility that an upgrade can be used as a backdoor to seize funds or disable withdrawals.
Provide concrete examples of problematic upgrades if found.

15. Oracle and Price Manipulation Risks

Act as a DeFi security researcher.
Focusing on oracle usage in this contract, identify:
- How price data or external data is obtained and trusted.
- Whether the protocol is vulnerable to manipulation via low-liquidity markets, flash loans, or timestamp manipulation.
- Any assumptions about off-chain feeds that, if broken, would result in loss of funds or bad debt.
Propose specific attack strategies an adversary might use, referencing the code paths involved.

16. Front-Running and MEV Analysis

Review the following contract from a front-running and MEV perspective.
- Identify user actions that can be sandwiched or front-run for profit.
- Locate any functions where parameters such as slippage, deadlines, or minimum returns are not adequately enforced.
- Describe at least two realistic MEV attack scenarios and the losses users would incur.
Suggest changes to parameters or logic to reduce MEV exposure.

17. NFT (ERC-721 or ERC-1155) Specific Review

Analyze this NFT contract for security and misuse issues, including:
- Unauthorized transfers or approvals
- Unsafe use of safeTransferFrom vs transferFrom
- Reentrancy via hooks or external calls in transfer/mint/burn paths
- Royalties logic that can be bypassed or drained.
Provide concrete examples of how an attacker or malicious marketplace might exploit these weaknesses.

18. Fuzzing and Property-Test Suggestions

Given this Solidity contract, propose a suite of fuzzing or property-based tests that would help uncover subtle bugs.
For each property, specify:
- What should always be true (the invariant or safety property).
- What random inputs or sequences should be generated.
- Any edge cases (e.g., zero values, max uint256, uncommon token behavior).
Output in a form that can be implemented using Foundry or Hardhat property testing.

Fix and Hardening Prompts (19-25)

19. Targeted Remediation Guidance

I will paste a list of vulnerabilities that were already identified in this contract, including code snippets.
For each vulnerability:
- Explain the root cause in one short paragraph.
- Propose a concrete code-level fix or mitigation, including modified Solidity code where appropriate.
- Mention any trade-offs or side effects of the fix (e.g., gas cost, complexity).
Output as a structured list.

20. Secure Refactor of a Risky Function

Act as a Solidity expert.
The following function has been flagged as risky due to [reason].
1) Rewrite this function in a more defensive style that eliminates the risk while preserving intended behavior.
2) Apply best practices such as checks-effects-interactions, explicit access control, and input validation.
3) Provide before/after code snippets and explain how the risk is mitigated.

21. Defense-in-Depth Design Review

Consider this entire contract (or protocol) and the known vulnerabilities that have been fixed.
Suggest defense-in-depth improvements that do not rely on a single control, such as:
- Additional require checks and invariants
- Circuit breakers or pausable patterns
- Rate limits or per-address caps
- Multi-sig controls or timelocks for admin operations.
For each suggestion, specify which class of attack it mitigates and how it interacts with existing controls.

22. Secure Pattern Recommendations

Based on the following contract and its functionality, recommend security patterns from established libraries (e.g., OpenZeppelin).
- Identify where Ownable, AccessControl, ReentrancyGuard, Pausable, SafeERC20, or UUPS/TransparentUpgradeableProxy patterns should be applied.
- Provide example integration code or refactors for each recommended pattern.
- Highlight any current homegrown patterns that should be replaced by standard, battle-tested implementations.

23. Gas Optimization with Security Constraints

Review this Solidity contract and identify gas optimizations that do not reduce security.
- Propose micro-optimizations only where they do not introduce new attack surfaces.
- Explicitly state the security assumptions you must maintain while applying each optimization.
- If an optimization trades safety for gas, explain the risk and mark it clearly as not recommended.

24. Incident Post-Mortem and Patch Validation

Assume that this contract has just suffered an exploit.
I will describe the exploit steps and provide the patched version of the contract.
- Validate whether the patch correctly closes the described exploit.
- Check for any residual or adjacent vulnerabilities introduced by the patch.
- Suggest additional tests or invariants that should be added to ensure the exploit cannot reoccur through a slightly different code path.

25. Pre-Audit Readiness Checklist

Act as a lead auditor preparing for a formal security audit of this smart contract system.
Based on the code and the protocol description, produce a pre-audit readiness checklist that includes:
- Documentation to prepare (specs, state diagrams, invariants, threat models).
- Tests and tooling to run beforehand (unit, integration, fuzzing, static analysis).
- Known high-risk areas that need additional internal review before an external audit.
Present the checklist in a prioritized order.

Practical Tips to Get Better Results from These Prompts

Constrain the output: ask for a table with severity, preconditions, exploit steps, and exact fixes.
Iterate deliberately: follow up with "show the call sequence," "write a Foundry test," or "identify the specific external call that enables reentry."
Feed real context: include compiler version, dependency list, upgrade model, and token assumptions (fee-on-transfer, rebasing, ERC-777 hooks).
Validate everything: reproduce exploit paths with tests, run static analyzers, and confirm patches through regression and property tests.

Conclusion

ChatGPT prompts for smart contract security are most effective when used as a structured assistant for threat modeling, targeted vulnerability discovery, and drafting fix recommendations. Results from security teams and published research consistently point to the same conclusion: LLMs can accelerate analysis of common issues, but they struggle with novel vulnerabilities, can hallucinate findings, and provide no formal guarantees. The safest approach keeps a human in the loop - use prompts to generate hypotheses, then confirm them with tools like Slither and fuzzing frameworks alongside manual audit review.

For teams looking to build repeatable engineering practices around smart contract security, structured training in secure development and security testing provides a strong foundation. Blockchain Council offers certification tracks in smart contract development and blockchain security for professionals at every stage of this work.