defi-security

DeFi のセキュリティ原則

言語ルール

• 常にユーザーが使用している言語と同じ言語で応答してください。 ユーザーが中国語で尋ねた場合は、中国語で応答してください。英語の場合は、英語で応答してください。

対象範囲：DeFi プロジェクト（DEX、レンディング、ステーキング、LP、イールド）のみに適用されます。DeFi 以外のプロジェクトでは、このスキルを無視できます。

保護策の決定ルール

脅威	必要な保護策
クジラによる操作	1 日あたりの取引上限＋1 回あたりの金額制限＋クールダウン期間
MEV／サンドイッチ攻撃	EOA のみを許可するチェック（msg.sender == tx.origin）、またはコミット・リビール方式を使用
アービトラージ	紹介者の紐付け＋流動性の分散＋固定イールドモデル＋ロック期間
再入攻撃	外部呼び出しを行うすべての関数に ReentrancyGuard を適用（solidity-security スキルを参照）
フラッシュローン攻撃	操作間で block.number が変化したことを確認するか、TWAP 価格を使用
価格操作	Chainlink オラクルまたは TWAP を使用。価格算出に AMM のスポット準備金を決して使用しない
承認の悪用	safeIncreaseAllowance／safeDecreaseAllowance を使用し、ユーザーのフローでは生の approve を決して使用しない
ガバナンス攻撃	投票にはスナップショット＋最低トークン保有期間を必須とし、提案の実行には 48 時間以上のタイムロックを設定
ERC4626 のインフレーション攻撃	初回入金に最低金額を設定するか、仮想シェアを使用して丸めによるシェアの希薄化を防止
Vault 間の信頼性チェック回避	Router／Registry の中継では Vault の認可を検証する必要があります。フラッシュローンのコールバック内で呼び出し元の識別情報を決して信頼しないでください — EVMbench/noya H-08
担保の所有権悪用	清算／ステーキング操作では、NFT／担保の実際の所有権を検証する必要があります — EVMbench/benddao
ボンディングカーブの操作	作成操作の ID／価格設定パラメーターは、外部呼び出しより前に完全に確定させる必要があります — EVMbench/phi H-06
DEX ペアの _transfer TOCTOU	_transfer 内で残高／準備金のチェックにより操作種別を決して判別しないでください。どちらの方向も悪用可能です。購入と removeLiquidity（pair→user）、売却と addLiquidity（user→pair）を区別する場合は、アドレスのホワイトリストのみを使用してください。新規プロジェクトでは Uniswap V4 Hook を推奨します
アドレスごとの状態制限の回避	mapping(address => ...) による制限（クールダウン、最大取引量、最大残高）は、複数アドレスの使用や送金後の取引によって回避できます。ウォレット間の送金時には max(_lastTxTime[to], _lastTxTime[from]) を使用して制限状態を引き継いでください。block.timestamp（嫌がらせ攻撃）や直接代入（上書きによる期間短縮）は決して使用しないでください

クジラ対策の実装ルール

• 1 回あたりの最大取引量：onlyOwner セッターで設定可能にする
• アドレスごとの 1 日の累積上限：mapping(address => mapping(uint256 => uint256))（アドレス → 日 → 金額）で追跡する
• 取引間のクールダウン：block.timestamp チェックで最小時間間隔を適用する
• 免除対象アドレス（デプロイヤー、LP ペア、ステーキングコントラクト）のホワイトリストを用意する

フラッシュローン対策ルール

• 価格に敏感な操作では、前回のインタラクション以降に block.number が変化していることを必須とする
• オラクルに依存する計算では、最低 30 分間の時間加重平均（TWAP）を使用する
• 重要な状態変更では、アクションの前に最低保有期間を設ける（例：トークンを N ブロック保有していることを必須とする）

プロトコルのコンポーザビリティに関するリスク

出典：EVMbench（OpenAI/Paradigm、2026年2月） — Code4rena の監査で確認された脆弱性パターン

• Vault 間の操作 [noya H-08]：Registry/Router の中継呼び出しでは、Vault レベルの認可を検証する必要があります。Keeper がフラッシュローンを使って他の Vault になりすますことを防いでください
• レンディングの担保 [benddao]：清算関数では、msg.sender が対象の担保を実際に所有しているか、操作する権限を持つことを検証する必要があります
• ボンディングカーブ [phi H-06]：作成と自動購入を行う操作では、購入トランザクションの実行前に ID の割り当てと価格設定パラメーターを完全に確定する必要があります。再入可能性によってこれらが変更されるのを防いでください
• 共有レジストリ [noya H-08]：共有レジストリにおける権限伝播チェーンは、各ホップで検証する必要があります。「信頼された送信元」フラグだけに頼らないでください

ローンチチェックリスト

メインネットにデプロイする前に、すべての項目を確認してください。

• すべての onlyOwner 関数の権限をマルチシグウォレットに移譲する
• Timelock コントラクトをデプロイして設定する（重要な変更には最低24時間の遅延を設定）
• 緊急停止の仕組みをテストする — 停止関数と再開関数がどちらも正しく動作する
• 1日の上限パラメーターを文書化し、妥当な値を設定する
• 第三者によるセキュリティ監査を完了し、重大度が Critical または High の指摘事項をすべて解決する
• テストネットで問題なく最低7日間稼働している
• スリッページ、手数料、ロック期間のパラメーターを確認し、文書化する
• 初期流動性の計画を文書化する（金額、ロック期間、LPトークンの取り扱い）
• DeFi の重要なすべての関数で、高い反復回数（10000回以上）のファズテストに合格する

緊急時対応手順

手順	アクション
1. 検知	アラートの発動を確認する（オンチェーン監視、コミュニティからの報告）
2. 停止	指定アドレスが pause() を呼び出す — 数分以内に対応する必要があります
3. 評価	技術リードが根本原因を分析し、資金への影響を見積もる
4. 連絡	コミュニティのチャンネル（Discord、Twitter、Telegram）にインシデントの告知を投稿する
5. 修正	修正をデプロイするか、復旧計画を準備する
6. 再開	フォーク環境で修正を検証した後に unpause() を呼び出す — または新しいコントラクトに移行する
7. 事後検証	48時間以内に詳細なインシデントレポートを公開する

DeFi テストのリファレンス

テストシナリオ	方法
資金フローのファズテスト	ステーキング／プールのコントラクトで、高い反復回数（10000回以上）のファズテストを実行する
メインネットのフォークテスト	Foundry のフォークモードをメインネット RPC に対して使用し、実際の状態でテストする
クジラのトランザクションのシミュレーション	Foundry cast CLI を使い、フォークしたネットワーク上で大口の呼び出しをシミュレーションする