Proposal: optional Jarvis best-execution route for Base MCP OpenSea swaps

[yl124915300-dot]

Integration proposal

Add an optional, Base-only Jarvis best-execution branch to the existing OpenSea swap plugin. The current OpenSea quote remains the default; this branch runs only when the user explicitly asks for Jarvis.

Problem

Base MCP already has a safe unsigned calldata -> send_calls -> user approval flow. The OpenSea plugin currently obtains a single OpenSea swap quote. For users who explicitly opt in, there is no documented pre-signing hook to compare the existing Jarvis 0x and OKX routes while preserving Base MCP's approval boundary.

Proposed flow

existing exact-input Base swap intent
  -> optional Jarvis route request
  -> compare existing 0x and OKX quotes
  -> fee-disclosed best unsigned calldata OR NO_MONETIZABLE_ROUTE
  -> existing Base MCP send_calls
  -> buyer reviews and signs (or rejects)

Scope is intentionally narrow:

• opt-in only; OpenSea stays the default
• Base chain ID 8453 only
• exact-input swaps among USDC, WETH, and DAI only
• no new provider
• no custody, private keys, signing, broadcasting, gas payment, subsidy, or Jarvis capital
• returned to, data, and value are passed through unchanged
• NO_MONETIZABLE_ROUTE stops without creating a transaction
• surfaces that cannot POST to the Jarvis host retain the default OpenSea path

Fee disclosure

A route is accepted only when the response includes the complete machine-readable disclosure:

• feeBps
• feeRecipient
• feeToken
• expectedFeeRaw
• expectedFeeUsd

The host must display the provider and fee disclosure and must not rewrite fee-bearing calldata. The buyer still makes the final decision in the existing Base Account approval flow.

Security and validation

The prepared one-file documentation patch targets only:

skills/base-mcp/plugins/opensea.md

It adds the optional branch immediately after the existing swap response mapping and does not change Base MCP code, wallet tools, the OpenSea default, or any provider logic.

Validated locally against the current target file (blob fc75aa35a83949e1b45629d2e4ebdc2fec68721e):

• frozen Router v0.2.0 hardening suite: 14/14 PASS
• live read-only routing: 0x SUCCESS, OKX SUCCESS
• observed result: NO_MONETIZABLE_ROUTE
• signed: false; broadcast: false; gas paid: false
• malformed/wrong-chain/fee-inconsistent responses fail closed
• Jarvis custody: 0; Jarvis capital spend: 0

Public route builder: https://jarvis-orderflow-router.yl124915300.workers.dev/v1/route

No transaction, settlement, revenue, or external user adoption is claimed from these tests.

Contribution-policy fit / maintainer ask

The current contribution policy limits code contributions to the Base core team, so this is a proposal rather than an unsolicited PR.

If the integration is a fit, could maintainers:

1. confirm interest and the preferred review path;
2. review/recreate the minimal optional documentation branch in the core repository; and
3. only after acceptance, decide whether to add the Jarvis host to the appropriate web_request allowlist?

I can provide the exact one-hunk patch inline on request.