---
title: "Permit2署名のリスク"
description: "Permit2は再利用可能なアローワンスと一回限りの署名転送を分離します。安全に署名するには、デプロイ、ドメイン、スペンダー、受取先、金額、ノンス、期限、ウィットネス、実行コールデータを正確に検証する必要があります。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Permit2署名のリスク
> 教育目的のみであり、投資助言ではありません。投資は損失につながる可能性があります。
## 直接の答え
Permit2は二つの異なる認可方式を組み合わせています。`AllowanceTransfer` は、金額、有効期限、順序付きノンスを含む、再利用可能な所有者・トークン・スペンダー単位のアローワンスを保存します。`SignatureTransfer` はアンオーダード・ノンス・ビットマップを使って一回限りの署名上限を消費し、永続的な下流アローワンスを作りません。どちらもERC-20トークンにおける所有者からPermit2へのアローワンスに依存します。
ガスを伴わない署名でも、スペンダーやリレイヤーが実行費用を支払えば資産を移転できます。正確なチェーン、デプロイ済みPermit2コード、EIP-712ドメイン、モジュール、トークン、スペンダー、署名上限、受取先のコールデータ、ノンス、時刻条件を確認してください。正規のPermit2コントラクトであっても、悪意あるスペンダー、受取先、ルーター、ウィットネスが安全になるわけではありません。
## 仕組み
1. `chainId`、ネットワーク、Permit2の `verifyingContract`、デプロイ済みランタイムコード、トークンのアドレスと小数桁、所有者のウォレット種別、想定アプリケーションを特定します。公式のデプロイ記録を使用し、見慣れたアドレスや表示名だけで判断しないでください。
2. 上流にあるERC-20の所有者からPermit2へのアローワンスと残高を読み取ります。有限承認か無制限承認か、トークン固有の転送挙動かを確認します。この台帳は、Permit2署名または保存済みの下流アローワンスが期限切れになっても残ります。
3. 正確な経路と署名対象のプライマリ型を特定します。AllowanceTransferでは `PermitSingle` または `PermitBatch`、SignatureTransferでは `PermitTransferFrom` またはそのバッチ版とウィットネス版です。`transferFrom` を署名型として扱ってはいけません。
4. EIP-712ドメインとメッセージの全項目をデコードします。AllowanceTransferでは、トークン、`uint160 amount`、`expiration`、順序付きノンス、スペンダー、`sigDeadline` を確認します。SignatureTransferでは、許可されたトークンと金額、アンオーダード・ノンス、期限、呼出元のコンテキストから束縛されるスペンダーを確認します。
5. 実行コールデータは別にデコードします。基本的なSignatureTransferでは、`SignatureTransferDetails.to` と `requestedAmount` は実行パラメータであり、基本署名許可のフィールドではありません。要求額は署名上限以下であれば足ります。バッチの各インデックスと、正確なウィットネスハッシュおよび型文字列を確認します。
6. 現在の順序付きアローワンス・ノンス、またはアンオーダード・ビットマップのワードとビットを照会し、正確な呼出元、コールデータ、チェーン、状態を再現してシミュレーションします。受取先、ルーターの処理、トークン固有の挙動、残高、二つのアローワンス台帳を照合します。状態、順序、再編成によりシミュレーション結果は変わり得ます。
7. 金額と有効期間を最小限にします。不審な場合は型付きデータを保存し、信頼できる経路から、上流承認の取消し、下流アローワンスの取消し、またはノンスの無効化のうち正しい操作を送信します。メンプール上の競合として扱い、承認後に転送、残高、アローワンス、ビットマップのビットを照合してください。
AllowanceTransferの `sigDeadline` は、署名許可によって保存済み権限を設定または更新できる期限です。`expiration` は、その保存済み権限を使用できる期限です。SignatureTransferの期限は一回限りの実行を制限します。EIP-712が提供するのは型付きハッシュとドメイン分離であり、リプレイ保護や意図の安全性ではありません。これらの境界はPermit2のノンスと期限の規則が提供します。
コントラクトウォレットでは、ERC-1271の有効性はウォレットの現在の `isValidSignature` ポリシー、モジュール、しきい値、コードに依存します。ウォレットの表示名、ハードウェアウォレットで省略された画面、成功したシミュレーションは判断材料であり、保証ではありません。フロントエンドとの接続を切っても、承認や署名は取り消されません。
## 例
- **二つのアローワンス台帳。** Permit2に対する有限のトークンアローワンスは当初 `1,000 USDC` で、`PermitSingle` がスペンダーS向けに `600 USDC` を保存します。Sが `225 USDC` を移転すると、保存額は `600 - 225 = 375 USDC`、標準的な有限の上流トークンアローワンスは `1,000 - 225 = 775 USDC` になります。375を期限切れにするか取り消しても、775は自動的には消えません。非標準トークンでは挙動が異なる場合があります。
- **一回限りの受取先と金額。** SignatureTransferで `250 USDC` の上限に署名し、コールデータが加盟店への `180 USDC` を要求するとします。残高と上流アローワンスが十分であれば、180を移転できます。ノンスは消費されるため、未使用の `70 USDC` は再利用できません。コールデータが攻撃者を受取先に指定している場合、基本許可だけでは、束縛されたスペンダーによる転送先の変更を防げません。
- **アンオーダード・ノンス・ビットマップ。** ノンス `513` では、`wordPos = 513 >> 8 = 2`、`bitPos = 513 & 255 = 1`、`mask = 1 << 1 = 2` です。実行するとワード2のビット1が設定され、513のリプレイは失敗します。ビット0にあるノンス `512` は独立しています。
- **取消しの競合。** 保存済みアローワンスを `400 USDC` とします。所有者はゼロへの取消しをブロードキャストしますが、`300 USDC` の転送が先に実行され、`100 USDC` が残ります。その後の取消しで残額が `0` になります。最終アローワンスがゼロでも、実現した `300 USDC` の損失は取り消されないため、トランザクション順序と残高を照合する必要があります。
## リスク
- チェーンID、デプロイ、ランタイムコードの誤り
- 偽造または想定外の検証コントラクト
- AllowanceTransferとSignatureTransferの混同
- 悪意または誤設定のスペンダーと呼出元
- 実行コールデータによって選ばれる受取先
- 署名上限に近い要求額
- トークンアドレス、シンボル、小数桁、生の単位の誤り
- 永続的または無制限の上流ERC-20承認
- 過大な下流金額または有効期限
- 期限、署名期限、アローワンス有効期限の混同
- 古い、または競合した順序付きノンス
- ビットマップのビット再利用、または広すぎる無効化マスク
- ウィットネスハッシュまたは正確な型文字列の不一致
- 隠れた、重複した、またはインデックスが誤ったバッチ項目
- フロントエンド表示またはコールデータと意図の相違
- 取消しがメンプールまたはMEVの競合に負けること
- ERC-1271のモジュール、署名者、しきい値、アップグレードの変更
- 転送手数料、リベース、一時停止、ブロック、コールバックを持つトークン
- シミュレーションの状態ずれ、失敗、再編成
- ハードウェアウォレットでの確認や接続解除を安全性と誤認すること
## よくある誤解
- **ガスの確認がない署名ではトークンを移転できない。** 別の当事者が実行ガスを支払えます。
- **公式のPermit2アドレスなら、スペンダーと受取先も安全である。** Permit2は悪意ある権限も指示どおりに実行し得ます。
- **SignatureTransferとAllowanceTransferは同じ永続的権限を作る。** 前者は一回限りで、後者は再利用可能なアローワンスを保存します。
- **接続解除または一つの層の取消しで、すべての経路と未実行署名が無効になる。** 上流、下流、ノンスの状態は別々であり、競合も残ります。
- **EIP-712、ハードウェアウォレット、成功したシミュレーションが意図とファイナリティを証明する。** 可視性や試験は改善しますが、フィールド、コールデータ、確定済み状態の検証に代わるものではありません。
## 関連トピック
- [EIP-712型付き署名](/ja/crypto/eip712-typed-signature/)
- [ウォレットの承認](/ja/crypto/wallet-approval/)
- [ウォレット署名](/ja/crypto/wallet-signature/)
## 出典
- [Overview](https://developers.uniswap.org/docs/protocols/permit2/overview) - Uniswap Developers（参照日：2026-08-13）
- [Allowance Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/allowance-transfer) - Uniswap Developers（参照日：2026-08-13）
- [Signature Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/signature-transfer) - Uniswap Developers（参照日：2026-08-13）
- [Deployments](https://developers.uniswap.org/deployments) - Uniswap Developers（参照日：2026-08-13）
- [PermitHash.sol](https://github.com/Uniswap/permit2/blob/main/src/libraries/PermitHash.sol) - Uniswap Permit2（参照日：2026-08-13）
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals（参照日：2026-08-13）
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals（参照日：2026-08-13）
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals（参照日：2026-08-13）
Source: https://wiki.fcontext.com/ja/crypto/permit2-signature-risk/index.mdx