Skip to main content
Glama
Baneado98

approval-guardian

by Baneado98
README.md
# 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

A4.5/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern: check_approvals and revoke_plan, making them predictable and easy to understand.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessSyncing