mcpField
S
solidity-checklist

solidity-checklist

github.com/0xlayerghostTesting & quality462 installsUpdated 2w ago
Repository

About solidity-checklist

solidity-checklist is a preflight skill for Solidity developers performing on-chain operations. Its six-step process checks permissions, dependencies, parameters, security, and local tests before execution, then verifies and records the outcome.

Key features

  1. 01Six-layer on-chain preflight flow
  2. 02Permission and dependency checks
  3. 03Parameter and security validation
  4. 04Local tests, simulations, and estimates
  5. 05Post-execution verification and notes

Use cases

  1. 01Check permissions and inputs before sending a transaction
  2. 02Review deployments or upgrades before execution
  3. 03Investigate failed transaction simulations

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/0xlayerghost/solidity-agent-kit --skill solidity-checklist

After installing, type/solidity-checklistin Claude Code to confirm it loaded.

Details

From the project README

Solidity Checklist

Language Rule

  • Always respond in the same language the user is using. If the user asks in Chinese, respond in Chinese. If in English, respond in English.

Why This Skill Exists

Most on-chain operation failures come from skipping systematic verification. Instead of the reactive loop:

deploy -> fail -> paste error -> ask AI -> retry -> fail again -> ask again

This skill enforces a proactive verification flow:

check permissions -> check dependencies -> check params -> check security -> test locally -> execute -> capture knowledge

The 6-Layer Preflight Flow

Every on-chain operation MUST pass through these 6 layers in order before execution.

Layer 1: PERMISSIONS  — Do I have the right to do this?
Layer 2: DEPENDENCIES — Do I understand what this affects?
Layer 3: PARAMETERS   — Are my inputs correct?
Layer 4: SECURITY     — Is this safe to execute?
Layer 5: TESTING      — Have I verified locally first?
Layer 6: EXECUTE & CAPTURE — Do it, then record what I learned.

Layer 1: Permissions Check

Before any on-chain call, verify the caller has the required access.

CheckCommandPass Condition
Contract ownercast call <CONTRACT> "owner()" --rpc-url <RPC>Returns expected deployer/admin address
Role-based accesscast call <CONTRACT> "hasRole(bytes32,address)" <ROLE_HASH> <CALLER> --rpc-url <RPC>Returns true
Whitelist statuscast call <CONTRACT> "isWhitelisted(address)" <CALLER> --rpc-url <RPC>Returns true (if applicable)
Token allowancecast call <TOKEN> "allowance(address,address)" <OWNER> <SPENDER> --rpc-url <RPC>Returns >= required amount
Paused statecast call <CONTRACT> "paused()" --rpc-url <RPC>Returns false
Decision Rule
ResultAction
All checks passProceed to Layer 2
Missing permissionFix permission first (grant role / approve / unpause), then re-check
Unsure which permissions are neededRead contract source — find all onlyOwner, onlyRole, require in target function

Layer 2: Dependency Check

Understand the blast radius — what contracts and state does this operation touch?

CheckHow
Direct dependenciesRead target function source — list all external calls (IERC20(token).transfer(...), etc.)
Upstream contractsWhich contracts hold a reference to this contract's address?
Downstream effectsWill this state change trigger callbacks, events, or off-chain indexers?
Initialization statecast call <CONTRACT> "initialized()" --rpc-url <RPC> — is the contract fully set up?
Linked addressesVerify all addresses stored in contract state are correct and not zero
Dependency Map Template

Before operating on a multi-contract system, build a mental (or written) map:

ContractA (owner: deployer)
  ├── references: TokenB (ERC20), RouterC
  ├── authorized callers: deployer, ContractD
  └── state deps: must be initialized, TokenB must be approved

ContractD (owner: deployer)
  ├── references: ContractA, OracleE
  └── state deps: OracleE must have price feed set
Decision Rule
ResultAction
Dependencies clearProceed to Layer 3
Unknown dependencyRead contract source or ask — do NOT proceed blindly
Redeployment neededTrace the full dependency graph to identify ALL contracts needing address updates

Layer 3: Parameter Validation

Verify every input before sending.

CheckCommon Pitfall
Address formatWrong network address, zero address, checksum mismatch
Token decimalsUsing 18 decimals for a 6-decimal token (USDC/USDT)
Amount precision1e18 vs 1e6 — off by 12 orders of magnitude
Function selectorCalling wrong function or wrong overload
Enum valuesPassing invalid enum index
Array lengthMismatched array lengths in batch operations
Deadline/timestampExpired deadline, wrong timezone, block.timestamp vs unix
Validation Commands
# Check token decimals before calculating amounts
cast call <TOKEN> "decimals()" --rpc-url <RPC>

# Verify address is a contract (not EOA)
cast code <ADDRESS> --rpc-url <RPC>
# Empty (0x) = EOA, non-empty = contract

# Decode your own calldata to double-check
cast calldata-decode "functionName(type1,type2)" <CALLDATA>

# Estimate gas before sending (catches obvious reverts)
cast estimate <CONTRACT> "functionName(args)" --from <CALLER> --rpc-url <RPC>
Decision Rule
ResultAction
All params verifiedProceed to Layer 4
Decimal mismatch foundRecalculate with correct decimals
Address is EOA, expected contractWrong address — verify deployment

Layer 4: Security Quick Check

Scan for common security risks before execution.

RiskCheckRed Flag
ReentrancyDoes the function make external calls before updating state?External call before state update
Front-runningIs this a price-sensitive operation (swap, liquidation)?No slippage protection or deadline
Access controlDoes the function restrict callers appropriately?Missing onlyOwner / onlyRole on sensitive function
Value handlingDoes the function handle msg.value correctly?Accepts ETH but doesn't use it, or vice versa
Approval amountAm I approving more than necessary?approve(spender, type(uint256).max) on unknown contract
Private key exposureDid the developer choose keystore or a gitignored .env?Literal private key in a command, script, log, or committed file
Private Key Rule (MANDATORY)
# NEVER put a literal private key in the command
cast send ... --private-key 0xdead...

# Option A: Foundry Keystore (recommended)
cast send ... --account <KEYSTORE_NAME>

# Set up keystore if not done
cast wallet import <NAME> --interactive

# Option B: load PRIVATE_KEY from a gitignored .env
source .env
cast send ... --private-key "$PRIVATE_KEY"

Let the developer choose Option A or Option B before execution. Never read, print, or commit .env.

Decision Rule
ResultAction
No red flagsProceed to Layer 5
Reentrancy risk foundAdd ReentrancyGuard or fix CEI pattern before proceeding
Front-running riskAdd slippage/deadline params
Private key exposedSTOP — rotate the key, then use keystore or a gitignored .env

Layer 5: Local Testing

Never send a transaction that hasn't been verified locally or on a fork.

MethodCommandWhen to Use
Unit testforge test --match-test <testName> -vvvvNew/modified contract functions
Fork testforge test --fork-url <RPC> --match-test <testName> -vvvvTesting against live state
Dry-run scriptforge script <Script> --rpc-url <RPC> -vvvv (no --broadcast)Deployment or complex operations
Gas estimationcast estimate <CONTRACT> "func(args)" --from <CALLER> --rpc-url <RPC>Before any cast send
Simulationcast call <CONTRACT> "func(args)" --from <CALLER> --rpc-url <RPC>Quick function call test
Testing Decision Tree
Is this a new or modified contract?
├── YES → Write forge test → Run test → Pass? → Proceed
│                                      → Fail? → Fix and re-test
└── NO (calling existing deployed contract)
    ├── Simple read? → cast call (Layer 3 already covers this)
    └── State-changing? → cast estimate first
        ├── Estimate succeeds → Proceed to Layer 6
        └── Estimate reverts → Debug with cast call + revert reason → Fix → Re-estimate
Decision Rule
ResultAction
Test passes / estimate succeedsProceed to Layer 6
Test failsFix the issue — do NOT deploy broken code
Estimate revertsLikely a Layer 1 (permissions) or Layer 3 (params) issue — go back

Layer 6: Execute & Capture

Execute the operation, verify success, and capture knowledge.

Execute
# Option A: send transaction using Foundry Keystore (recommended)
cast send <CONTRACT> "functionName(type1,type2)" <arg1> <arg2> \
  --account <KEYSTORE_NAME> \
  --rpc-url <RPC>

# Option A: deploy using Foundry Keystore
forge script <Script> \
  --rpc-url <RPC> \
  --account <KEYSTORE_NAME> \
  --broadcast \
  --gas-limit <LIMIT> \
  -vvvv

# Option B: load PRIVATE_KEY from a gitignored .env, then send or deploy
source .env
cast send <CONTRACT> "functionName(type1,type2)" <arg1> <arg2> \
  --private-key "$PRIVATE_KEY" \
  --rpc-url <RPC>

forge script <Script> \
  --rpc-url <RPC> \
  --private-key "$PRIVATE_KEY" \
  --broadcast \
  --gas-limit <LIMIT> \
  -vvvv
Post-Execution Verification (MANDATORY)
CheckCommand
TX statusCheck status field in receipt: 1 = success, 0 = fail
State changecast call to verify the expected state change happened
Events emittedCheck logs in receipt for expected events
Balance changecast balance or cast call balanceOf to verify token movements
Knowledge Capture

After every successful (or failed) operation, capture what you learned:

What to RecordWhere
Successful command with parametersPersonal command handbook (.md file)
New error encountered + solutionDebug notes
Contract address and its roleProject architecture doc
Permission/role requirements discoveredContract dependency map
Gas cost of common operationsGas reference table
Anti-Pattern: One-Time Consumption

The biggest leverage: turn every AI interaction into your own knowledge, not a one-time consumption.

If you asked AI for a command and it worked:

  1. Understand WHY each parameter is what it is
  2. Record it in your own words
  3. Next time, write it yourself first — then verify with AI

Quick Reference: Preflight by Operation Type

OperationCritical LayersMost Common Failure
approveL1 (owner), L3 (amount/decimals)Wrong decimals
transferL1 (balance), L3 (amount/decimals)Insufficient balance
addLiquidityL1 (approve both tokens), L3 (amounts/ratio), L5 (estimate)Missing approval
removeLiquidityL1 (LP approve), L3 (minAmounts), L4 (slippage)Slippage too tight
stakeL1 (approve + whitelist), L2 (staking contract state), L3 (amount)Staking not active / not whitelisted
unstakeL1 (staker status), L2 (lock period), L3 (amount)Lock period not expired
deployL3 (constructor args), L4 (full security check), L5 (fork test mandatory)Constructor arg mismatch
upgradeL1 (proxy admin), L2 (storage layout), L4 (storage collision), L5 (fork test mandatory)Storage layout incompatible

Preflight Summary Card

Print this mental checklist before EVERY on-chain operation:

[ ] L1 PERMISSIONS  — Can I call this? (owner/role/approve/whitelist/paused)
[ ] L2 DEPENDENCIES — What does this touch? (contracts/state/events)
[ ] L3 PARAMETERS   — Are inputs correct? (address/decimals/amount/selector)
[ ] L4 SECURITY     — Is this safe? (reentrancy/frontrun/key exposure)
[ ] L5 TESTING      — Did I test locally? (forge test/estimate/dry-run)
[ ] L6 EXECUTE      — Send it, verify it, record what I learned.

6 layers, 2 minutes. Saves hours of debugging and wasted gas.

Comments

Markdown supported