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.