교육 목적으로만 제공되며 투자 조언이 아닙니다. 투자로 손실이 발생할 수 있습니다.
핵심 답변
일부 ERC-20 구현은 기존 allowance와 newAmount가 모두 영이 아닐 때 approve(spender, newAmount)를 거부합니다. 이런 토큰은 먼저 approve(spender, 0)을 제출하고 확정을 기다린 다음, 새로운 영이 아닌 승인을 제출해야 합니다.
이 제한은 모든 ERC-20 토큰의 필수 조건이 아닙니다. ERC-20은 approve를 현재 allowance의 덮어쓰기로 정의하며 승인 변경 경쟁을 완화하도록 클라이언트 화면에 영 우선 방식을 권고합니다. 동시에 호환성을 위해 토큰 계약 자체가 이를 강제해서는 안 된다고 설명합니다. 그런데도 일부 배포된 토큰은 이 제한을 강제합니다. 따라서 영 우선 방식은 호환성 절차이자 유용한 확인 지점이지만, 영으로 만드는 거래가 확정되기 전에 기존 allowance가 사용되지 않는다는 보장은 아닙니다.
모든 항목을 검토해도 자산, 거래 또는 시스템의 안전이 입증되는 것은 아닙니다.
작동 방식
- 체인, 토큰 계약, 소유자, spender, 의도한 금액을 확인합니다. 지갑의 표시 이름만 믿지 말고 토큰 계약에서
allowance(owner, spender)를 읽습니다. - allowance가 이미
0이면 원하는 승인을 한 번 제출합니다. 영이 아니면 다른 영이 아닌 값으로 직접 바꾸는 호출이 표준 구현에서는 성공해도 영 우선 토큰에서는 revert될 수 있습니다. - 영 우선 절차에서는
approve(spender, 0)을 제출하고 성공 receipt를 기다립니다. 같은 소유자와 spender의 allowance를 다시 읽어0인지 확인합니다. - 토큰 잔액, spender, 목적을 다시 확인합니다. 그런 다음에만
approve(spender, newAmount)를 제출하고 확정된 뒤 새 allowance가 활성화되었다고 판단합니다. - 최종 allowance를 확인하고 중간의
Transfer및Approval이벤트를 검토합니다. 성공한 거래 receipt는 실행을 증명하며 현재 계약 상태는 남아 있는 권한을 보여 줍니다.
OpenZeppelin의 SafeERC20.forceApprove는 계약용 호환성 대체 절차를 구현합니다. 원하는 값을 먼저 시도하고, 그 호출이 실패하면 0과 원하는 값을 차례로 시도합니다. 이 도우미는 호출하는 계약 자체의 allowance를 바꿉니다. 사용자 지갑 승인을 자동으로 고치지 않으며 거래 순서와 최종 상태를 확인할 필요도 없애지 않습니다.
예시
소유자가 spender에게 1000토큰의 allowance를 부여했고 이를 100으로 줄이려 합니다. 영 우선 토큰에서는 approve(spender, 100)이 revert되므로 온체인 allowance는 1000으로 남습니다. revert된 호출은 상태를 일부만 갱신하지 않습니다.
대신 소유자는 approve(spender, 0)을 제출합니다. 이 거래가 확정되기 전에 spender가 400을 사용하여 600이 남았고, 이후 확정된 영 설정 거래가 나머지를 0으로 덮어씁니다. 소유자는 줄어든 토큰 잔액을 확인한 뒤 새로운 100을 부여할지 결정할 수 있습니다. 부여한다면 spender는 이미 400을 썼고 나중에 최대 100을 더 쓸 수 있습니다. 영 우선 절차는 새 권한을 주기 전에 중간 지출을 드러냈지만 그 지출을 되돌리지는 않았습니다.
위험
- 기존 allowance는 영 설정 거래가 실행될 때까지 사용할 수 있습니다. spender가 보류 중인 취소나 감액보다 먼저 지출할 수 있습니다.
- 첫 거래의 확정을 기다리지 않고 영 설정과 대체 거래를 모두 전파하면 의도한 확인 지점이 사라지고 중간 지출을 놓칠 수 있습니다.
- 체인, 토큰 주소 또는 spender 주소가 틀리면 의도와 다른 권한을 만들거나 취소합니다. 토큰 심볼은 고유 식별자가 아닙니다.
- 두 단계가 모두 필요하면 두 거래의 비용이 들며, 어느 쪽이든 실패하거나 대체되거나 계속 보류될 수 있습니다. 서명을 제출했다는 사실만으로 상태를 추정하지 마세요.
- 무제한 승인과 업그레이드 가능하거나 침해된 spender는 미래 입금까지 노출할 수 있습니다. 실용적인 최소 금액을 사용하고 이용 후 남은 allowance를 확인하세요.
- 계약 연동은 비표준 반환값과 승인 동작을 명시적으로 처리해야 합니다. 호환성 래퍼가 신뢰할 수 없는 spender를 안전하게 만들지는 않습니다.
흔한 오해
- 모든 ERC-20이 영 우선 방식을 요구한다. 표준은 클라이언트 측 순서를 권고하지만 토큰 계약이 강제해서는 안 된다고 설명합니다. 영이 아닌 값에서 다른 영이 아닌 값으로의 변경을 거부하는 것은 일부 구현뿐입니다.
- 영 우선 방식이 승인 경쟁을 완전히 해결한다. spender는 영 설정 거래가 확정되기 전에 기존 allowance를 사용할 수 있습니다.
- 대체 승인이 revert되면 기존 allowance도 지워진다. revert는 시도한 상태 변경을 되돌리므로 이전 allowance가 일반적으로 그대로 남습니다.
- 두 거래를 함께 보내면 확정을 기다리는 것과 같다. 안전 확인 지점은 영 상태를 확정하고 검사한 뒤 대체 승인을 결정할 때 생깁니다.
- 웹사이트 연결을 끊으면 승인도 취소된다. 지갑 연결 상태와 토큰 계약의 온체인 allowance는 서로 별개입니다.
관련 주제
출처
- ERC-20: 토큰 표준 - Ethereum Improvement Proposals (열람일: 2026-08-21)
- ERC20 | OpenZeppelin 문서 - OpenZeppelin (열람일: 2026-08-21)
- SafeERC20.sol - OpenZeppelin (열람일: 2026-08-21)