ecosystem: add RugGuard — pre-trade rug-check API for AI agents

[dbe006]

Summary

Adds RugGuard to the ecosystem under "Services/Endpoints".

RugGuard is a pre-trade rug-check API for AI agents. Given a token contract on Base or Solana, it returns a weighted risk score 0–100, a verdict, and structured red flags (owner renounced, LP locked, honeypot signatures, top10 concentration, mint authority, bytecode similarity to known rugs, deployer rug history, etc.).

• Pricing: $0.01 quick scan, $0.05 deep scan, $0.005 explain
• Settled in USDC on Base via the Coinbase CDP facilitator (x402)
• No API key, no signup — the wallet that pays is the identity
• Live on x402scan: server 88f6ecef-5668-4def-90a3-6984865f0e06
• 2 paid scans already settled on Base mainnet via the dual-mode v1/v2 wire format

Files added

• typescript/site/app/ecosystem/partners-data/rugguard/metadata.json
• typescript/site/public/logos/rugguard.png (512×512, 95 KB)

No existing files modified.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 1 Sum 2

[TateLyman]

Ran a no-payment external pass against the public RugGuard OpenAPI. No X-PAYMENT, no payment signature, no wallet, and no paid calls.

Repro:

npx --yes x402-surface-check@latest https://rugguard.redfleet.fr/openapi.json --limit 8 --origin https://rugguard.redfleet.fr

What looks good:

• /openapi.json is reachable and machine-readable.
• Six sampled paid routes return structured x402 402 challenges before execution: quick scan, deep scan, explain, discover, watch, and wallet profile.
• The observed prices match the product copy closely: /bin/zsh.01, /bin/zsh.05, /bin/zsh.005, and /bin/zsh.50 where expected.
• Public /v1/metrics / health-style routes remain free, which is a good separation.

Patch notes before/after merge:

• P1: Actual 402 challenge responses do not expose Access-Control-Allow-Origin, so browser agents cannot read the payment requirements cross-origin.
• P1: OPTIONS preflight returns 405 and does not allow X-PAYMENT; browser-based x402 clients will fail before retrying with payment.
• P1/P2: POST /v1/scan_batch returned validation 422 before a payment challenge to the no-payment probe. If batch scan is intended to be paid, return the 402 challenge before request validation or include a safe OpenAPI example body.

If this is intended to be server-to-server only, documenting that scope would resolve the CORS items. Otherwise I would add OPTIONS handling plus CORS headers to both preflight and actual 402 responses before relying on browser agents.

[dbe006]

Thanks @TateLyman for the careful pass! All three blockers are deployed and live now.

P1.1: CORS on 402. Custom exception handler now attaches Access-Control-Allow-Origin and Access-Control-Expose-Headers (Payment-Required, Payment-Response, X-Payment-Response, plus the X-RugGuard-* webhook headers) on every 402 response. Browser-side JS can now read the spec body of the challenge.

P1.2: OPTIONS preflight. Mounted CORSMiddleware globally with allow_methods=[GET, POST, DELETE, OPTIONS] and allow_headers covering X-Payment, Payment-Signature, Content-Type, X-RugGuard-Secret. max_age=600 caches preflights for 10 min per origin.

P1/P2: batch 422 → 402. Registered a RequestValidationError handler scoped to POST /v1/scan/batch that converts the validation 422 into a 1-item-priced 402 challenge (5000 atomic USDC = $0.005) with a hint field documenting the expected body shape. Other endpoints' 422s are untouched — we only rewrite where a browser probe needs the challenge to discover pricing + payTo + asset.

Live verification:

$ curl -i -X OPTIONS -H "Origin: https://example" -H "Access-Control-Request-Method: GET" -H "Access-Control-Request-Headers: x-payment" https://rugguard.redfleet.fr/v1/scan/base/0x4ed4E862860beD51a9570b96d89aF5E1B0Efefed
HTTP/2 200
access-control-allow-origin: *
access-control-allow-methods: GET, POST, DELETE, OPTIONS
access-control-allow-headers: Accept, Accept-Language, Content-Language, Content-Type, Payment-Signature, X-Payment, X-RugGuard-Secret
access-control-max-age: 600

$ curl -i -H "Origin: https://example" https://rugguard.redfleet.fr/v1/scan/base/0x4ed4E862860beD51a9570b96d89aF5E1B0Efefed
HTTP/2 402
access-control-allow-origin: *
access-control-expose-headers: Payment-Required, Payment-Response, X-Payment-Response, ...
payment-required: eyJ4NDAyVmVyc2lvbiI6Mi... # v2 challenge, base64
{"x402Version":1,"accepts":[...]} # v1 body, dual-mode

$ curl -i -X POST -H "Content-Type: application/json" -d '[]' https://rugguard.redfleet.fr/v1/scan/batch
HTTP/2 402
{"x402Version":1,"accepts":[{"maxAmountRequired":"5000",...}],
"hint":"POST /v1/scan/batch expects a JSON array body like [...]"}

6 new regression tests pin the contracts (CORS on paid endpoints, OPTIONS preflight, 402 includes Access-Control-Expose-Headers, empty and malformed bodies on batch return 402 not 422). 397/397 unit tests pass.

Server-to-server was the initial target audience, but the CORS fix is the right call regardless. Any in-browser x402 client (web-based agent UIs, browser extensions, SSE-transport MCP) was locked out before this. Thanks again for the careful probe.