solidity-checklist

Solidity チェックリスト

言語ルール

• 常にユーザーが使用している言語で応答してください。 ユーザーが中国語で質問した場合は、中国語で応答してください。英語で質問した場合は、英語で応答してください。

このスキルが必要な理由

オンチェーン操作の失敗のほとんどは、体系的な検証を省略することから発生します。次のような事後対応の繰り返しではなく、

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

このスキルでは、事前検証のフローを徹底します。

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

6 層の事前確認フロー

すべてのオンチェーン操作は、実行前に次の 6 層を順番どおりに通過する必要があります。

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.

---

レイヤー 1：権限の確認

オンチェーンの呼び出しを行う前に、呼び出し元に必要なアクセス権があることを確認してください。

確認項目	コマンド	合格条件
コントラクトの所有者	cast call <CONTRACT> "owner()" --rpc-url <RPC>	想定されるデプロイヤー／管理者のアドレスが返される
ロールベースのアクセス制御	cast call <CONTRACT> "hasRole(bytes32,address)" <ROLE_HASH> <CALLER> --rpc-url <RPC>	true が返される
ホワイトリストの状態	cast call <CONTRACT> "isWhitelisted(address)" <CALLER> --rpc-url <RPC>	true が返される（該当する場合）
トークンの使用許可	cast call <TOKEN> "allowance(address,address)" <OWNER> <SPENDER> --rpc-url <RPC>	必要額以上が返される
一時停止の状態	cast call <CONTRACT> "paused()" --rpc-url <RPC>	false が返される

判断基準

結果	アクション
すべての確認に合格	レイヤー 2 に進む
権限が不足している	まず権限を付与する（ロールの付与／承認／一時停止解除）ための対応を行い、再確認する
必要な権限が不明	コントラクトのソースを読み、対象関数内のすべての onlyOwner、onlyRole、require を確認する

---

レイヤー 2：依存関係の確認

影響範囲を把握します。この操作で、どのコントラクトや状態に影響が及ぶでしょうか？

確認項目	方法
直接的な依存関係	対象関数のソースを読み、すべての外部呼び出し（IERC20(token).transfer(...) など）を列挙する
上流コントラクト	このコントラクトのアドレスを参照しているコントラクトはどれか？
下流への影響	この状態変更によってコールバック、イベント、オフチェーンのインデクサーが動作するか？
初期化の状態	cast call <CONTRACT> "initialized()" --rpc-url <RPC> — コントラクトのセットアップは完全に完了しているか？
関連アドレス	コントラクトの状態に保存されているすべてのアドレスが正しく、ゼロアドレスでないことを確認する

依存関係マップのテンプレート

複数のコントラクトからなるシステムを操作する前に、関係を頭の中で（または書き出して）マップ化してください。

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

判断基準

結果	アクション
依存関係が明確	レイヤー 3 に進む
不明な依存関係がある	コントラクトのソースを読むか、質問する — やみくもに進めてはいけません
再デプロイが必要	依存関係グラフ全体をたどり、アドレスの更新が必要なすべてのコントラクトを特定する

---

レイヤー 3：パラメーターの検証

送信前に、すべての入力を確認します。

確認項目	よくある落とし穴
アドレス形式	ネットワークのアドレスが違う、ゼロアドレス、チェックサムの不一致
トークンの小数桁数	6 桁のトークン（USDC／USDT）に 18 桁を使用する
金額の精度	1e18 と 1e6 の違い — 12 桁ずれている
関数セレクター	誤った関数またはオーバーロードを呼び出す
Enum 値	無効な Enum インデックスを渡す
配列の長さ	バッチ操作で配列の長さが一致しない
期限／タイムスタンプ	期限切れ、タイムゾーンの誤り、block.timestamp と Unix 時刻の混同

検証コマンド

# 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>

判断基準

結果	アクション
すべてのパラメーターを検証済み	レイヤー 4 に進む
小数桁数の不一致が見つかった	正しい小数桁数で再計算する
想定はコントラクトだが、アドレスが EOA	アドレスが誤っている — デプロイを確認する

---

レイヤー 4：セキュリティの簡易チェック

実行前に、よくあるセキュリティリスクをスキャンします。

リスク	確認事項	危険な兆候
再入可能性	状態を更新する前に、関数が外部呼び出しを行いますか？	状態更新前の外部呼び出し
フロントランニング	価格に影響される操作（スワップ、清算）ですか？	スリッページ保護または期限がない
アクセス制御	関数は呼び出し元を適切に制限していますか？	機密性の高い関数に onlyOwner ／ onlyRole がない
値の処理	関数は msg.value を正しく処理していますか？	ETH を受け取るのに使用しない、またはその逆
承認額	必要以上の額を承認していませんか？	不明なコントラクトに対する approve(spender, type(uint256).max)
秘密鍵の露出	開発者はキーストアまたは Git の追跡対象外の .env を選びましたか？	コマンド、スクリプト、ログ、またはコミット済みファイル内に秘密鍵が直接記載されている

秘密鍵のルール（必須）

# 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"

実行前に、開発者にオプション A またはオプション B を選んでもらいます。.env を読み取ったり、表示したり、コミットしたりしてはいけません。

判断基準

結果	対応
危険な兆候なし	レイヤー 5 に進む
再入可能性のリスクが見つかった	続行する前に ReentrancyGuard を追加するか、CEI パターンを修正する
フロントランニングのリスク	スリッページ／期限のパラメーターを追加する
秘密鍵が露出している	停止 — 鍵をローテーションしてから、キーストアまたは Git の追跡対象外の .env を使用する

---

レイヤー 5：ローカルテスト

ローカルまたはフォーク上で検証していないトランザクションを送信してはいけません。

方法	コマンド	使用する場面
単体テスト	forge test --match-test <testName> -vvvv	新規または変更したコントラクト関数
フォークテスト	forge test --fork-url <RPC> --match-test <testName> -vvvv	ライブ状態に対するテスト
ドライランスクリプト	forge script <Script> --rpc-url <RPC> -vvvv（--broadcast なし）	デプロイまたは複雑な操作
ガス見積もり	cast estimate <CONTRACT> "func(args)" --from <CALLER> --rpc-url <RPC>	cast send の実行前
シミュレーション	cast call <CONTRACT> "func(args)" --from <CALLER> --rpc-url <RPC>	関数呼び出しの簡易テスト

テストの判断フロー

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

判断基準

結果	対応
テスト成功／見積もり成功	レイヤー 6 に進む
テスト失敗	問題を修正する — 壊れたコードをデプロイしてはいけません
見積もりがリバート	レイヤー 1（権限）またはレイヤー 3（パラメーター）の問題と考えられます — 戻って確認してください

---

レイヤー 6：実行と記録

操作を実行し、成功を検証して、得た知識を記録します。

実行

# 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

実行後の検証（必須）

確認項目	コマンド
TX ステータス	レシートの status フィールドを確認します：1 = 成功、0 = 失敗
状態変更	cast call で期待どおりの状態変更が起きたことを確認します
イベント発行	レシートの logs で期待されるイベントを確認します
残高変更	cast balance または cast call balanceOf でトークンの移動を確認します

知識の記録

操作が成功した場合も失敗した場合も、毎回学んだことを記録します。

記録する内容	場所
パラメーター付きの成功したコマンド	個人用コマンドハンドブック（.md ファイル）
新たに遭遇したエラーとその解決策	デバッグメモ
コントラクトアドレスとその役割	プロジェクトアーキテクチャドキュメント
判明した権限／ロールの要件	コントラクト依存関係マップ
一般的な操作のガスコスト	ガス参照表

アンチパターン：一度きりの消費

最大の効果は、AI とのやり取りを使い捨てにせず、すべて自分の知識に変えることです。

AI にコマンドを尋ねて、それがうまくいった場合：

1. 各パラメーターがその値である理由を理解します
2. 自分の言葉で記録します
3. 次回は、まず自分で書いてから、AI で確認します

---

操作タイプ別クイックリファレンス

操作	重要なレイヤー	最もよくある失敗
approve	L1（所有者）、L3（金額／小数桁）	小数桁の誤り
transfer	L1（残高）、L3（金額／小数桁）	残高不足
addLiquidity	L1（両方のトークンの承認）、L3（金額／比率）、L5（見積もり）	承認漏れ
removeLiquidity	L1（LP 承認）、L3（minAmounts）、L4（スリッページ）	スリッページの許容範囲が狭すぎる
stake	L1（承認＋ホワイトリスト）、L2（ステーキングコントラクトの状態）、L3（金額）	ステーキングが有効でない／ホワイトリストに登録されていない
unstake	L1（ステーカーの状態）、L2（ロック期間）、L3（金額）	ロック期間が終了していない
deploy	L3（コンストラクター引数）、L4（完全なセキュリティチェック）、L5（フォークテスト必須）	コンストラクター引数の不一致
upgrade	L1（プロキシ管理者）、L2（ストレージレイアウト）、L4（ストレージの衝突）、L5（フォークテスト必須）	ストレージレイアウトに互換性がない

---

プリフライト概要カード

オンチェーン操作の前に必ず、このチェックリストを頭の中で確認してください。

[ ] 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 つのレイヤー、2 分。何時間ものデバッグと無駄なガス代を節約できます。