صفحہ پلٹ رہا ہے۔
اگلا باب سامنے لا رہے ہیں…
سنیے… مطالعہ اپنے مطابق بنائیں۔
خط اور تھیم ظاہری انداز میں ہیں۔ اپنی آنکھوں کی سہولت بھی دیکھیں۔
اگلا باب سامنے لا رہے ہیں…
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.