#22898: feat(skills): add x402engine — invisible service access for 70+ paid APIs

## Give every OpenClaw agent access to 70+ paid APIs — for pennies, invisibly Today, if an OpenClaw agent needs real-time data (crypto prices, wallet balances, web scraping) or compute (image gen, code execution, transcription), the builder has to wire up API keys, manage billing, handle auth, and pray the provider doesn't change their pricing. The user sees the friction too — they're asked about payments, tokens, USDC. This PR makes all of that disappear. ### Before vs after **Before** — x402engine was a payment executor: ``` User: "pay 2 USDC to 0xabc..." Agent: "Payment sent. TX: 0x..." ``` The user had to know about x402, USDC, wallet addresses. It was a crypto tool, not a skill. **After** — x402engine is an invisible service layer: ``` User: "what's the price of bitcoin?" Agent: "Bitcoin is currently $97,500." ``` Behind the scenes: the skill matched the query to `crypto-price`, paid $0.001 USDC via x402, and returned the result. The user never saw a payment. ### What agents can do now | User says | What happens | Cost | |-----------|-------------|------| | "price of bitcoin" | Real-time crypto prices | $0.001 | | "generate an image of a sunset" | FLUX image generation | $0.015 | | "wallet activity of vitalik.eth" | On-chain transaction history | $0.005 | | "ask llama to summarize this" | Llama 3.3 inference | $0.002 | | "run this python code" | Sandboxed code execution | $0.005 | | "transcribe this audio" | Deepgram transcription | $0.10 | | "scrape example.com" | Web scraping | $0.005 | | "resolve vitalik.eth" | ENS resolution | $0.001 | | "create a video of a cat" | Video generation | $0.30 | 70+ services across crypto, wallet, image, video, LLM, code, audio, web, storage, and ENS — all auto-discovered from the gateway catalog. ### How it works ``` User query → intent-router.js: scores query against 70+ service descriptions → discovery.js: fetches live catalog (60s cache, auto-discovers new services) → policy-engine.cjs: checks spend caps, rate limits, recipient allowlist (fail-closed) → client.js: @x402/fetch signs micropayment automatically → executor.js: returns { ok, data, service } → Agent answers naturally ``` The only time the user hears about payments: **when the wallet runs out**. > "I need funds to access this service. Add USDC to your wallet to continue." ### Safety The policy engine is **fail-closed** — no policy file = deny everything. - Per-transaction caps (e.g. max $5 per call) - Daily spending limits per chain/asset - Rate limits (min interval between payments, max per hour) - Recipient allowlist — only pays known gateway addresses - Missing or invalid policy = all requests denied ### Setup (3 lines) ```bash cd skills/x402engine npm install export EVM_PRIVATE_KEY=0x... # fund with Base USDC or MegaETH USDm ``` ### Test evidence ``` npm test — 47/47 passing ``` - `discovery.test.js` — catalog fetch, caching, TTL, failure fallback - `intent-router.test.js` — query matching across all 10 service categories - `client.test.js` — wallet management, payment selector - `executor.test.js` — full flow with mocks - `policy-engine.test.js` — fail-closed, caps, allowlist - `error-taxonomy.test.js` — reason code coverage ### Technical notes - **ESM + createRequire hybrid**: `@x402/fetch` requires ESM; policy engine stays CJS via `createRequire` (proven pattern) - **Catalog-driven matching**: intent router scores against live catalog — new services added to the gateway are instantly available without skill code changes - **Autopreflight in payment selector**: policy check runs inside `@x402/fetch`'s callback, seeing the actual price from the 402 response (not a catalog estimate) - **EVM-only for v1**: Base USDC + MegaETH USDm; Solana can be added later ### Files changed | Action | Files | |--------|-------| | New | `discovery.js`, `intent-router.js`, `client.js`, `format.js` | | Rewritten | `executor.js`, `SKILL.md`, `README.md`, `cli.js`, `package.json` | | Renamed `.js` → `.cjs` | `policy-engine`, `reason-codes`, `error-taxonomy` | | New tests | `discovery.test.js`, `intent-router.test.js`, `client.test.js`, `executor.test.js` | | Deleted | `test/routing.test.js` (tested relay spawning, which is gone) | <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR introduces `x402engine` as an invisible API access layer that transparently handles micropayments for 70+ paid services. The implementation transforms the skill from a payment executor into a service discovery and routing layer. **Major changes:** - Added catalog-driven service discovery (`discovery.js`) with 60s TTL caching and auto-discovery of new services - Implemented intent routing (`intent-router.js`) with synonym expansion and parameter extraction across 10 service categories - Built fail-closed policy engine (`policy-engine.cjs`) with per-tx caps, daily spending limits, rate limiting, and recipient allowlisting - Created payment wrapper (`client.js`) integrating `@x402/fetch` with autopreflight policy checks - Added comprehensive test coverage (47 tests) across all core modules **Architecture strengths:** - Catalog-driven design eliminates hardcoded service lists — new gateway services are instantly available - Policy autopreflight runs inside payment selector callback, seeing actual 402 response prices before signing - Fail-closed security model — missing/invalid policy denies all requests - Clean separation: discovery → routing → policy → payment → execution **Code quality:** - Well-structured with clear module boundaries - Comprehensive test coverage for discovery, routing, policy enforcement, and error paths - Good documentation in SKILL.md and README.md <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with minimal risk — well-tested new feature with strong security model - Strong implementation with comprehensive tests (47 passing), fail-closed policy engine, and clear architecture. Only minor style issue found (unused constant). The catalog-driven design is elegant and the security model is sound with recipient allowlisting and spending caps enforced before payment signing. - No files require special attention — all core modules have good test coverage and follow consistent patterns _{Last reviewed commit: ed77854} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->