---
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`라고 가정합니다. 소유자가 0으로 만드는 철회를 브로드캐스트하지만 `300 USDC` 전송이 먼저 실행되어 `100 USDC`가 남고, 이후 철회가 나머지를 `0`으로 만듭니다. 최종 승인 한도가 0이어도 이미 실현된 `300 USDC` 손실은 되돌리지 못하므로 트랜잭션 순서와 잔액을 대조해야 합니다.
## 위험
- 잘못된 체인 ID, 배포 또는 런타임 코드
- 위조되었거나 예상하지 못한 검증 컨트랙트
- AllowanceTransfer와 SignatureTransfer의 혼동
- 악의적이거나 잘못 지정된 스펜더와 호출자
- 실행 호출 데이터로 선택되는 수신자
- 서명 상한에 가까운 요청 금액
- 잘못된 토큰 주소, 심벌, 소수 자릿수 또는 원시 단위
- 지속적이거나 무제한인 상위 ERC-20 승인
- 과도한 하위 금액 또는 만료 시각
- 기한, 서명 기한, 승인 한도 만료 시각의 혼동
- 오래되었거나 경쟁 중인 순차 논스
- 비트맵 비트 재사용 또는 지나치게 넓은 무효화 마스크
- 위트니스 해시 또는 정확한 타입 문자열 불일치
- 숨겨지거나 중복되거나 인덱스가 잘못된 배치 항목
- 프런트엔드 표시 또는 호출 데이터와 의도의 불일치
- 철회가 멤풀 또는 MEV 경쟁에서 지는 위험
- ERC-1271 모듈, 서명자, 임계값 또는 업그레이드 변경
- 전송 수수료, 리베이스, 일시 정지, 차단 또는 콜백 토큰
- 시뮬레이션 상태 변동, 실패 또는 재구성
- 하드웨어 지갑 확인이나 연결 해제를 안전으로 오인하는 위험
## 흔한 오해
- **가스 안내가 없는 서명으로는 토큰을 옮길 수 없다.** 다른 당사자가 실행 가스를 지불할 수 있습니다.
- **공식 Permit2 주소라면 스펜더와 수신자도 안전하다.** Permit2는 악의적인 권한도 지시대로 실행할 수 있습니다.
- **SignatureTransfer와 AllowanceTransfer는 같은 지속적 권한을 만든다.** 전자는 일회성이고 후자는 재사용 가능한 승인 한도를 저장합니다.
- **연결을 끊거나 한 계층을 철회하면 모든 경로와 대기 중인 서명이 취소된다.** 상위, 하위, 논스 상태는 별개이며 경쟁도 남습니다.
- **EIP-712, 하드웨어 지갑 또는 성공한 시뮬레이션이 의도와 최종성을 증명한다.** 가시성이나 시험은 개선하지만 필드, 호출 데이터, 확인된 상태 검증을 대신하지 못합니다.
## 관련 주제
- [EIP-712 타입 서명](/ko/crypto/eip712-typed-signature/)
- [지갑 승인](/ko/crypto/wallet-approval/)
- [지갑 서명](/ko/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/ko/crypto/permit2-signature-risk/index.mdx