Flagged before you sign.
Our panel reads every approval as MetaMask shows it, says what it grants, and stops you once on anything unlimited.
MetaMask does not let a panel rewrite a request. The cap is set in MetaMask itself.
How it works
A swap asks you to Approve.
Underneath, it wants all your USDC. Forever.
We flag it in MetaMask, before you sign.
Already signed it? One tap caps it to what you meant.
You sign the cap in MetaMask. Never us.
We check the chain: exactly what you set.
Access receipt
● What the button says
ActionSwap
Amount100 USDC
ButtonApprove
Asks for?
Before we look
Access receipt
● Unbounded
AmountUnlimited
ExpiresNever
ReachesEntire balance
Later depositsCovered
As requested
Too wideAccess receipt
● Unbounded · flagged
AmountUnlimited
ExpiresNever
ReachesEntire balance
Later depositsCovered
In your MetaMask
Look firstAccess receipt
● Bounded
Amount100 USDC
Reaches100 USDC, no more
Later depositsOut of reach
RevokeOne tap
As corrected
Access receipt
● Bounded · unsigned
Amount100 USDC
Reaches100 USDC, no more
Later depositsOut of reach
RevokeOne tap
In your MetaMask
YoursAccess receipt
● Bounded · on chain
Amount100 USDC
Reaches100 USDC, no more
Later depositsOut of reach
RevokeOne tap
Read back from the chain
VerifiedTap to move on. Point at a line to go back.
Product
Where you sign, where you fix it, and when to look.
Capped in one tap.
Every app that can move your money, on every chain we read, in one ring. Limit or remove each one, sign it in MetaMask, and we read the chain back.
We read the major assets and apps on each chain, and say when something is outside that.
Told when it changes.
Sign in once, link Telegram, and get a message when a new approval appears, anything unlimited can reach you, or an approval grows.
Catches approvals made outside MetaMask, too.
One integration, and the request is right before it is signed.
Inside your wallet or app, we read what a request really asks for and hand back the smaller one your user meant. Your user signs. We never do.
- A decoder per standard, and per standard after that
- A state reader per chain, and its quirks
- The control flow around a correction that must not be signed by you
what your users see
Rendered from four fields - reading, reachableNow, because, remediable - and a plan whose signed is always false.
Questions.
Including the two we are asked least and should be asked most: what this cannot see, and what it cannot do.
Not here? Ask us directly
What we touch
Do you hold my keys, or sign anything for me?
No. Every correction is an unsigned transaction handed to your own wallet, and your wallet still has to confirm it. We never sign and we never hold a key.
Do you store my wallet history?
The analysis path has no database at all. ADR 001 keeps it stateless: signed, short-lived envelopes carry all the context a decision needs, which removes backups, migrations and recovery from the picture. Persistence arrives with the permission dashboard, not before.
What it cannot do
Can you show me everything my wallet has ever approved?
No, and neither can anyone else. Approvals cannot be enumerated from chain state - they can only be asked about, one asset and one spender at a time. We ask about a registry of major assets and known applications on each chain, derived from live Approval logs and then verified on chain. Anything outside that registry will not appear, and we say so rather than rendering an empty result as a clean wallet.
Is the MetaMask Snap the thing doing the work?
No. MetaMask transaction insight is read-only: it can show the analysis inside the confirmation, but it cannot rewrite the request. The Snap is a second display surface, not the mechanism.
Why not ship a browser extension?
Asking a mainstream user to discover, trust and install a new security extension is high friction, and wallet-native features commoditise standalone ones. Distribution is integrations - an SDK, a decision API and a widget - rather than installs. The extension stays in the deferred register until integrations alone stop providing reach.
How it works
What is the difference between limiting and revoking?
Revoking removes authority that nothing needs any more. Limiting cuts authority something still needs down to the amount the action actually required, and attaches an expiry where there was none. Most standing permissions want limiting rather than deleting, which is why the default is not simply to remove everything.
Which chains do you read?
Fifteen EVM chains. The domain model is chain-independent by design - Base is the first implementation environment, not the product definition - so adding a chain touches the state reader and configuration and nothing else.
Getting it
What will it cost?
Basic protection is free and stays free on purpose. Paywalling the sentence “this application can take everything” would sell fear and starve the integrations the paid layer depends on. Pro is $6.99 a month and Family $12.99; the revenue is in the developer tiers.
Can I use it today?
Not yet - we are pre-release. The MVP ships on 14 January 2027 and runs on Base Sepolia first. If you are building something that asks users for standing authority, that is exactly when we want to talk.