Integration proposal: safe preflight and buffered Base USDC AutoFund

[crystalsignal]

Problem

MCPay's client proxy already coordinates x402 negotiation, wallet payment, confirmation, and retry. On Base, an otherwise funded agent may hold ETH/WETH but lack enough USDC for the requested tool, forcing a manual interruption. A separate transaction preflight can also reduce unsafe token, approval, slippage, and calldata signing.

Proposed optional client hook

At the existing “proxy cannot/shouldn't pay” client branch:

1. call SafeRoute Proof for the proposed transaction and require its signed ALLOW result (or surface BLOCK/REVIEW);
2. if canonical Base USDC is short, request an exact AutoFund route for the payment plus a configurable residual buffer;
3. verify chain 8453, payer, target balance, maximum sell, expiry, route calldata, simulation evidence, and SafeRoute's Ed25519 receipt;
4. use MCPay's local EVM wallet path to authorize the exact transaction;
5. wait for confirmation, recheck the USDC balance, and retry the MCP call once.

This is non-custodial: SafeRoute never receives the private key and cannot auto-sign or broadcast. The live public beta stays Base-only, with a $10 AutoFund cap and 100-bps slippage ceiling.

Integration surfaces:

• Remote MCP: https://saferoute-x402-production.up.railway.app/mcp
• OpenAPI: https://saferoute-x402-production.up.railway.app/openapi.json
• Wrapper source: https://github.com/crystalsignal/saferoute/tree/main/packages/x402
• Skill: https://github.com/crystalsignal/saferoute/tree/main/skills/saferoute-pay
• Release: https://github.com/crystalsignal/saferoute/pull/66

I can prepare a small client-side adapter/example after maintainers confirm the preferred package boundary. Partners can attach a verified referral code and accrue 25% of settled external SafeRoute service fees; owner/QA/self-paid/failed/duplicate calls are excluded.