OpenFinance: one market API for agents — with Solana spot & DeFi
OpenFinance (by GTR.Trade) gives an AI agent one API key to trade crypto spot, perps, US equities, prediction markets, and DeFi across chains — Solana, Ethereum, and Base for spot & DeFi. It ships as an MCP server that builds and simulates transactions for the agent to sign itself, so keys stay with the agent.
Most agent-trading integrations die on plumbing: every market is a different broker, a different auth model, a different chain, a different SDK. OpenFinance — built by GTR.Trade — collapses that into one premise: "Every market. One API." A single key gives an AI agent access to crypto spot and perps, US equities, prediction markets, and DeFi across multiple chains — and Solana is one of the three it runs spot & DeFi on, which is why it's worth a look here.
What it covers
The pitch is breadth behind one account. What's live today versus coming, in their own framing:
Live today
Crypto spot & DeFi — Ethereum · Solana · Base
Crypto perps — Hyperliquid
US equities
Prediction markets — Polymarket
Bridging + swaps — via Relay
Coming (Q3)
Forex · commodities · derivativesSolana's role in the lineup is spot trading and DeFi — one of the three chains OpenFinance routes that activity through (alongside Ethereum and Base). Perpetuals in their stack run on Hyperliquid rather than a Solana venue, so if you specifically want Solana-native perps that's a different integration; OpenFinance's Solana surface is spot and DeFi.
It ships as an MCP server
The primary interface is a Model Context Protocol server over streamable HTTP, so a model can call markets as tools. Wiring it into Claude Code is two flags and a key:
claude mcp add openfinance-tech \
--transport http \
"https://api.openfinance.tech/agent/mcp" \
--header "x-api-key: open_xxxxx"
# or pull their skills bundle:
npx skills add openfinance-tech/skills -yThere are also Python and TypeScript SDKs, and integration guides for Cursor, VS Code, Windsurf, Cline, Claude Desktop, and ChatGPT. The single API key is the whole auth model — it aggregates every connected market and broker behind one credential, which is the convenience and, as below, the thing to be deliberate about.
The design choice that matters: the agent signs
The interesting part for a Solana developer is that OpenFinance is, by its own description, a transaction-builder, not a custodian. The MCP server exposes four capabilities, and notice where the trust sits:
- Market data — multi-chain prices, funding rates, order books, metadata.
- Trade simulation — "simulate trades safely before any transaction is signed."
- Order management — place, modify, cancel (when authenticated).
- Transaction building — "prepare on-chain actions for agents to sign and submit."
For the on-chain side, OpenFinance prepares the transaction and the agent signs and submits it with its own keypair. That's the right shape: the service routes and builds, but it never holds your Solana keys, and the simulate step lets the agent preview the effect before committing a signature. It moves the custody question off OpenFinance and onto your agent's wallet — which is where, for an autonomous system, you want it.
The honest read
This is a free beta from a team trading under the GTR.Trade name, with a self-reported "$100M+ in volume" and no public audit. Treat all three of those as unverified until they aren't. The non-custodial signing model is genuinely reassuring — your keys stay yours — but the trust boundary doesn't vanish, it moves: you're trusting OpenFinance's transaction construction and its price/route data. A built transaction is only as safe as the bytes it asks your agent to sign, so the simulate step isn't a nicety — it's the check you should actually run, and you should verify what a transaction does before an agent signs it unattended.
Two more practical notes. One key unlocking every market is convenient and also a single blast radius — scope it, rotate it, and don't hand a beta a hot wallet with size on it. And "DeFi on Solana" is, at the time of writing, stated at the marketing level without a public list of which Solana protocols are wired in; confirm the specific venues you care about before you route real flow. For exploration, paper trades, and small autonomous strategies, a single-key MCP across this many markets is a legitimately useful primitive — just size your trust to a beta.
References
- openfinance.tech — the product
- docs.openfinance.tech — MCP server & SDKs
- x402 + MCP: how agents pay for tools
- Solana AI agents in 2026
- Drift — Solana-native perps
OpenFinance's bet is that the hard part of agent trading isn't any single market — it's the seam between all of them. One key, one MCP server, transactions built for the agent to sign: on Solana that means spot and DeFi an agent can reach without standing up a venue-by-venue integration. Useful, beta, and yours to verify before you sign.
Keep reading
An agent that can call any paid API on the open internet sounds great until you ask: whose money, and what stops it from draining the wallet? This is the practical wiring — x402 inside the MCP tool loop, the @x402/svm client, and the Solana agent wallets (Coinbase, Crossmint, Privy, SendAI) that enforce spend caps and allowlists.
Mastercard's Agent Pay for Machines puts the incumbent into agentic payments — but the interesting part isn't the card network, it's where the authorization lives. Agent permissions and credentials are written to public blockchains (Solana among the first three) as a 'Verifiable Intent' ledger anyone can audit, while settlement stays on Mastercard's network. A look at the architecture and how it sits beside x402.
Both x402 and Mastercard's AP4M answer the same question — how does an agent pay without a human in the loop — and they answer it differently. One is an open HTTP status code settled in USDC on Solana; the other is a permissioned network that uses public chains only as a credential ledger. Here's the head-to-head, dimension by dimension, and a decision guide.