페이지를 넘기고 있습니다.
다음 장을 불러오고 있습니다…
잠깐… 나만의 읽기 환경을 만들어 보세요.
글꼴과 테마는 화면 설정에서 설정하세요. 눈의 편안함도 중요합니다.
다음 장을 불러오고 있습니다…
A token allowance large enough to let a designated spender move present and potentially future balances without asking for another allowance each time.
브라우저의 읽어주기 지원을 확인하는 중…
이 읽기 자료는 현재 영어로 제공됩니다. 인터페이스에는 선택한 언어가 적용됩니다.
영어 원문 읽기 →ERC-20 separates a holder's token balance from allowances granted to spenders. An approval authorizes a particular address to use the token's delegated transfer mechanism up to the allowance. Interfaces often call a very large allowance unlimited because it avoids repeated approval transactions. The permission generally remains until consumed or changed according to the token implementation; closing a browser tab or disconnecting a website does not itself modify that on-chain state.
Suppose a user intends to swap ten tokens but grants a spender a very large allowance. If that spender is malicious, compromised, or upgraded to unsafe code, the permitted balance can be exposed beyond the original ten-token trade. Later deposits of the same token can also matter while the allowance remains. The approval normally concerns that token and spender, not every asset in the wallet, although other signed permissions may create additional exposure.
Check the network, token contract, spender, allowance amount, and whether the spender can change behavior. A limited allowance can narrow exposure but does not make the underlying trade safe. Revocation changes future permission after its transaction is accepted; it cannot recover assets already moved and can be affected by pending transactions. Permission systems built on signed messages or additional approval contracts may add further layers. Use the exact permission model instead of assuming a single revoke button covers every authorization.