The short answer
Turning trading research into dependable software is mostly a risk-control and state-management problem, not a strategy problem. Cryptuon builds the parts around your strategy: venue connectors, a paper-trading environment on the live code path, one risk service every order must pass through, reconciliation, and monitoring. Each is delivered against acceptance tests you sign off.
You keep the keys, the venue accounts, the strategy, and every trading decision. We build and operate software. We do not trade.
Decision criteria
The questions that decide cost and approach:
How many venues, and of what kind?
A single centralised exchange with one order type is a contained build. Prediction markets add their own complications. Polymarket settles on-chain, so fills and position updates arrive with blockchain latency, while Kalshi behaves like a conventional exchange API. Events also resolve on schedules and under rules you do not control. Each additional venue adds a connector, fixtures, fee and size rules, and a reconciliation path.
Must paper and live share a code path?
If paper trading runs a separate simulator, it will drift from live behaviour, and you will find out with real money. The design we build puts strategy, risk, and order logic in one code path and swaps only the venue adapter. Strategies start in paper mode and are promoted to live one at a time.
Who or what can originate an order?
Human operators, scheduled strategies, and LLM agents need the same gates. If an agent can call a place_order tool, that tool must create an approval request or check a pre-authorised threshold. It must never submit directly. An approval for one strategy must not carry over to another.
Where do keys live, and who can rotate them?
In your secret manager (cloud KMS, Vault, or a hardware-backed store), under your access policy. Our services read scoped API keys with withdrawal permissions disabled wherever the venue supports it. Rotation and revocation are yours to perform, and the runbook covers them.
Implementation options
| Approach | How it works | Strength | Tradeoff | Maturity |
|---|---|---|---|---|
| Cryptuon delivery (using PolyBot or dgbit where they fit) | Connectors, shadow-first paper trading, a single NNG-connected risk service, approval gates, and reconciliation, delivered and optionally operated by us | Prediction-market and agent workflows supported natively; risk and operations built to your written criteria | Narrower venue coverage than the large community frameworks; PolyBot and dgbit have smaller user bases | PolyBot and dgbit: open source, evidence level reproduced; Moby Market: declared, not deployed |
| Hummingbot | Python framework with Cython hot paths, connectors for many CEXes and DEXes, strategy templates | Broad venue coverage and a mature market-making focus | Built around market making and arbitrage rather than signal-based strategies; limited backtesting | Established, Apache-2.0 |
| Freqtrade | Single-process Python bot over CCXT with backtesting, hyperopt, and FreqUI | Many exchanges, parameter optimisation, large strategy community | Directional crypto focus, no prediction markets; GPL-3.0 licence | Established |
| NautilusTrader | Event-driven platform with a Rust core and Python API; the same strategy code runs in backtest and live | High performance and research-to-live parity by design | Steeper learning curve; adapters vary in depth by venue | Established, LGPL-3.0 |
| CCXT-based in-house stack | Your team builds strategy, risk, state, and deployment on CCXT’s unified exchange API | Full control; CCXT covers a very wide range of exchanges | CCXT is a connectivity library, so risk, reconciliation, and operations are all yours to build and run | CCXT established; the rest depends on your team |
If you already run Freqtrade, Hummingbot, or Nautilus, we usually keep it and add what is missing (a central risk gate, reconciliation, monitoring, and runbooks) rather than replace it.
The delivery sequence
- Inventory. List the strategies, venues, order types, data sources, and where state currently lives, including notebooks.
- Risk policy. Write the limits down: per-market, per-venue, and global exposure; daily loss stops; maximum order size; approval thresholds; who can override them.
- Connectors and fixtures. Build or adopt venue adapters and record real responses (fills, rejects, disconnects) for replay tests.
- Paper path. Run every strategy in shadow mode on live data through the same order path, and compare decisions against your research.
- Drills. Rehearse the kill switch, reconciliation halts, and a venue outage on testnet or in paper mode, with timings recorded.
- Promote and operate. Move strategies to live one at a time on your approval, with monitoring, alerting, and an incident runbook.
PolyBot’s risk service shows the shape of the policy layer. Limits are configured centrally, and agent-initiated orders need approval:
pip install polybot-trader
polybot strategy enable arbitrage
polybot strategy shadow arbitrage --enable # paper-trade; no funds touched
polybot risk set --per-market-usd 300 --global-net-usd 8000
polybot risk show --strategy momentum # per-strategy overrides
polybot mcp approve --threshold 100 --strategy ai_model --markets "politics"
polybot mcp audit approvals --pendingThe acceptance tests are written against the risk gate, whichever framework sits underneath. An illustrative pytest suite (fixture names stand in for your adapters):
# Acceptance tests for the risk gate and kill switch. Illustrative: the
# fixtures wrap the client's risk service and a paper-mode venue adapter.
import time
import pytest
def test_order_over_per_market_cap_is_rejected(risk, paper_venue):
order = {"market": "FED-DEC", "side": "buy", "usd": 301}
decision = risk.check(order)
assert decision.allowed is False
assert decision.reason == "per_market_cap"
assert paper_venue.submitted_orders() == []
def test_kill_switch_cancels_everything_within_budget(risk, paper_venue):
paper_venue.seed_working_orders(count=25)
started = time.monotonic()
risk.kill(reason="drill")
assert paper_venue.working_orders() == []
assert time.monotonic() - started < 5.0 # agreed budget
with pytest.raises(risk.TradingHalted):
risk.submit({"market": "FED-DEC", "side": "buy", "usd": 10})
def test_position_drift_halts_trading(risk, paper_venue):
paper_venue.force_position("FED-DEC", usd=900) # venue disagrees with local
risk.reconcile()
assert risk.halted is TrueEvidence
- PolyBot’s three-layer risk design (pre-submission checks, in-flight monitoring, post-fill reconciliation with auto-halt) is documented in its risk controls guide, and the shadow-first lifecycle in its shadow mode guide. Installation and the CLI are in the PolyBot documentation.
- PolyBot’s features list the venue connectors, the 25+ MCP tools, and the three execution modes (disabled, shadow, live with approval).
- dgbit’s quickstart goes from
pip install dgbitto a backtest and then to Bybit testnet. Its comparisons with Freqtrade and Hummingbot say where those tools are the better choice. Reference material is in the dgbit documentation. - Moby Market’s feature set and the Moby Market documentation describe its execution primitives. It is not deployed for institutional flow.
- Not yet evidenced: none of these frameworks has a published record of customer-accepted production operation, and none has a third-party audit. Strategy performance is not evidenced at all, by design. Current levels are in the maturity register.
What drives the cost
- Number of venues and order types. Each connector needs fixtures, fee and size rules, and its own reconciliation.
- Agent involvement. LLM-originated orders add approval workflows, budget limits on tool calls, and audit logging.
- State reconciliation. On-chain settlement (Polymarket, Solana venues) is slower and messier to reconcile than exchange REST APIs.
- Existing code. Wrapping a working Freqtrade or Nautilus deployment costs less than restructuring a set of notebooks.
- Operating hours. Round-the-clock alerting and incident response cost more than a business-hours monitoring envelope.
Limitations and what we won’t do
- We do not take custody, hold venue accounts, trade on your behalf, choose strategies, or promise returns. Backtests and paper results are not forecasts.
- Venue access depends on each venue’s terms and your jurisdiction. Real-money prediction markets in particular need your own legal review.
- PolyBot covers prediction markets plus Binance; dgbit is Bybit-only by design. Other venues mean building or adopting a connector.
- Moby Market is a declared design, not a deployed system. We will not route real flow through it without an independent audit and integration testing.
- Risk controls limit losses from software and operator error. They do not limit losses from a strategy that is simply wrong within its limits.
For related work, see forecasting and agent competitions, agent payments and payouts, and our write-up on verifiable on-chain AI inference and resolution. Engagement terms are on /services.
Next step
Send us a description of your strategies, the venues and order types you use, where your research code lives, and how keys are held today. Never send the keys themselves. The assessment returns a risk-policy draft, a connector and paper-trading plan, and a costed build, or you can start here.