Setting custom spend limits is a simple yet overlooked technique to protect your wallet from potential Web3 exploits.
If you've ever used apps like Uniswap, AAVE, etc, chances are that you've overlooked doing this
Quick 🧵 on what they are and how to use them properly
When interacting with services that transact with your crypto assets, you often encounter something called the "Approve" transaction step before performing the main transaction.
Here's what that transaction looks like when you interact with Uniswap
What the Approve transaction does is two things:
1. Allow the smart contract you're interacting with to validate how much of the token you have
2. Give permission to the smart contract to transfer/spend a certain amount of those assets on your behalf for future operations
This "approval" is a necessity for many Web3 protocols because it allows smart contracts to spend your assets in the future without needing you to do an explicit transaction at that given time
This applies to assets like ERC20 tokens and NFTs
By default the Approve transaction allows the smart contract to spend an almost infinite amount of your tokens, even if you're only wanting to transact with a small amount like 100
This is done for UX reasons as I'll explain later. However, it also opens you up to huge risks
The biggest risk is:
If the smart contract gets exploited (or if it is a straight up rug pull), you can have all of your tokens drained without realizing it
I'll illustrate this with a hypothetical scenario:
Alice has 1000 $SHIB
Alice interacts with a AMM protocol called Rugswap that lets her swap 200 $SHIB for ETH.
Before performing a swap, Rugswap asks her to perform a standard Approve transaction on her $SHIB.
Alice accepts the default spend limit and then subsequently performs a swap transaction and Rugswap sends her ETH in exchange for her 200 $SHIB
Later, due to an undiscovered security vulnerability, a hacker is able to exploit a bug in the Rugswap smart contract and get access to its token transfers functionality
The hacker proceeds to use the exploited smart contract to transfer the remaining 800 $SHIB from Alice's wallet into their own wallet
Since she used the default spend limit on the approval transaction, the hacked smart contract had permission to transfer the additional $SHIB
This could have all been prevented with a simple 1 second step: setting custom spend limits
Here's how to do it
When you are asked to perform an Approve transaction, there is an "edit permission" option where you can customize the approval settings.
Here you can specify an exact amount of tokens you want the smart contract to be able to spend using the "Custom Spend Limit" option.
Once you hit save and submit the transaction, the smart contract will ONLY be allowed to spend up to that amount.
If Alice had set her limit to 200 $SHIB, she would have been protected against the hacker transferring out any additional tokens from her wallet.
So now you might be asking, "Why is the default spend limit an insanely high number"
It comes down to two things:
User experience and gas optimization
Each time the smart contract reaches the approved spend limit for a given wallet, it must ask for a new spend limit.
This can result in a cumbersome UX of requiring an approval transaction each time you want to do the main transaction
Setting the approved spend limit to a super high number makes it so that the smart contract rarely or never has to ask for an approve transaction again for that token.
Also -- each approval transaction is an on-chain transaction, and as a result results in spending gas.
More transactions = more money wasted on gas.
With this newfound knowledge, you have to decide on some trade-offs.
Here are my recommendations
If you're operating on a L1 or L2 with low gas fees, ALWAYS set a custom spend limit.
The work to perform extra Approve transactions are insignificant compared to potentially losing your tokens.
If you're operating on mainnet, you can make a call depending what contract you're interacting with.
If it's a battle-tested platform with a good track record of security, (e.g. Uniswap, Aave, Opensea) then you're probably fine with using the default spend limit.
If it's a brand new platform or shadowy ponzi, then set a custom approval limit to give yourself some insurance.
This exploit is common and has occurred several times in the past in high profile cases.
One of the notable ones was an exploit on the Bancor protocol
If you've already approved default spend limits in the past, Etherscan has a handy tool to see what protocols have access to transfer your tokens and how many you've granted.
You can also revoke permissions as well through this tool