Add o1.exchange trading plugin

[JerryPan2718]

Summary

• Adds a new Base MCP plugin for the o1.exchange trading API
• Supports token swaps on Base and BSC via http-api integration → send_calls
• Includes Bearer token auth, MEV protection, optional Permit2 gasless approvals, and slippage controls

Test plan

• Verify frontmatter conforms to plugin-spec.md (chains, integration type, risk tags, auth)
• Confirm api.o1.exchange is reachable and /order endpoint returns expected unsigned tx shape
• Validate send_calls mapping: { to, data, value } from unsigned object, gasLimit/chainId stripped
• Test example prompts end-to-end on Base with a real API token

🤖 Generated with Claude Code

[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

[stephancill]

Thanks for the submission. The documented endpoints resolve and the response shapes match, but the Permit2 signing flow has a blocking issue:

Required

• The Permit2 flow string-replaces a fixed 65-byte SIGNATURE_PLACEHOLDER in unsigned.data with the signature. This only holds for EOA signatures. Base smart-account signatures (ERC-1271/6492) are variable-length (unbounded; >200 bytes in practice) and the signature is ABI-encoded as a dynamic bytes field with a length prefix and offset. Splicing such a signature into a fixed 65-byte slot produces malformed calldata, so the flow fails for smart-contract wallets — the common Base account type. Encode the signature as dynamic bytes (and support ERC-1271 verification), or have the build endpoint accept the signature and re-encode server-side.

Minor

• Submitting the order through send_calls bypasses o1's /order/complete private-mempool relay, so mevProtection does not apply to these submissions. State this so it isn't presented as MEV-protected.
• The API-token URL is inconsistent across sections; use the one that resolves.
• ## Auth should document token lifetime/refresh, and ## Submission should state the value hex-wei contract.
• Consider adding low-liquidity to risk for arbitrary-token / pool-targeted trades.

[youssefea]

Note: this is an AI-generated review. An automated, read-only API/endpoint health check — not a human review.

Thanks for putting this together — the o1.exchange integration is shaping up well. As part of reviewing the Wave 2 submissions I ran an automated, read-only health check against the APIs this plugin documents. The endpoints themselves look healthy; there's one signing-flow item worth addressing before merge, plus a couple of notes:

Findings

• Blocking — Permit2 flow uses a fixed 65-byte EOA signature placeholder. Orchestration step 3 of the Permit2 swap says to replace 0x42f6…62ff1b in unsigned.data with the signature from sign. That placeholder is exactly 130 hex chars (65 bytes, trailing v=0x1b) — an EOA r||s||v signature. The default Base MCP wallet is a smart contract, so sign (eth_signTypedData_v4) returns a variable-length ERC-1271/6492 signature much longer than 65 bytes. A fixed-width string-replace into the calldata will either fail or produce malformed calldata, and no length/offset update is documented. The Permit2 path is broken for the default wallet.
• POST /api/v2/order and POST /api/v2/order/complete (host api.o1.exchange): both return 401 {"success":false,"code":401,"message":"Unauthorized: Missing or invalid token"} unauthenticated, and a fake Bearer token also returns 401 Unauthorized. This positively confirms the auth: api-key claim — the endpoints are real and gated. The authenticated 200 response shape (transactions[].unsigned, permit2.eip712) could not be verified read-only without a token; only the {success, code, message} error shape was observed.
• OPTIONS /api/v2/order returns 404 ("No matching routes found") — no CORS preflight route. Fine for harness/server-side web_request, but the chat-only web_request path in "Surface Routing" may hit a CORS preflight against this host; worth confirming.
• Allowlist is correct: requires.allowlist: [api.o1.exchange] matches the only programmatically-contacted host; o1.exchange is a human-facing token-generation URL only.
• value is documented as hex (0x…) and gasLimit/chainId are stripped before send_calls, so there is no decimal-to-hex gap. The partner unsigned.to (router) is passed straight into send_calls without validation against a documented router constant — acceptable given the authenticated build API, but noted as untrusted-calldata surface.

What was checked

Read-only probes only: dig/curl -sI for DNS+TLS on api.o1.exchange and o1.exchange; unauthenticated and fake-Bearer POSTs to /api/v2/order and /api/v2/order/complete with empty and deliberately-invalid bodies (HTTP status + JSON error shape vs the doc, and auth-claim verification); OPTIONS/GET method probes; and byte-length analysis of the documented Permit2 placeholder signature. No SDK/CLI package or on-chain contract addresses are documented, so none required npm view or cast code checks. This was strictly read-only: no transactions were submitted, no funds were moved, and no API keys were used.

Really appreciate the contribution — happy to clarify any of the above. Since this is an automated check, please double-check anything that looks unexpected on your end before changing it.

---

Generated by an AI assistant (Claude) after an automated, read-only deep analysis of the API/endpoint health documented in this plugin. It checks endpoint reachability, HTTP status codes, response shapes, auth behavior, SDK/package existence, and on-chain contract presence — it does not submit transactions or move funds. Please independently verify any finding before acting on it.