Back to Security & Vulnerability Analysis

solidity-security

soliditysmart contractsblockchainsecurityauditingvulnerabilitiesdefiweb3
36.8k📄 MIT🕒 2026-06-16Source ↗

Install this skill

npx skills add wshobson/agents

Works across Claude Code, Cursor, Codex, Copilot & Antigravity

The solidity-security skill provides automated analysis and remediation patterns for smart contract development. It enforces the Checks-Effects-Interactions paradigm to mitigate reentrancy attacks, mandates overflow/underflow handling, and validates access control implementation. By integrating standard libraries like OpenZeppelin’s ReentrancyGuard and Ownable, this skill helps identify high-risk code segments before deployment. It covers both legacy Solidity versions requiring SafeMath and modern 0.8+ syntax, while providing tactical mitigations for complex issues like front-running in decentralized exchanges. This tool ensures that your contract logic adheres to established security standards, protecting treasury assets and user balances from common exploits found in the EVM environment. It serves as a static analysis partner that scans for logical vulnerabilities and advises on the secure architectural adjustments required for mainnet-ready code.

When to Use This Skill

  • Refactoring withdrawal functions to prevent reentrancy
  • Updating legacy smart contracts to utilize compiler-native overflow checks
  • Implementing role-based access control for administrative functions
  • Securing DEX swap logic against mempool-based exploitation

How to Invoke This Skill

Example prompts that trigger this skill in Claude Code, Cursor, or Antigravity:

  • Fix reentrancy issues in my withdrawal function
  • How do I secure my smart contract against unauthorized access?
  • Check my code for potential integer overflow vulnerabilities
  • Implement a ReentrancyGuard in this contract
  • Refactor this function to prevent front-running attacks

Pro Tips

  • 💡Prioritize a "Security-First" Mindset: Always consider potential attack vectors from the very first line of code. Use this skill as a constant checklist during development to proactively build secure contracts.
  • 💡Combine with Manual Review: While this skill provides excellent guidance and identifies common pitfalls, always complement its suggestions with thorough manual code reviews by experienced security auditors.
  • 💡Utilize Static Analysis Tools: Integrate automated tools like Slither or MythX into your CI/CD pipeline alongside this skill's insights for an even stronger, multi-layered security posture.

What this skill does

  • Checks-Effects-Interactions code refactoring
  • Automated access control pattern enforcement
  • Arithmetic overflow/underflow security auditing
  • ReentrancyGuard implementation guidance
  • Front-running mitigation via commit-reveal schemas

When not to use it

  • Performing full-scale independent third-party security audits
  • Analyzing non-EVM based smart contract languages like Rust or Move
  • Replacing comprehensive unit and integration testing suites

Example workflow

  1. Provide the Solidity contract source code to the agent
  2. Agent scans for identified vulnerability patterns
  3. Agent refactors vulnerable functions using best practices
  4. Agent suggests specific OpenZeppelin imports
  5. Agent explains the security trade-offs of the changes
  6. Review and integrate the suggested secure code snippets

Prerequisites

  • Access to Solidity source files
  • Fundamental understanding of EVM storage and call patterns

Pitfalls & limitations

  • !Non-reentrant modifiers may increase gas consumption slightly
  • !Commit-reveal patterns add complexity to user interaction flow
  • !Automated fixes might not account for complex multi-contract logic interdependencies

FAQ

Do I still need SafeMath if I use Solidity 0.8.0 or higher?
No, Solidity 0.8.0 introduced native overflow and underflow checks that automatically revert the transaction, making SafeMath unnecessary for standard arithmetic.
Is ReentrancyGuard enough to keep my contract safe?
While it effectively prevents reentrancy, it is only one layer of security. You must still follow the Checks-Effects-Interactions pattern and conduct thorough external audits.
How can I prevent users from front-running my exchange orders?
Use a commit-reveal scheme where the user submits a hash of their transaction first and performs the actual execution in a subsequent block.

How it compares

Unlike generic code reviewers, this skill applies specific EVM-aware security primitives and provides drop-in fixes based on industry-standard libraries.

Source & trust

37k stars📄 MIT🕒 Updated 2026-06-16
📄 Full skill instructions — original source: wshobson/agents
# Solidity Security

Master smart contract security best practices, vulnerability prevention, and secure Solidity development patterns.

## When to Use This Skill

- Writing secure smart contracts
- Auditing existing contracts for vulnerabilities
- Implementing secure DeFi protocols
- Preventing reentrancy, overflow, and access control issues
- Optimizing gas usage while maintaining security
- Preparing contracts for professional audits
- Understanding common attack vectors

## Critical Vulnerabilities

### 1. Reentrancy

Attacker calls back into your contract before state is updated.

**Vulnerable Code:**

// VULNERABLE TO REENTRANCY
contract VulnerableBank {
mapping(address => uint256) public balances;

function withdraw() public {
uint256 amount = balances[msg.sender];

// DANGER: External call before state update
(bool success, ) = msg.sender.call{value: amount}("");
require(success);

balances[msg.sender] = 0; // Too late!
}
}


**Secure Pattern (Checks-Effects-Interactions):**

contract SecureBank {
mapping(address => uint256) public balances;

function withdraw() public {
uint256 amount = balances[msg.sender];
require(amount > 0, "Insufficient balance");

// EFFECTS: Update state BEFORE external call
balances[msg.sender] = 0;

// INTERACTIONS: External call last
(bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
}
}


**Alternative: ReentrancyGuard**

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SecureBank is ReentrancyGuard {
mapping(address => uint256) public balances;

function withdraw() public nonReentrant {
uint256 amount = balances[msg.sender];
require(amount > 0, "Insufficient balance");

balances[msg.sender] = 0;

(bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
}
}


### 2. Integer Overflow/Underflow

**Vulnerable Code (Solidity < 0.8.0):**

// VULNERABLE
contract VulnerableToken {
mapping(address => uint256) public balances;

function transfer(address to, uint256 amount) public {
// No overflow check - can wrap around
balances[msg.sender] -= amount; // Can underflow!
balances[to] += amount; // Can overflow!
}
}


**Secure Pattern (Solidity >= 0.8.0):**

// Solidity 0.8+ has built-in overflow/underflow checks
contract SecureToken {
mapping(address => uint256) public balances;

function transfer(address to, uint256 amount) public {
// Automatically reverts on overflow/underflow
balances[msg.sender] -= amount;
balances[to] += amount;
}
}


**For Solidity < 0.8.0, use SafeMath:**

import "@openzeppelin/contracts/utils/math/SafeMath.sol";

contract SecureToken {
using SafeMath for uint256;
mapping(address => uint256) public balances;

function transfer(address to, uint256 amount) public {
balances[msg.sender] = balances[msg.sender].sub(amount);
balances[to] = balances[to].add(amount);
}
}


### 3. Access Control

**Vulnerable Code:**

// VULNERABLE: Anyone can call critical functions
contract VulnerableContract {
address public owner;

function withdraw(uint256 amount) public {
// No access control!
payable(msg.sender).transfer(amount);
}
}


**Secure Pattern:**

import "@openzeppelin/contracts/access/Ownable.sol";

contract SecureContract is Ownable {
function withdraw(uint256 amount) public onlyOwner {
payable(owner()).transfer(amount);
}
}

// Or implement custom role-based access
contract RoleBasedContract {
mapping(address => bool) public admins;

modifier onlyAdmin() {
require(admins[msg.sender], "Not an admin");
_;
}

function criticalFunction() public onlyAdmin {
// Protected function
}
}


### 4. Front-Running

**Vulnerable:**

// VULNERABLE TO FRONT-RUNNING
contract VulnerableDEX {
function swap(uint256 amount, uint256 minOutput) public {
// Attacker sees this in mempool and front-runs
uint256 output = calculateOutput(amount);
require(output >= minOutput, "Slippage too high");
// Perform swap
}
}


**Mitigation:**

contract SecureDEX {
mapping(bytes32 => bool) public usedCommitments;

// Step 1: Commit to trade
function commitTrade(bytes32 commitment) public {
usedCommitments[commitment] = true;
}

// Step 2: Reveal trade (next block)
function revealTrade(
uint256 amount,
uint256 minOutput,
bytes32 secret
) public {
bytes32 commitment = keccak256(abi.encodePacked(
msg.sender, amount, minOutput, secret
));
require(usedCommitments[commitment], "Invalid commitment");
// Perform swap
}
}


## Security Best Practices

### Checks-Effects-Interactions Pattern

contract SecurePattern {
mapping(address => uint256) public balances;

function withdraw(uint256 amount) public {
// 1. CHECKS: Validate conditions
require(amount <= balances[msg.sender], "Insufficient balance");
require(amount > 0, "Amount must be positive");

// 2. EFFECTS: Update state
balances[msg.sender] -= amount;

// 3. INTERACTIONS: External calls last
(bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
}
}


### Pull Over Push Pattern

// Prefer this (pull)
contract SecurePayment {
mapping(address => uint256) public pendingWithdrawals;

function recordPayment(address recipient, uint256 amount) internal {
pendingWithdrawals[recipient] += amount;
}

function withdraw() public {
uint256 amount = pendingWithdrawals[msg.sender];
require(amount > 0, "Nothing to withdraw");

pendingWithdrawals[msg.sender] = 0;
payable(msg.sender).transfer(amount);
}
}

// Over this (push)
contract RiskyPayment {
function distributePayments(address[] memory recipients, uint256[] memory amounts) public {
for (uint i = 0; i < recipients.length; i++) {
// If any transfer fails, entire batch fails
payable(recipients[i]).transfer(amounts[i]);
}
}
}


### Input Validation

contract SecureContract {
function transfer(address to, uint256 amount) public {
// Validate inputs
require(to != address(0), "Invalid recipient");
require(to != address(this), "Cannot send to contract");
require(amount > 0, "Amount must be positive");
require(amount <= balances[msg.sender], "Insufficient balance");

// Proceed with transfer
balances[msg.sender] -= amount;
balances[to] += amount;
}
}


### Emergency Stop (Circuit Breaker)

import "@openzeppelin/contracts/security/Pausable.sol";

contract EmergencyStop is Pausable, Ownable {
function criticalFunction() public whenNotPaused {
// Function logic
}

function emergencyStop() public onlyOwner {
_pause();
}

function resume() public onlyOwner {
_unpause();
}
}


## Gas Optimization

### Use uint256 Instead of Smaller Types

// More gas efficient
contract GasEfficient {
uint256 public value; // Optimal

function set(uint256 _value) public {
value = _value;
}
}

// Less efficient
contract GasInefficient {
uint8 public value; // Still uses 256-bit slot

function set(uint8 _value) public {
value = _value; // Extra gas for type conversion
}
}


### Pack Storage Variables

// Gas efficient (3 variables in 1 slot)
contract PackedStorage {
uint128 public a; // Slot 0
uint64 public b; // Slot 0
uint64 public c; // Slot 0
uint256 public d; // Slot 1
}

// Gas inefficient (each variable in separate slot)
contract UnpackedStorage {
uint256 public a; // Slot 0
uint256 public b; // Slot 1
uint256 public c; // Slot 2
uint256 public d; // Slot 3
}


### Use calldata Instead of memory for Function Arguments

contract GasOptimized {
// More gas efficient
function processData(uint256[] calldata data) public pure returns (uint256) {
return data[0];
}

// Less efficient
function processDataMemory(uint256[] memory data) public pure returns (uint256) {
return data[0];
}
}


### Use Events for Data Storage (When Appropriate)

contract EventStorage {
// Emitting events is cheaper than storage
event DataStored(address indexed user, uint256 indexed id, bytes data);

function storeData(uint256 id, bytes calldata data) public {
emit DataStored(msg.sender, id, data);
// Don't store in contract storage unless needed
}
}


## Common Vulnerabilities Checklist

// Security Checklist Contract
contract SecurityChecklist {
/**
* [ ] Reentrancy protection (ReentrancyGuard or CEI pattern)
* [ ] Integer overflow/underflow (Solidity 0.8+ or SafeMath)
* [ ] Access control (Ownable, roles, modifiers)
* [ ] Input validation (require statements)
* [ ] Front-running mitigation (commit-reveal if applicable)
* [ ] Gas optimization (packed storage, calldata)
* [ ] Emergency stop mechanism (Pausable)
* [ ] Pull over push pattern for payments
* [ ] No delegatecall to untrusted contracts
* [ ] No tx.origin for authentication (use msg.sender)
* [ ] Proper event emission
* [ ] External calls at end of function
* [ ] Check return values of external calls
* [ ] No hardcoded addresses
* [ ] Upgrade mechanism (if proxy pattern)
*/
}


## Testing for Security

// Hardhat test example
const { expect } = require("chai");
const { ethers } = require("hardhat");

describe("Security Tests", function () {
it("Should prevent reentrancy attack", async function () {
const [attacker] = await ethers.getSigners();

const VictimBank = await ethers.getContractFactory("SecureBank");
const bank = await VictimBank.deploy();

const Attacker = await ethers.getContractFactory("ReentrancyAttacker");
const attackerContract = await Attacker.deploy(bank.address);

// Deposit funds
await bank.deposit({ value: ethers.utils.parseEther("10") });

// Attempt reentrancy attack
await expect(
attackerContract.attack({ value: ethers.utils.parseEther("1") }),
).to.be.revertedWith("ReentrancyGuard: reentrant call");
});

it("Should prevent integer overflow", async function () {
const Token = await ethers.getContractFactory("SecureToken");
const token = await Token.deploy();

// Attempt overflow
await expect(token.transfer(attacker.address, ethers.constants.MaxUint256))
.to.be.reverted;
});

it("Should enforce access control", async function () {
const [owner, attacker] = await ethers.getSigners();

const Contract = await ethers.getContractFactory("SecureContract");
const contract = await Contract.deploy();

// Attempt unauthorized withdrawal
await expect(contract.connect(attacker).withdraw(100)).to.be.revertedWith(
"Ownable: caller is not the owner",
);
});
});


## Audit Preparation

contract WellDocumentedContract {
/**
* @title Well Documented Contract
* @dev Example of proper documentation for audits
* @notice This contract handles user deposits and withdrawals
*/

/// @notice Mapping of user balances
mapping(address => uint256) public balances;

/**
* @dev Deposits ETH into the contract
* @notice Anyone can deposit funds
*/
function deposit() public payable {
require(msg.value > 0, "Must send ETH");
balances[msg.sender] += msg.value;
}

/**
* @dev Withdraws user's balance
* @notice Follows CEI pattern to prevent reentrancy
* @param amount Amount to withdraw in wei
*/
function withdraw(uint256 amount) public {
// CHECKS
require(amount <= balances[msg.sender], "Insufficient balance");

// EFFECTS
balances[msg.sender] -= amount;

// INTERACTIONS
(bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
}
}


## Resources

- **references/reentrancy.md**: Comprehensive reentrancy prevention
- **references/access-control.md**: Role-based access patterns
- **references/overflow-underflow.md**: SafeMath and integer safety
- **references/gas-optimization.md**: Gas saving techniques
- **references/vulnerability-patterns.md**: Common vulnerability catalog
- **assets/solidity-contracts-templates.sol**: Secure contract templates
- **assets/security-checklist.md**: Pre-audit checklist
- **scripts/analyze-contract.sh**: Static analysis tools

## Tools for Security Analysis

- **Slither**: Static analysis tool
- **Mythril**: Security analysis tool
- **Echidna**: Fuzzing tool
- **Manticore**: Symbolic execution
- **Securify**: Automated security scanner

## Common Pitfalls

1. **Using tx.origin for Authentication**: Use msg.sender instead
2. **Unchecked External Calls**: Always check return values
3. **Delegatecall to Untrusted Contracts**: Can hijack your contract
4. **Floating Pragma**: Pin to specific Solidity version
5. **Missing Events**: Emit events for state changes
6. **Excessive Gas in Loops**: Can hit block gas limit
7. **No Upgrade Path**: Consider proxy patterns if upgrades needed

How to Use This Skill Unit

Option A: Project-Specific (Recommended)

  1. Click "Download" above
  2. In your project, create the directory: .agent/skills/solidity-security/
  3. Save the file as SKILL.md
  4. The agent will automatically discover the skill based on its description.

Option B: Global Installation (All Agents)

Save the file to these locations to make it available across all projects:

  • Claude Code: ~/.claude/skills/wshobson/agents/solidity-security/SKILL.md
  • Cursor: ~/.cursor/skills/wshobson/agents/solidity-security/SKILL.md
  • Antigravity: ~/.gemini/antigravity/skills/wshobson/agents/solidity-security/SKILL.md

🚀 Install with CLI:
npx skills add wshobson/agents

Read the Master Guide: Mastering Agent Skills

Recommended Rules

View more rules

Recommended Workflows

View more workflows

Recommended MCP Servers

View more MCP servers

Take It Further

Maximize your productivity with these powerful resources

📋

Define Your Standards

Set up coding standards to ensure this workflow produces consistent, high-quality results.

Browse Rules Library
📖

Master Workflows

Learn how to create custom workflows, use Turbo Mode, and build your automation library.

Complete Guide

How to use this Skill in Claude Code & Cursor

For Claude Code (CLI)

To use this skill in Claude Code, copy the rule content into your project's custom instructions or follow our Add-Skill CLI guide. This ensures Claude follows your standards during every code generation.

For Cursor & Windsurf

For Cursor or Windsurf, individual skills are best used in the "Rules for AI" section. This specific unit helps the agent avoid security & vulnerability analysis issues, leading to cleaner, more efficient code.

Why the skill format matters: the standardized Agent Skills format lets your AI agent load detailed instructions only when they are relevant, keeping your prompt clean while improving results.

Source & attribution

This skill is categorized under Security & Vulnerability Analysis and is published by W. Shobson, maintained in wshobson/agents.

← Browse All Agent Skills
Sponsored AI assistant. Recommendations may be paid.