AI-native runtime for Coincheck 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
- Coincheck
- Venue type
- Crypto exchange (NASDAQ-listed CNCK)
- Asset class
- Crypto (JPY-quoted spot)
- Supported products
- JPY-quoted spot trading on BTC, ETH, XRP and other listed pairs. Coincheck also offers separate JPY-quoted derivative products with their own market_type designation distinct from spot.
- Runtime model
- Containerised strategy runtime
- Deployment source
- GitHub
- Languages
- Any language that runs in a container
- Common integrations
- Native Coincheck 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
- Coincheck role
- Exchange account, API access, market access, execution venue
- Affiliation
- TradingHost is independent and is not affiliated with Coincheck.
Section 02 · What Coincheck offers
What Coincheck offers
Coincheck is a JP-regulated crypto exchange offering JPY-quoted spot trading on BTC, ETH, XRP and other listed pairs, plus separate JP derivative products with their own market_type designation. Strategies authenticate with HMAC-SHA256 signatures using a monotonically increasing millisecond nonce. Endpoint specifics change over time; Coincheck reserves the right to adjust rate limits based on system load with no advance notice. The shape is durable; the precise rate-limit numbers and symbol lists live in Coincheck's docs.
Markets and strategy patterns
- JPY-quoted spot strategies (BTC_JPY, ETH_JPY, XRP_JPY)
- Long-tail JPY altcoin spot trading
- Cross-venue JPY arbitrage paired with bitFlyer or other JP venues
- Public WebSocket-driven market data consumers
- Private WebSocket account and order event streams
- Order book imbalance strategies on JPY pairs
- Sub-account-isolated multi-strategy deployments
- Funding-rate trading on JP derivative products (where available)
API surface
- Product surfaces
- JPY-quoted spot trading on BTC, ETH, XRP and other listed pairs. Separate JP derivative products carry their own market_type designation distinct from spot. Coincheck is a JP-regulated exchange operating under JFSA oversight; product availability is JP-tilted.
- Connection methods
- REST at https://coincheck.com/api/ for order placement, market data and account queries. Public WebSocket for real-time market data without authentication. Private WebSocket for account-scoped order and balance events; each private WebSocket connection requires a per-connection auth handshake at session start.
- Authentication
- API key, secret and nonce per signed request. The signature is HMAC-SHA256 over nonce + URL + body, signed with your secret. The nonce must be a monotonically increasing millisecond-precision integer; a nonce equal to or below the previously-seen nonce is rejected. Permissions are scoped per key. Strategies should never need withdrawal permission.
For specifics, refer to Coincheck
Specific endpoints, rate-limit numbers, symbol lists, fee tiers and version history live in Coincheck's documentation. Treat these as the source of truth.
Section 03 · Build with AI
Build your Coincheck 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 Coincheck API
Direct control over Coincheck-specific behaviour, nonce handling and order execution logic.
Hummingbot
Framework-based deployments using Hummingbot strategy structure and configuration model.
Custom connector
Your own internal trading engine or proprietary Coincheck integration.
Framework support for Coincheck products
Framework coverage is thin for Coincheck. CCXT exposes JPY-quoted spot through the unified coincheck class. Hummingbot and Freqtrade do not list Coincheck in their officially supported exchanges. JP derivative products are not surfaced as first-class framework primitives; for derivatives, target the native Coincheck API.
✓ confirmed support per official framework docs. "no" indicates not officially documented as supported.
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
Coincheck provides the exchange and API access. TradingHost provides the production environment where your Coincheck-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 Coincheck.
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.
- STEP 03
Deploy into a TradingHost container
Pick a region (EU or US-East), supply the environment values your strategy needs (Coincheck API key and secret, etc.), 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 Coincheck
Things that bite you when you actually run a Coincheck strategy in a containerised cloud runtime, not in Coincheck's docs, not in framework READMEs. Every claim below is quoted or paraphrased from Coincheck's own documentation; the deployment-side guidance is from running these strategies on TradingHost.
01 · Nonce ordering
Nonce must be a monotonically increasing millisecond-precision integer
Coincheck signed requests carry an ACCESS-NONCE header that must be strictly greater than the previously-accepted nonce for that key. A nonce equal to or below the last-seen value returns a nonce-error response. The recommended pattern is a millisecond-precision Unix timestamp, but any monotonic counter works. Two strategies sharing one key will conflict if they emit overlapping nonces; one scoped key per strategy avoids the entire class of nonce-collision bugs.
02 · Shared rate limit
4 requests per second shared across all pairs for new orders; 1 req/sec per-pair for order detail queries
Coincheck enforces a shared 4 requests per second cap across all pairs for new order placement. Order detail queries are capped separately at 1 request per second per pair. Hitting either ceiling returns 429 responses. Coincheck's API documentation includes the explicit caveat that rate limits "may be changed depending on system load" without advance notice. Size your concurrency below the published ceilings to leave headroom, and treat 429 as an instruction to back off respectfully.
03 · Private WebSocket auth
Private WebSocket channels require a per-connection auth handshake at session start
Coincheck public WebSocket channels (trades, orderbook) connect without authentication. Private WebSocket channels (account-scoped order and balance events) require a per-connection authentication handshake at session start, sent as part of the subscription message rather than at the HTTPS handshake. Strategies that authenticate only at HTTPS handshake see private subscriptions silently drop or refuse the subscription.
04 · Three-header signature
ACCESS-KEY, ACCESS-NONCE, ACCESS-SIGNATURE are all required
Coincheck private REST requests carry three headers: ACCESS-KEY (your API key), ACCESS-NONCE (monotonic millisecond integer) and ACCESS-SIGNATURE (HMAC-SHA256 of nonce + URL + body, signed with your secret, hex output). Strategies that omit any of the three return signature-error responses. The canonical body must match exactly what is sent; serialise JSON with stable key ordering before signing.
05 · Derivative market_type
JP derivative products carry a separate market_type designation from spot
Coincheck offers separate JP-licensed derivative products in addition to JPY-quoted spot. Derivative products are flagged via a distinct market_type designation; strategies that filter by symbol alone without checking market_type can accidentally route spot logic against a derivative product or vice versa. Pin market_type as an explicit filter at order placement and at fill processing.
06 · Key scoping
One scoped key per strategy, never one master key shared across strategies
Coincheck API keys carry per-permission scoping (read, trade, withdrawal). Strategies should never need withdrawal scope; isolate withdrawal-capable keys on a separate manually-managed credential outside the container runtime. Per-strategy keys with only the scopes that strategy needs contain the blast radius if a key leaks. Per-strategy keys also avoid the nonce-collision pattern that occurs when two strategies share one key.
Section 06 · Built for
Built for
TradingHost Coincheck runtimes are best suited to:
- Developers building strategies in AI IDEs (Cursor, Claude Code)
- Systematic crypto traders
- Quant developers
- JP-licensed Coincheck account holders
- 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 Coincheck.
No. Your strategy code connects to Coincheck and sends instructions according to your own logic, account permissions and integration method. TradingHost provides the runtime where that code runs.
No. Coincheck API access is provided by Coincheck. You are responsible for your Coincheck account, API permissions, credentials and compliance with Coincheck’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 exposes Coincheck through the unified `coincheck` class for JPY-quoted spot. JP derivative products are not surfaced as a first-class CCXT primitive; for derivatives, target the native Coincheck API. See the CCXT framework runtime for the full setup story.
TradingHost is venue-agnostic at the runtime level: any code that can authenticate against Coincheck can run inside a container, including strategies that target JP derivative products. The implication you have to design for is that derivative products carry a separate market_type designation from spot. Pin market_type as an explicit filter at order placement and at fill processing so spot logic does not accidentally route against a derivative product.
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 spot project. Or connect your own GitHub strategy repo if you target the native Coincheck API. 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. Use scoped permissions (read, trade) and IP whitelisting where appropriate.
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.
Coincheck requires ACCESS-NONCE to be a strictly increasing millisecond-precision integer per API key. A nonce equal to or below the previously-accepted value returns a nonce-error response. The most common cause is two strategies sharing one key and emitting overlapping nonces, or a container clock that rewinds (NTP correction in the wrong direction). Use one scoped key per strategy and trust the runtime's NTP-synced clock. 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.