Revoke.cash is the tool the crypto industry already tells people to use after something goes wrong: it manages token approvals, the lingering access users grant to DeFi apps and marketplaces every time they swap, stake, or sell an NFT. Revoke.cash used MetaMask's Smart Accounts Kit to create Auto-Revoking, which goes a step further by automatically cleaning up unneeded approvals without ever holding a user’s keys.
Revoke.cash solves a problem most wallets never surface
A token approval is the permission you give a DeFi app to move your tokens: approve USDC so Uniswap can swap it, approve a Pudgy Penguin so OpenSea can list it. That access doesn't expire when you're done. It sits on your wallet indefinitely, and every dormant approval is a standing liability if the app it was granted to is ever exploited.
Revoke.cash started in October 2019 as founder Rosco's side project, built to solve his own discomfort with how many DeFi apps quietly held standing access to his wallet. There was no way yet to see or revoke that access, so he built one. Over the past six years, Revoke.cash has served more than 2 million users and been used to revoke over 20 million token approvals. Premium and Ultimate, the paid tiers that introduced Auto-Revoking, shipped in 2026.
Rosco says the idea for Auto-Revoking came from noticing the right advice always arrives too late. Whenever an exploit hits or someone loses funds, the standard advice is "go to Revoke.cash." The classic case of too little, too late.
Instead, prevention is everything. Regularly cleaning up approvals keeps them from causing problems. Doing that consistently by hand is unrealistic for most people, so Revoke.cash built the automated version once the underlying technology made it possible.
The problem: acting for someone without ever holding their keys
As an industry, we're working hard to make it viable for users to manage their own wallets in a non-custodial manner. Taking custody of a user's seed phrase is never an option from a security point of view.
— Rosco, founder of Revoke.cash
Some onchain actions, like automated rebalancing or limit orders, already have workable ways to act on a user's behalf. Revoking someone else's token approval didn't, until ERC-7710 and ERC-7715 arrived.
MetaMask's Smart Accounts Kit and Delegation Framework became the foundation rather than custom-built infrastructure. The SDKs handle both sides of the problem: a simple UI for users to grant a delegation and a backend that can consume it. That let Revoke.cash focus its own engineering on the harder, more novel part: the systems around Auto-Revoking, rather than reinventing the delegation layer underneath it.
Revoke.cash's feedback helped shape what became the token-approval-revocation permission type specifically. MetaMask also helped Revoke.cash work through parts of its hot-and-cold wallet delegation setup.
Before | With Auto-Revoking + Delegation Framework |
Users are told to revoke approvals only after an exploit or loss | Approvals are revoked proactively, on a schedule, before they're exploitable |
Cleaning up approvals requires remembering to do it, manually, per app | A user grants one permission, once, in MetaMask |
No way to act on a user's approvals without holding their keys | A scoped token-approval-revocation permission authorizes only that action |
Manual review doesn't scale to thousands of dormant approvals | Revoke.cash's systems index and monitor approvals continuously |
One cold wallet, two hot ones, a single narrow permission
A user turns on Auto-Revoking from the account settings section of Revoke.cash. That action requests a token-approval-revocation permission, granted through MetaMask, to a Revoke.cash-controlled cold wallet. The cold wallet is set up to forward those delegations to two hot wallets that run on Revoke.cash's auto-revoke servers.
From there, Revoke.cash's systems index and monitor the user's token approvals against their configured auto-revoke rules, such as approvals that have gone stale or ones flagged as high-risk. When an approval matches a rule, one of the hot wallets sends a transaction that carries both delegations in the chain, the user-to-cold delegation and the cold-to-hot delegation, authorizing the revoke onchain.
Why a cold wallet in the middle at all: if a hot wallet is ever compromised, the cold wallet is what keeps that from touching the user directly. Hot wallets can be added or removed behind the cold wallet without the user's original delegation ever changing.
Why two hot wallets instead of one: Revoke.cash splits auto-revokes into two categories. Routine revokes are ordinary cleanup, like an OpenSea approval left over from an NFT sold two years ago. Urgent revokes are triggered by an active exploit or an emerging risk, where speed matters. Running each category through its own dedicated hot wallet means an urgent, exploit-triggered revoke is never stuck in a queue behind routine housekeeping.
The permission itself is scoped by MetaMask's caveat enforcers to only ever authorize a revoke action, nothing broader, which is the guarantee that makes it safe to hand a delegation to an automated system in the first place.
The stack
Layer | Components |
Permission | Advanced Permissions (ERC-7715) token-approval-revocation permission type |
Delegation | User → cold wallet → two hot wallets, MetaMask Delegation Framework |
Execution | Two dedicated hot wallets: routine cleanup and urgent, risk-triggered revokes |
Monitoring | Revoke.cash's approval indexing and rule-matching engine |
Revoking approvals is an important security measure that everyone needs to do, but no one wants to think about. By providing automated revoking, powered by MetaMask's Smart Accounts Kit, we're able to help protect these users while saving them the mental load of managing it manually.
— Rosco, founder of Revoke.cash
Revoke.cash's advice for builders
Don't build the delegation layer yourself. The hard, novel part of Auto-Revoking was the surrounding system: indexing approvals, matching risk rules, routing routine versus urgent execution. Letting MetaMask's Smart Accounts Kit SDK handle granting and consuming the permission itself meant that work didn't have to be duplicated.
Isolate your execution layer from your user's trust. A cold wallet between the user and the hot wallets that actually execute transactions means a compromised executor never has to become the user's problem; wallets behind the cold wallet can be rotated freely.
Separate routine from urgent. When automation runs on a schedule, not every trigger is equally time-sensitive. Splitting execution paths by urgency keeps a slow, routine job from ever delaying a fast, high-stakes one.
For more information, check out: