AI-native runtime for Ripio trading strategies
Author in Cursor, Claude Code or any AI IDE. Deploy from GitHub into a managed cloud runtime with first-class MCP control, logs and region selection.
Section 01 · At a glance
At a glance
- Venue
- Ripio
- Venue type
- Crypto exchange (LATAM, 8-jurisdiction)
- Asset class
- Crypto with multi-fiat LATAM quote (BRL, ARS, MXN, EUR, USD)
- Supported products
- Spot trading on country-filtered pairs (BTC_BRL, ETH_BRL, BTC_ARS, BTC_MXN, BTC_EUR and others), local stablecoins (wARS, wBRL, wMXN), Ripio Trade API v4
- Runtime model
- Containerised strategy runtime
- Deployment source
- GitHub
- Languages
- Any language that runs in a container
- Common integrations
- Native Ripio Trade API v4 REST and WebSocket, CCXT, custom connectors
- AI workflow integration
- MCP control surface for Cursor, Claude Code, GitHub Copilot and CLI agents
- TradingHost role
- Runtime, deployment, logs, health checks, region selection, MCP control
- Ripio role
- Exchange account, API access, market access, execution venue
- Affiliation
- TradingHost is independent and is not affiliated with Ripio
Section 02 · What Ripio offers
What Ripio offers
Ripio offers spot trading across 8 LATAM jurisdictions with multi-fiat quote pairs (BRL, ARS, MXN, EUR, USD) and local stablecoins (wARS, wBRL, wMXN). Strategies authenticate against the Ripio Trade API v4 and operate under tiered rate limits keyed to KYC status. Country-filtered pair availability via the `countries` query parameter means a single strategy can deploy against different regional product sets. Endpoint specifics change over time. The shape is durable; the precise rate-limit weights, pair lists and minimum sizes live in Ripio's docs.
Markets and strategy patterns
- BRL-quote spot strategies (BTC_BRL, ETH_BRL, USDC_BRL)
- ARS-quote spot strategies on Argentine peso pairs
- MXN-quote spot strategies on Mexican peso pairs
- Local stablecoin trading (wARS, wBRL, wMXN)
- Cross-LATAM-fiat arbitrage strategies
- Country-filtered pair discovery via the `countries` query parameter
- WebSocket ticket-authenticated subscriptions for sensitive topics
- KYC-tiered rate-limit usage planning per account
API surface
- Product surfaces
- Spot trading on country-filtered pairs across Argentina, Brazil, Mexico, Spain, Uruguay, Colombia, Chile and the US. Pair codes use underscore notation (BTC_BRL, ETH_BRL, BTC_ARS, BTC_MXN). Local stablecoins (wARS, wBRL, wMXN) enable direct digital-currency operations. Per-pair minimum amount, minimum value and price tick must be queried per pair.
- Connection methods
- REST for order placement, account queries and pair discovery. WebSocket streams for real-time market data. Access to sensitive WebSocket topics requires a ticket obtained from POST `/v4/ticket` before the subscription, not just an API key.
- Authentication
- Tiered API rate limits keyed to KYC status. Unverified accounts: 1 request per second (~86,400 daily). Verified accounts: 3.5 requests per second (~302,400 daily). Exceeding the tier limit returns HTTP 429 with the standard retry-after header.
For specifics, refer to Ripio
Specific endpoints, rate-limit weights, pair lists, fee tiers and version history live in Ripio's documentation. Treat these as the source of truth.
Section 03 · Build with AI
Build your Ripio strategy with AI
Pick an integration method, fork a TradingHost framework starter, and author your strategy in an AI IDE. Cursor, Claude Code, GitHub Copilot and CLI-based AI agents all work with the same GitHub-native deployment loop.
Native Ripio API
Direct control over Ripio-specific behaviour, including country-filtered pair discovery and LATAM-fiat order routing.
CCXT
Common interface across Ripio and other crypto exchanges. CCXT exposes Ripio Trade via the unified `ripio` class for spot trading.
Freqtrade or Hummingbot
Neither framework lists Ripio as a first-class supported exchange today. Best path is custom or CCXT-backed implementations.
Custom connector
Your own internal trading engine or proprietary Ripio Trade API v4 integration against the REST and WebSocket surface.
Framework support for Ripio products
Coverage varies by framework. Ripio is spot-only at the venue level (no native perps or options on Trade), so the matrix is narrow by design. CCXT exposes Ripio Trade spot through its unified `ripio` class. Neither Freqtrade nor Hummingbot lists Ripio as a first-class supported exchange today; native API access reaches everything Ripio Trade v4 publishes.
✓ confirmed support per official framework docs. "no" indicates not officially documented as supported. Workflow links target /workflows/ pages currently in authoring.
TradingHost does not force a framework. It runs your project.
Author with AI
The framework starters above pair naturally with AI IDEs. The TradingHost MCP control surface closes the loop: AI tools can inspect deployments, review logs and manage the runtime alongside you, never the trade execution path.
Section 04 · Run on TradingHost
Run your code on TradingHost
Ripio provides the exchange and API access. TradingHost provides the production environment where your Ripio-connected strategy runs.
Instead of running strategy code on a laptop, desktop machine, generic VPS or manually configured server, you deploy from GitHub into a TradingHost-managed container runtime.
You
- Your repo contains your code.
- Your deployment defines how it runs.
- Your strategy connects to Ripio.
TradingHost
- Keeps the runtime online.
- Surfaces logs and health checks.
- Region selection.
- Controlled deployment surface.
Deployment flow
- STEP 01
Connect GitHub
Authorise TradingHost to access your GitHub account.
- STEP 02
Link a repo or start from a framework
Point TradingHost at your existing strategy repo, or fork a TradingHost framework runtime (CCXT) for a working baseline against the Ripio Trade API v4.
- STEP 03
Deploy into a TradingHost container
Pick a region (EU or US-East), supply the environment values your strategy needs (Ripio Trade API key, country code, WebSocket ticket settings), and deploy. TradingHost builds your container from the repo and runs your strategy on managed Kubernetes infrastructure. No local Docker install required.
- STEP 04
Monitor logs and health
Watch live logs, health and runtime state from the TradingHost dashboard. The same surface is reachable through MCP from any AI IDE, so Cursor, Claude Code or a CLI agent can read deployment state and manage the runtime alongside you.
- STEP 05
Update and redeploy
Push changes to your GitHub main branch and TradingHost redeploys automatically.
Section 05 · Operational notes
Operational notes for Ripio
Things that bite you when you actually run a Ripio strategy in a containerised cloud runtime, not in Ripio's docs, not in framework READMEs. Every claim below is quoted or paraphrased from Ripio's own documentation; the deployment-side guidance is from running these strategies on TradingHost.
01 · KYC-tiered rate limits
Unverified accounts get 1 rps; verified accounts get 3.5 rps
Ripio Trade API v4 rate limits are keyed to KYC tier rather than endpoint family. Unverified accounts are capped at 1 request per second (around 86,400 daily). Verified accounts move to 3.5 requests per second (around 302,400 daily). Exceeding the tier returns HTTP 429. A strategy that ships in unverified mode and gets promoted to verified mid-life can quadruple its safe poll cadence; conversely an unverified-tier strategy authored as if it were verified will hit 429 on day one. Encode the tier as a runtime config so the rate-limit budget is explicit.
02 · Country-filtered pairs
The `countries` query parameter is the source of truth for tradable pairs
Ripio spans 8 jurisdictions (AR, BR, MX, ES, UY, CO, CL, US) with per-country compliance tiers, and pair availability is filtered through the `countries` query parameter rather than a flat global symbol list. A pair that trades in Brazil may not trade in Argentina, and vice versa. Strategies that hardcode a symbol list against the Brazilian product set silently no-op when run for an Argentine account. Discover pairs at startup via the country-filtered endpoint instead of pinning them in code.
03 · Pair codes use underscore
BTC_BRL and ETH_BRL, not BTCBRL
Ripio pair codes use underscore notation: BTC_BRL, ETH_BRL, BTC_ARS, BTC_MXN, BTC_EUR. The convention differs from Binance and most global venues where pairs are concatenated (BTCBRL). CCXT normalises the symbol to BTC/BRL in its unified interface, but anything hitting the native API directly must use the underscore form. Strategy code that ports from another venue often silently fails on pair-not-found until the format is fixed.
04 · Per-pair minimums
`min_amount`, `min_value` and `price_tick` are pair-specific and must be queried
Pair minimums and price ticks are fiat-pair-specific. BRL pairs, ARS pairs and MXN pairs each have their own `min_amount`, `min_value` and `price_tick` values that must be queried per pair before order placement. A strategy that uses a single hardcoded minimum across BRL and ARS pairs will silently undersize or oversize trades depending on the active country. Cache the per-pair fields at startup and re-validate before each order rather than assuming a global minimum.
05 · WebSocket ticket auth
Sensitive WebSocket topics require a ticket from POST `/v4/ticket`
Public WebSocket topics (market data, orderbook) are open. Sensitive topics (account state, order events) require a ticket obtained from POST `/v4/ticket` before subscribing, not just an API key. The ticket has a short TTL and must be refreshed periodically for long-running strategies. Containers that lose the WebSocket connection and reconnect must request a fresh ticket each time; reusing a stale ticket silently fails the subscription, and order-state callbacks stop firing.
06 · Local stablecoins
wARS, wBRL and wMXN enable direct digital-currency operations
Ripio publishes local stablecoins wARS, wBRL and wMXN that enable direct digital-currency operations against the BRL, ARS and MXN markets. These differ from USDT/USDC and may have different liquidity, settlement and fee characteristics. Strategies designed around USDT carry assumptions do not automatically transfer to wARS or wBRL. Validate the depth and spread on the local stablecoin pairs separately before sizing live exposure.
Section 06 · Built for
Built for
TradingHost Ripio runtimes are best suited to:
- Developers building strategies in AI IDEs (Cursor, Claude Code)
- Systematic crypto traders
- Quant developers
- CCXT users
- Teams moving from VPS hosting to containerised deployment
Connecting GitHub and creating your first strategy is free.
Section 08 · FAQ
FAQ
No. TradingHost is independent and is not affiliated with Ripio.
No. Your strategy code connects to Ripio and sends instructions according to your own logic, account permissions and integration method. TradingHost provides the runtime where that code runs.
No. Ripio API access is provided by Ripio. You are responsible for your Ripio account, API permissions, credentials and compliance with Ripio’s terms.
No. TradingHost is the cloud runtime where your strategy code runs. We do not provide signals, AI prediction models or pre-built bots. With TradingHost you write or generate the strategy yourself (often with Cursor or Claude Code), keep it in GitHub as your code, and use TradingHost to run it in production. 3Commas, Cryptohopper and similar products own the strategy logic; TradingHost runs your strategy.
AWS and DigitalOcean give you raw compute. You handle OS updates, container orchestration, log shipping, secret rotation, region failover and uptime monitoring yourself. TradingHost gives you a managed runtime purpose-built for trading strategies: GitHub-native deployment, MCP-driven control from AI IDEs, log and health surfaces out of the box. If you want to operate the infrastructure yourself, AWS works. If you want the runtime as a managed service, TradingHost is the shorter path.
Yes. TradingHost runs Python strategies; pick the framework runtime that matches your stack or deploy your own repo.
Yes. TradingHost supports any language that can run inside a container.
Yes. CCXT ships a unified `ripio` class that covers spot trading on Ripio Trade pairs. Drop your CCXT strategy into a container, point it at GitHub, and TradingHost runs it like any other Python or Node project. See the CCXT framework runtime for the full setup story.
Yes. Ripio LATAM-fiat pairs (BTC_BRL, ETH_BRL, BTC_ARS, BTC_MXN, BTC_EUR and others) are reached through the same REST and WebSocket APIs as the global pairs. The strategy code inside your container authenticates with your Ripio Trade API key, and TradingHost is venue-agnostic at the runtime level. Note that pair availability is country-filtered through the `countries` query parameter, so discover pairs at startup rather than hardcoding them.
Yes, if your project is designed that way. You can run multiple strategy processes or services inside one runtime, or separate them into different runtimes for isolation and operational clarity. See the TradingHost runtime page for the multi-strategy model.
The fastest path is to fork a TradingHost framework runtime: CCXT for a ready-to-deploy project. Or connect your own GitHub strategy repo. Linking a GitHub repo and creating a strategy is free; runtime plans are listed on the pricing page.
In your GitHub-controlled secrets workflow. TradingHost reads them at runtime through GitHub repository secrets, environment secrets or your own approved secret-management process. TradingHost does not need custody of your API key and secret. See platform secrets for the full handling model.
No. Strategies should never need withdrawal permissions. Scope your API key down to trading and account-state reads only, and keep withdrawal off the key entirely.
Yes. TradingHost supports MCP-based control for AI IDEs including Cursor, Claude Code, GitHub Copilot and CLI-based AI agents. AI tools can inspect deployments, review logs, restart strategies and manage runtime workflows. MCP is a control and observability surface, not the trade execution path. See the MCP control surface for the full picture.
Both. The MCP control surface works equally well from CLI-based agents (Claude Code CLI, custom MCP clients, scripted MCP calls) and from inside an IDE. The GitHub-native deployment loop also works without any AI tooling: a regular git push to your main branch triggers a redeploy.
The runtime detects the crash and exposes the relevant logs and health information. Where supported, the affected strategy can be restarted without disrupting other strategies running in the same container. Your strategy code is still responsible for safe error handling, duplicate-order protection and risk controls. See observability for the logs and health surface.
Ripio Trade API v4 rate limits are tiered by KYC status. Unverified accounts get 1 request per second; verified accounts get 3.5 requests per second. Exceeding the tier returns HTTP 429. The fix is to size your request cadence to the tier your account currently sits in, treat the tier as runtime config rather than a constant, and back off on 429 with exponential jitter. See the Operational notes section above for the full guidance.
TradingHost runs in the EU and US-East regions. Pick the region closest to the matching engine your strategy depends on. See the regions page for routing and proximity details.
No. TradingHost is focused on production runtime and deployment. Backtesting belongs in your research stack, framework or AlgoBuilder.