The users did nothing wrong on the day they lost the money. They did nothing at all.
An attacker took control of the protocol's admin address and used it to upgrade the contracts. The upgraded contracts then reached into every wallet still holding an active approval to Orange Finance and emptied it. Some of those wallets had not interacted with the protocol in a long time.
The decision point was in the past, and it was not a mistake when it was made. Approving the protocol was the normal, necessary way to use it. What changed is that the contract you approved is not a fixed thing, and nobody revisited a permission that had outlived its purpose.
The previous three lessons were about the moment of signing. This one is about everything you have already signed, which for most people is a longer list than they expect and contains at least one entry from a protocol that no longer exists.
The thing that makes approvals different
A transfer is over when it confirms. An approval is not an event. It is a standing condition that persists until something explicitly ends it.
That produces a property nothing else in your setup has: the risk you accepted is not the risk you hold. You evaluated a protocol at the moment you approved it. The approval outlives that evaluation, and it does not re-evaluate itself when the protocol is upgraded, when its admin keys change hands, when the team walks away, or when someone finds a bug.
"I trust this protocol" is a statement about now. An unlimited approval is a commitment about every future state of that contract. Those are very different claims, and the interface asks you to make the second while you are thinking about the first.
Finding what you have granted
There are two ways, and you should be able to do the second one.
Revocation tools read your address and list outstanding approvals with a button to revoke each. Several exist and they are genuinely useful. They are also a phishing target of exactly the shape this course has been describing, because a fake one is a site that asks you to sign things while you are in a security-minded frame of mind. Reach any such tool by a bookmark you created yourself, never by search result and never by a link someone sent you.
Block explorers show approvals per token contract without any signing at all. It is slower and it always works, it cannot be spoofed into asking you to sign anything, and it is the fallback when you do not trust the tooling. Learn this method, because it is the one that survives the tool you like being compromised.
Whichever you use, the output is a list. Read it for three things:
- Unlimited allowances. Usually rendered as a very large number or the word "unlimited". These are your largest exposures regardless of how much you actually hold.
- Contracts you do not recognise. Approvals from a session you have forgotten, a bridge you used once, a mint you regretted.
- Protocols that are gone. Abandoned projects still hold live permissions. Nobody is maintaining that contract, and nobody will patch it.
Revoking
Revocation is an on-chain transaction, so it costs gas. This is the reason people do not do it, and it is a bad reason.
A revocation is a simple contract call, typically around 30,000 to 46,000 gas.
At 65,000 gas we computed roughly 0.00091 ETH in F105-01. A revocation is smaller, so call it 0.0005 ETH, under two dollars at $3,000 ETH.
Now the other side. An unlimited approval on a token exposes your entire balance of that token in that address, for an unbounded period, contingent on the future behaviour of a contract you do not control.
You are comparing a known cost of a couple of dollars against an unbounded exposure with no expiry. There is no version of this arithmetic where the gas is the deciding factor.
Two practical notes. Setting an allowance to zero is the revocation. And on Permit2 the allowance lives in the Permit2 contract rather than the token, so revoking there is a separate action from revoking a classic ERC-20 approval; check both.
The cadence
Approval review is a habit, not a project. It fails when it has no schedule.
On a schedule. Monthly for a daily-use address is a reasonable default. Ten minutes. Treat it like reviewing app permissions on a phone.
Off schedule, immediately, when any of these happen:
- You hear a protocol you have used has been exploited, upgraded unexpectedly, or changed hands.
- You interacted with something you were unsure about.
- You are about to move a significant balance into an address.
- You finished a one-time interaction, a mint, a bridge, a single swap on an unfamiliar venue. Revoke at the end of the session rather than at the next review.
I moved my funds to a new wallet, so the old approvals do not matter.
Correct for the funds you moved, and a trap for the ones you did not. Approvals are per address and per token. They apply to any balance of that token that address holds in future, including tokens you receive there later, an airdrop, a refund, a payment from someone who still has the old address.
The tier that makes this manageable
If a monthly audit sounds tedious, that is a signal about architecture rather than about discipline.
The three-tier structure from F104 exists partly for this. The vault tier never connects to a dApp, so it accumulates no approvals and needs no audit. The daily tier holds a modest balance and gets the monthly review. The burner tier is assumed compromised and rotated, so its approvals are irrelevant by design.
Nearly all approval risk lands on the tier that is supposed to be small. That is the architecture working.
An approval is a standing condition, not an event, and it does not re-evaluate itself when the thing you trusted changes. Enumerate what you have granted, revoke unlimited allowances and anything you no longer use, and put the review on a calendar with named triggers for going off schedule. The gas cost of revoking is a couple of dollars against an exposure with no ceiling and no expiry.