Risk check for EVM wallets: active ERC20 approvals cross-referenced with contracts under live exploit, wallet-drainer spenders we derive ourselves, and known-bad address lists. Every finding says which of the three backs it. 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 findings that name their evidence —
e.g. "revoke this approval: the spender is a known wallet-drainer contract".
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
}
An HTTP client alone cannot complete a paid call. Postman, Insomnia,
a browser or plain curl will get you to the 402 and let you read
the price — but step 2 requires signing an EIP-3009 payment with a wallet key, which
those tools cannot do. Use an x402 client library (@x402/fetch), the
wallettriage-mcp server,
or any x402-aware agent runtime. A signed X-PAYMENT header is valid for
one request, so it cannot be pasted and reused.
Free endpoints — /sandbox/scan and the 402 price discovery above —
work fine in any HTTP client.
New to this? Follow the step-by-step REST guide: it takes you
from a free Postman request to your first paid scan, with nothing assumed.
Three kinds of evidence, and the API tells you which one produced each finding
(evidence_class). They are not equivalent — a delayed list match is not the same
claim as a contract being drained right now, and we don't dress one up as the other.
Contracts showing anomalous outflow, unexpected proxy upgrades or mass approvals to a freshly created contract — detected from on-chain streams, typically within seconds of the block. Severity: critical.
We visit live phishing sites in a disposable sandbox with a mock wallet and capture the spender address the drainer kit asks permission for — method and function recorded as evidence. This signal is ours: not a reseller's list, and every entry passed a human review plus a false-positive gate before shipping. Severity: critical.
Public blocklists of drainer and phishing addresses. Useful, but delayed by up to 7 days upstream — an approval to a known-bad address is worth revoking even a week late, though it is hygiene rather than live detection. We say so in the response. Severity: high.
Coverage is EVM approvals: Ethereum, Base, Polygon, Arbitrum,
Optimism and BNB Chain. Non-EVM drainers (Solana kits, for instance) are out of scope today, and the
response never claims otherwise — when the feed holds no live-exploit entities at all, the answer
says that too, in caveats.
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.
Each finding names the evidence class behind it, and the response reports what the feed actually held when it was served — including when it held no live-exploit entities. A big number of tracked entities is not a promise of live coverage, so we publish the breakdown instead of a single figure.
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.