Real-time exploit-exposure check for EVM wallets: dangerous ERC20 approvals cross-referenced with a live threat feed of contracts under attack. Built for AI agents — paid per query via x402, no signup, no API key.
Your agent discovers the price, pays and gets an answer — in one HTTP round trip. No account, no key management, no invoices.
check_address_risk(address) via MCP, or GET /scan on the REST API.
The first response is an HTTP 402 with the exact price.
The agent signs a gasless USDC payment (EIP-3009) on Base with its session key. One signature per call, zero interaction, settled on-chain in ~1–2s.
A risk_score (0–100), a risk_level and actionable findings —
e.g. "revoke this approval: the spender is under active exploit".
Paste an address and inspect the verdict. This demo replays real responses from the API for three representative wallets — the live paid endpoint returns exactly this schema.
Demo responses are pre-recorded. WalletTriage is probabilistic and never
says "safe" — the minimum level is low, always with a summary of what was checked.
Want to hit a real endpoint instead? The free
sandbox returns the same schema, no payment and no wallet needed.
One price, per query, settled in USDC on Base at request time. No subscription, no minimum, no credit card. If you don't call, you don't pay.
| What you get | Field |
|---|---|
| Overall risk score (0–100) and level | risk_score, risk_level |
| Actionable findings with recommended action | findings[] · recommended_action |
| Live exploit exposure (threat feed cross-reference) | exploit_exposure findings |
| Approvals summary (spam suppressed, USD at risk) | summary |
Two interfaces, same engine. Full spec: OpenAPI 3.1.
Requires Node 20+. Add the
wallettriage-mcp server to your MCP config
(e.g. claude_desktop_config.json) and fund a dedicated
session wallet with a few USDC on Base — never your main key. Tools: check_address_risk (paid) and
get_pricing (free). You can start with no key at all — see
sandbox-only mode below.
{
"mcpServers": {
"wallettriage": {
"command": "npx",
"args": ["-y", "wallettriage-mcp"],
"env": {
"GATEWAY_URL": "https://api.wallettriage.com",
"EVM_PRIVATE_KEY": "0xREPLACE_WITH_SESSION_WALLET_PRIVATE_KEY",
"MAX_PAYMENT_ATOMIC": "100000"
}
}
}
}
About EVM_PRIVATE_KEY. This is the private key
(0x + 64 hex) of a wallet — whoever holds it controls that wallet's funds entirely,
with no recovery. Create a new, dedicated session wallet for this
(cast wallet new, or a fresh account exported from your browser wallet)
and fund it with a few USDC on Base. Never use a key that holds anything you'd miss.
The key never leaves your machine. The MCP server runs locally and
signs each payment there (EIP-3009), sending only the signature — WalletTriage never
receives your key. Each signature authorizes one fixed amount to one recipient;
it is not a spending allowance. MAX_PAYMENT_ATOMIC caps it further, in USDC
atomic units (6 decimals): 100000 = $0.10 max per call, refused locally
before signing. No ETH needed — payments are gasless.
Try it with no key at all. Omit EVM_PRIVATE_KEY and the
server starts in sandbox-only mode: check_address_risk with
sandbox: true returns a free synthetic response with the identical schema.
Build and test your whole integration first; fund a wallet only once it works.
Troubleshooting (Windows / corporate networks): if you see
unable to verify the first certificate, your antivirus or proxy
intercepts TLS. Add "NODE_OPTIONS": "--use-system-ca" to the
env block so Node trusts your system's certificate store —
never disable TLS verification.
Build and test your parser before you sign a
single payment. GET /sandbox/scan is free, needs no wallet and no key, and returns
the exact same schema as the paid endpoint — it runs the same risk engine. It only
answers for four synthetic fixture addresses, one per risk level, so it can never hand out a
free verdict about a real wallet.
# free — no X-PAYMENT header, no wallet
curl "https://api.wallettriage.com/sandbox/scan?address=0x0000000000000000000000000000000000000001"
# fixture addresses (…0001 → …0004)
0x…0001 critical — exposure to a contract flagged by the threat feed
0x…0002 high — unlimited allowance to an unknown spender
0x…0003 medium — bounded allowance to an unknown spender
0x…0004 low — reputable spenders only, spam token suppressed
# response: same fields as /scan, plus
{ "sandbox": true, "data_source": "fixture", "caveats": [ "SANDBOX RESPONSE — …" ] }
Pass any other address and you get a 400 listing the fixtures — pointed, not cryptic.
From MCP, call check_address_risk with sandbox: true: same tool, same
arguments, no payment, no wallet required.
What the sandbox does not cover: the x402 payment handshake itself. The
fixture data is synthetic and the responses are deterministic — never use one to make a security
decision about a real wallet.
# 1) discover the price (free)
curl https://api.wallettriage.com/scan?address=0xABC…
# → HTTP 402 with x402 payment requirements (USDC on Base)
# 2) pay + retry with the X-PAYMENT header (any x402 client does this for you)
# → HTTP 200
{
"address": "0xabc…",
"risk_score": 92,
"risk_level": "critical",
"findings": [ … ],
"threat_feed": { "state": "ok", "updated_at": "2026-07-07T13:11:30Z", "entities": 15 },
"stateless": true
}
Nothing about you or your query is persisted. No user database, no API keys, no history. The agent holds its own state, pays and leaves.
WalletTriage never holds funds and can never move them. Mitigation actions are only suggested — you (or your agent) sign in your own wallet.
Risk scores are probabilistic signals, not guarantees. We never return "safe" — a low score always comes with the evidence we checked.
Integration questions, feedback, or a security disclosure — email wallettriage@gmail.com.
We reply from the same address. WalletTriage will never email you asking for a private key, a seed phrase or a signature — if you receive such a message, it is not us.