approval-guardian
# approval-guardian π‘οΈ
**Find the token approvals draining your wallet β and get the revoke calldata.**
`approval-guardian` is an [MCP](https://modelcontextprotocol.io) server **and** a pay-per-call [x402](https://x402.org) HTTP API. Give it a wallet `address + chain` and it returns a **CLEAN / REVIEW / AT_RISK** verdict listing every active ERC-20 approval, worst first, with the exact `approve(spender, 0)` calldata to revoke each one.
Unlimited token approvals are the **#1 way DeFi wallets get drained** β a single bad `approve()` lets a spender move your entire balance of that token, forever, in one transaction.
> β οΈ **Read-only risk screen, not financial advice.** approval-guardian never holds a key and never moves funds. Revoking is a transaction **you** sign. Absence of findings is not proof of safety.
## Why it exists (the moat)
To know what a wallet has *approved*, an agent that "just reads the chain" must:
1. Pull **every** ERC-20 `Approval` log the wallet ever emitted (paginated `eth_getLogs` with the right `topic0` + owner topic, respecting per-RPC block-range caps).
2. For each `(token, spender)` pair, read the **LIVE** `allowance()` β because a later `approve(0)` or a spend may have changed it. Stale logs lie.
3. Read each token's `decimals`/`symbol` to turn a raw allowance into a human amount.
4. **Classify the spender**: is it a contract at all? a plain wallet (EOA)? an **EIP-1967 upgradeable proxy** whose code can be swapped behind your approval? a recognised router/permit/locker?
5. Score the blast radius and order the revokes.
`approval-guardian` batches all of that over public RPCs and returns one prioritized report. That live aggregation β not a static answer β is what an agent pays for.
## What it catches
| | |
|---|---|
| β»οΈ **Live allowances** | only approvals with `allowance > 0` *right now* count β stale Approval logs are filtered out |
| π» **EOA spenders** | approving a token to a plain wallet (not a contract) is the signature of a drainer phishing scam β flagged **critical** |
| βΎοΈ **Unlimited** | infinite (`2^256-1` / `2^96-1`) allowances stay exploitable forever, in one call |
| π **Upgradeable** | spender is an EIP-1967 proxy whose implementation can be replaced |
| β
**Known routers** | recognises Uniswap / Permit2 / 1inch / 0x / PancakeSwap so you aren't scared off safe infra |
| π§Ύ **Revoke calldata** | every finding ships the exact `approve(spender, 0)` calldata to sign |
## Use as an MCP server (free)
```json
{
"mcpServers": {
"approval-guardian": { "command": "npx", "args": ["-y", "approval-sentinel-mcp"] }
}
}
```
Tools:
- **`check_approvals`** β full approval-risk report. Params: `chain`, `wallet`, `deep` (optional, full history).
- **`revoke_plan`** β just the ordered list of risky approvals + revoke calldata. Params: `chain`, `wallet`, `minRisk`.
Or connect over HTTP at `POST /mcp`.
## Free HTTP API
```
GET /check?chain=base&wallet=0xYourWallet
GET /check?chain=ethereum&wallet=0x...
```
Returns the active approvals worst-first, each with `revokeCalldata`.
## Pay-per-call (x402)
The `/pro/*` routes are gated by [x402](https://x402.org). Your agent pays **$0.20 USDC** per call automatically β no sign-up, no API key. The pro scan covers **full on-chain history**; settles on-chain (Base) to the operator wallet.
```
GET /pro/check?chain=base&wallet=0x... # 402 β pay β deep report
GET /pro/revoke_plan?chain=base&wallet=0x...
```
## Chains
Ethereum Β· Base Β· BSC Β· Polygon Β· Arbitrum β all via public, key-free RPCs.
## Part of the guardian set
[npm-guardian](https://github.com/Baneado98/npm-guardian) Β· [contract-auditor](https://github.com/Baneado98/contract-auditor) Β· [rug-check](https://github.com/Baneado98/rug-check) Β· **approval-guardian**
---
Source & docs: github.com/Baneado98/approval-guardian Β· MIT
TDQS
Scored across 2 tools
The two tools have distinct and complementary purposes: check_approvals performs an audit and provides a verdict, while revoke_plan generates a list of revoke actions. There is no overlap in functionality.
Both tool names follow a consistent verb_noun pattern: check_approvals and revoke_plan, making them predictable and easy to understand.
With only 2 tools, the server is minimal but well-scoped for its specific purpose of auditing and planning revocations. It covers the essential operations without unnecessary bloat.
The tools cover the core workflow of auditing approvals and generating a revocation plan. The lack of a tool for executing revocations is intentional (read-only design), so the surface is complete for its stated domain.