Skip to main content
Glama
approval-guardian

approval-guardian

by Baneado98

approval-guardian πŸ›‘οΈ

Find the token approvals draining your wallet β€” and get the revoke calldata.

approval-guardian is an MCP server and a pay-per-call x402 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.

Related MCP server: chain-signer

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)

{
  "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. 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 Β· contract-auditor Β· rug-check Β· approval-guardian


Source & docs: github.com/Baneado98/approval-guardian Β· MIT

Available Tools

2 tools
check_approvalsA

Audit a wallet's ACTIVE ERC-20 token approvals (allowances) for drain risk β€” the #1 way DeFi wallets get emptied. Pulls every Approval event the wallet ever emitted, reads the LIVE allowance for each (token, spender) pair, classifies the spender (EOA / unknown contract / upgradeable proxy / known router) and returns a prioritized CLEAN / REVIEW / AT_RISK verdict listing exactly which approvals to revoke first β€” with the approve(spender,0) revoke calldata ready to sign. Read-only; never moves funds, never holds a key. Use this before/after a wallet interacts with unfamiliar dApps, when a user fears a drainer, or to harden any wallet. Chains: ethereum, base, bsc, polygon, arbitrum.

Inputs: chain (required), wallet (required), deep.

revoke_planA

Return ONLY the revoke action plan for a wallet: the ordered list of risky approvals to cancel, each with the token, spender and the exact approve(spender,0) calldata the user signs to revoke it. Use after check_approvals to get a clean, signable to-do list. Read-only; the user signs each revoke themselves.

Inputs: chain (required), wallet (required), minRisk.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    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.

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      D
      maintenance
      Non-custodial agent wallet with a transaction preflight that decodes an unsigned EVM tx and flags drain patterns (unlimited/large approval, approve-all, token & NFT transferFrom, proxy upgrade, on-chain permit, approvals hidden in multicall) before signing.
      9
      110 PyPI
      1
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      Evaluates on-chain risk for Pharos agents before executing transactions, providing verdicts (safe/caution/dangerous) and risk-bounded execution plans via Foundry cast reads.
      MIT No Attribution