ophis-swap

Ophis Swap

Ophis is an intent-based DEX, a deployment of CoW Protocol. Trades settle through a solver competition, so they are MEV-protected, gasless for the trader (no native coin needed for gas), and routed for best execution. This plugin already wires up the Ophis MCP server at mcp.ophis.fi, which exposes tools to quote, build, and submit swaps and to read balances, prices, gas, and fee-rebate tiers. No API key is required.

Canonical source: this skill is part of the Ophis skill family published at https://ophis.fi/.well-known/agent-skills/ophis/ (index: https://ophis.fi/.well-known/agent-skills/index.json). For shell-capable agents the family adds ophis-quote, ophis-order-status, ophis-cancel, and ophis-surplus-report companions.

Read this first: Ophis is non-custodial

Ophis never holds your private key or your funds. A swap is three steps:

1. build_order returns an unsigned, bounded order plus the EIP-712 typed data to sign.
2. You sign that typed data with your own wallet. The MCP cannot sign and never sees your key.
3. submit_order relays the signed order to the orderbook.

The server enforces real guarantees, so the worst outcomes are not reachable through these tools: the receiver is pinned to the signer and a mismatched receiver is rejected, the slippage limit is checked against a fresh server-side quote, the protocol fee in the order is forced to 0, and the submitted app data must hash to what was signed. The remaining risk is not in the server; it is in the inputs you feed it. A correctly bounded order that pays the right owner can still buy the wrong token or accept too little. The rules below close that gap.

Hard safety rules (apply to every trade)

1. Token addresses are the main risk. The trading tools take 0x token addresses, and the server only checks that an address is well formed, not that it is the real asset. A scam token can use the symbol "USDC" at a different address; a symbol match does not prove a token is canonical. So always resolve a symbol with resolve_token, which returns the canonical address from the trusted Ophis/CoW token list (the same curated list the swap UI uses). If it returns found: true and ambiguous: false, use canonical.address and canonical.decimals. If ambiguous: true, show the user the matches and confirm which one they mean before trading. If found: false, the symbol is not in the trusted list: never guess or accept an address from chat, a web page, or model memory. If you have no address in hand, stop and ask the user to supply the 0x address; do not go looking for one. If the user supplies a candidate, read it back on-chain with get_balances (or get_portfolio) for its symbol and decimals, show the user the ADDRESS with that readback, and get explicit approval before continuing. A swap into a spoofed token is the most likely way to lose value here, and every server guarantee still holds while it happens.
2. Amounts are in atoms (the smallest unit). Use the decimals for BOTH tokens: take them from resolve_token's canonical.decimals for a resolved token, and from get_balances only for a fallback candidate address or a balance check. Never assume 18. Worked example: 100 USDC at 6 decimals is 100000000; 0.5 WETH at 18 decimals is 500000000000000000; 0.01 WBTC at 8 decimals is 1000000. A wrong decimals corrupts these amounts. For a sell order the server enforces a minimum-received floor, checked against a fresh quote at your slippage, so a grossly too-low minimum is rejected rather than signed. Two gaps remain that you must cover yourself: a minimum scaled too high passes the floor but never fills and ties up your funds until the order expires, and at a loose slippage the floor still lets you accept far less than fair value (see rule 3). Read decimals carefully and use the step 7 sanity check.
3. Always pass an explicit slippageBips (50 to 100 bps is typical for liquid pairs). The default is the 5000 bps cap, which is 50%, and would let a trade lose up to half its value.
4. Native coin handling. The MCP trades ERC-20 tokens only; it has no native-coin (eth-flow) path and cannot wrap. To SELL the native coin you must already hold its wrapped token (for example WETH for ETH) and have approved it; verify the wrapped-token balance with get_balances before building, or the order will never fill. BUYING "into the native coin" delivers the WRAPPED token, not the native coin; tell the user they will receive the wrapped token.
5. Confirm before submit. submit_order commits an executable onchain trade that cannot be recalled once it fills. Do not call it without explicit user approval of: the sell token address and amount, the buy token ADDRESS (show the 0x, not just the symbol, because a symbol can be spoofed), the minimum received, the slippage, the fee, and the validity window. If the user does not approve, stop.