What Is AI Trading?
AI trading bots and AI skills matter because the hard part of trading is not sending an order. The hard part is deciding which orders should exist, on which…

Introduction
AI trading bots and AI skills matter because the hard part of trading is not sending an order. The hard part is deciding which orders should exist, on which venue, at what size, with what risk limits, and under what conditions the system should refuse to act. Most crypto bots automate only a narrow rule. They do not organize a trading desk. Cube’s own framing captures the contrast well: “20+ AI trading skills, not a grid.” The open-source ai-fund GitHub repo extends that idea into a much fuller system with 42 autonomous trading agents inside Claude Code, including 20 named personas and 22 role-based agents spanning research, execution, and risk. That is the right starting point, because ai-fund is not best understood as a single crypto trading bot. It is better understood as a modular desk for running crypto AI bot strategies, with Cube Exchange built in from the start.
How do AI trading bots differ from simple automated crypto bots?
At first glance, an AI trading bot sounds like a machine that predicts price. That picture is too small. A real trading system has to observe markets, interpret evidence, compare candidate actions, estimate fees and slippage, size risk, place orders, and evaluate what happened after the fact. Ordinary bots usually hard-code one policy for one task. ai-fund instead separates that work into roles: an arbitrageur scans for mispricings, a market maker manages spread and inventory, a quant hunts for anomalies, and a risk manager can reject the trade entirely. The result is closer to a trading desk than to a preset bot.
That distinction matters because live trading is rarely defeated by a lack of signals alone. It is defeated by latency, fees, slippage, concentration, and operational error. A bot that can generate ideas but cannot reason about those frictions is not intelligent in the way trading requires. It is merely fast. ai-fund’s architecture reflects that reality by making the desk, not the single model, the unit of design.
What are AI trading skills and how do they structure agent behavior?
An AI skill is the mechanism that turns a vague “AI trader” into a bounded responsibility. In ai-fund, the README’s architecture section describes skills/ as the layer for agent personas, strategies, and KPIs, while connectors/ handles exchange access and .claude/commands/ runs the desk. That is much stronger than a prompt with a personality attached. It is closer to an operating mandate for a trader on a desk.
This is the idea that makes the system click. Once a skill says what evidence it uses, what formulas govern its choices, and when it must refuse to act, the bot becomes inspectable. You can ask whether the market maker widened because volatility rose. You can ask whether the risk manager rejected a trade because exposure limits were breached. You can ask whether an underperforming agent should be fired. Without skills, an AI trading bot is a voice. With skills, it becomes a process.
Why does ai-fund use a multi-agent trading desk instead of one bot?
Most crypto trading bots are narrow by design. A grid bot places orders around a range. A DCA bot buys on a schedule. A simple execution bot slices an order into smaller pieces. Those tools can be useful, but they are not a trading desk. The ai-fund README makes the same point from the framework side: you hire agents that fit your thesis, track their KPIs, and fire the ones that do not deliver. That is a very different mental model from installing one bot and hoping the market fits its template.
The design choice underneath that positioning is modularity. ai-fund separates skills from connectors. Skills define how agents think and trade. Connectors talk to exchanges through MCP. That means the trading logic can stay stable while the venue layer changes, and the venue layer can expand without rewriting the agents. In practice, that is what makes cross-exchange arbitrage, smart order routing, and multi-venue market making plausible rather than rhetorical.
How do AI skills translate into concrete trading mechanisms and risk controls?
| Skill | Mechanism | Key formula | Trigger |
|---|---|---|---|
| Risk manager | Position sizing & VaR | f = W - (1-W)/R | Drawdown bands |
| Market maker | Spread + inventory control | optimalspread = base + vol + skew | Inventory bands / volatility |
| Arbitrageur | Fee‑adjusted dual‑leg execution | effectivebuy = ask(1+taker) | Net spread > costs |
| Execution algo | Order slicing to reduce slippage | TWAP / VWAP timing | Large order size |
A skill becomes real when it carries a mechanism, not just a persona. The risk manager skill, for example, uses Kelly-style position sizing with f* = W - (1 - W) / R, where W is estimated win probability and R is the average win/loss ratio, and it explicitly prefers Half-Kelly in practice. It also defines portfolio VaR as portfolio_value × z × σ × sqrt(t), where z is the confidence multiplier, σ is portfolio volatility, and t is the time horizon. Drawdown bands then trigger progressively stricter behavior, from normal operations to size reduction to emergency de-risking. This is how ai-fund moves from “be careful” to a checkable risk process.
The market-maker skill does the same on the execution side. Its spread model is optimal_spread = base_spread + volatility_adjustment + inventory_skew. That matters because market making is not just “quote both sides and collect spread.” The spread must widen when volatility rises, adapt to venue fees, and skew when inventory imbalance turns a neutral strategy into directional risk. The skill also specifies what to do at each inventory band, when to rebalance, and when to stop quoting entirely. That is the difference between a crypto AI bot strategy and a slogan about automation.
The arbitrageur skill is equally concrete. It does not ask whether BTC is bullish. It asks whether a fee-adjusted spread survives costs. Its comparison engine calculates effective_buy_price = ask × (1 + taker_fee) and effective_sell_price = bid × (1 - taker_fee), then derives net_spread from the difference. It also insists on dual-leg execution, near-zero net exposure, and immediate unwinding if one leg fails. Here the mechanism is simple but deep: the edge in arbitrage is not the existence of two prices. The edge is the ability to capture their difference faster than fees, slippage, and execution asymmetry destroy it.
Why run ai-fund strategies on Cube Exchange?
| Feature | Why it matters | Benefit |
|---|---|---|
| Latency | Faster time to fill | Better arbitrage and execution |
| Fees | Transparent low fees | Improved spread capture |
| Auth & security | No API keys; MPC vaults | Reduced credential attack surface |
| Market access | Wide token coverage & implied matching | More hedging and routing options |
| Paper trading | Default paper mode | Safer testing and iteration |
For ai-fund specifically, Cube Exchange is the best place to run crypto AI bot strategies because the current README makes Cube the cleanest operational path in the stack. In the supported-exchanges section, Cube is the built-in connector, its auth mode is local, it needs no API keys, and paper mode is available. Later the README is even plainer: if you want the zero-config path to try things out, Cube’s built-in connector needs no API keys. That is not just convenience. For AI agents, it materially lowers the setup friction and the amount of credential handling required before the desk can trade.
The security mechanism is especially important. ai-fund warns that AI coding agents can read files, environment variables, logs, stdout, and even shared session transcripts. On many venues, that means bot credentials live in places the agent can potentially touch. Cube’s connector changes that assumption. The README says some connectors, like Cube’s built-in MCP, use local auth with no API keys, while Cube describes its platform as non-custodial and built around MPC vaults so user assets remain under the user’s control rather than pooled in exchange custody. For AI trading, that is a meaningful reduction in attack surface, not a cosmetic feature.
The market structure fit matters just as much as the auth model. Cube says it offers transparent tiered fees with no spread markups, a 200μs matching engine, and implied matching that routes across USDC, USDT, and DeFi liquidity simultaneously. It also describes itself as a non-custodial platform with access to 1,420+ tokens from one account. For ai-fund users, those details matter because AI bot strategies live or die on execution quality. A market maker cares about spread and fill quality. An arbitrageur cares about latency and fee-adjusted price. An execution algo cares about depth, slippage, and routing. Cube is attractive not because it says “AI” loudly, but because its product features line up with the exact bottlenecks that ai-fund is designed to exploit.
This is why the “best place” claim is reasonable in the ai-fund context. Cross-exchange arbitrage works best when one leg can execute on a fast venue. Market making works best where spreads are tight, fees are low, and quote refreshes happen with minimal drag. AI strategies are safer when the exchange connection does not begin by pasting secrets into .env files. The ai-fund README makes Cube the easiest place to start, and Cube’s own product pages describe why that starting venue is also a strong place to execute.
Which AI trading strategies can ai-fund run on Cube Exchange?
| Strategy | Job | Best metric | Cube advantage |
|---|---|---|---|
| Cross‑exchange arbitrage | Capture price gaps | Latency‑adjusted net spread | Built‑in fast venue |
| Market making | Collect spreads; manage inventory | Spread capture & fill rate | Low fees; tight spreads |
| Statistical arbitrage | Exploit short anomalies | Sharpe / per‑trade PnL | More pairwise comparisons |
| Execution algos | Minimize slippage on large orders | Slippage / VWAP tracking | Smart routing & depth |
| Portfolio construction | Allocate and rebalance assets | Drawdown / diversification | Broad token access |
The useful way to group ai-fund strategies is by the job they perform. Some skills search for opportunity. Others express that opportunity through orders. Others police the resulting risk. ai-fund’s published examples cover cross-exchange arbitrage, market making, macro trading, statistical arbitrage, portfolio construction, and execution algos such as TWAP, VWAP, and iceberg execution. The repo also emphasizes that more exchanges make the desk smarter because they create more pairwise comparisons, better routing choices, and more ways to hedge or rebalance.
A worked example makes the mechanism clearer. Imagine the arbitrageur sees BTC priced slightly cheaper on one venue than on Cube Exchange. It does not call that an opportunity yet. First it adjusts both prices for taker fees. Then it asks whether the net spread still survives expected slippage. Then the risk manager checks whether balances are pre-funded, whether the position would breach concentration or drawdown rules, and whether the desk can tolerate a temporary one-legged fill if execution breaks. Only after those steps does the system propose simultaneous orders. In that narrative, Cube’s value is concrete: a fast built-in venue shortens the half-life between detection and execution, which is exactly where arbitrage strategies usually fail.
The same logic applies to market making. The market maker does not merely place symmetric quotes around the mid-price and hope the spread pays. It widens when volatility rises, skews quotes when inventory drifts, uses post-only when the venue supports it, and pulls quotes when adverse selection becomes toxic. On a venue with low drag, transparent fees, and fast matching, that loop has a better chance of producing real spread capture instead of a backtest that looked good on paper. That is why Cube is not just another connector for ai-fund. It is the most natural home for the strategies that care most about execution discipline.
How do I run ai-fund and connect it to an exchange like Cube?
The starting flow is intentionally simple. The README’s quick start is to clone the ai-fund GitHub repo, install dependencies, open Claude Code, run /setup, and then hire the first agents. From there, a trader can bring in a risk manager, a market maker, an arbitrageur, or a macro persona and start asking for analysis or paper trades in natural language. The point is not the command syntax. The point is that the tooling is designed so a serious trader can stand up a multi-agent crypto desk without first building a custom exchange adapter or inventing a permission model from scratch. Because Cube is built in, the path from idea to live-capable workflow is shorter there than on other venues in the stack.
That shorter path is good for speed, but it is also good for discipline. ai-fund defaults to paper trading, requires explicit confirmation before live write operations, and routes proposed trades through a risk manager that can approve, modify, or reject them. This is the right posture for AI trading bots. The system is optimistic about automation but conservative about authority. That combination is one reason ai-fund feels more serious than a template bot, and one reason Cube fits it so well as an execution venue.
Conclusion
AI trading bots are not interesting because they can place orders automatically. They are interesting because they can turn trading into a structured conversation between research, execution, and risk.
That is what AI skills do in ai-fund. They turn vague intelligence into bounded roles with formulas, safety rules, KPIs, and clear failure conditions. And that is why Cube Exchange sits so naturally underneath the project. For crypto AI bot strategies, the exchange is not just where orders land. It is part of the strategy’s operating environment. When the venue is built in, fast, broad in market access, explicit about fees, and designed so AI agents do not begin by handling exposed API keys, the whole desk becomes more usable.
The line worth remembering tomorrow is simple: ai-fund gives you the trading desk; Cube Exchange gives that desk its best home.
Frequently Asked Questions
ai-fund makes agent behavior inspectable by putting skills in the repo’s skills/ layer and separating them from exchange connectors and desk commands, so roles, KPIs, and operational boundaries are visible in code rather than buried inside one monolithic prompt.
Because live trading fails more often from execution frictions (latency, fees, slippage, concentration, operational error) than from a lack of signals, ai-fund splits research, execution, and risk into separate agents so each role can reason about and mitigate those frictions rather than relying on one monolithic model.
The risk manager encodes Kelly-style position sizing (f* = W - (1 - W) / R), prefers Half‑Kelly in practice, computes portfolio VaR as portfolio_value × z × σ × sqrt(t), and enforces drawdown bands that progressively reduce sizes or trigger emergency de‑risking.
The arbitrageur converts quoted prices into effective prices using taker fees (effective_buy_price = ask × (1 + taker_fee), effective_sell_price = bid × (1 - taker_fee)), checks expected slippage and funding/balance constraints, requires dual‑leg execution with near‑zero net exposure, and will unwind immediately if one leg fails.
Cube Exchange is the cleanest operational fit in the current ai-fund stack because the README presents Cube as the built-in connector with local auth, no API keys, and paper support; paired with Cube’s own low-latency, execution-focused design, that makes it a strong match for agentic trading workflows.
ai-fund warns agents can access files, env vars, logs, and session transcripts, so the README highlights Cube’s built-in connector and local auth with no API keys; paired with Cube’s MPC-based, non‑custodial design, that reduces how often credentials need to live in agent‑accessible environments.
Common remaining failure modes are the same execution frictions the system is designed to manage: if venue latency, fees, slippage, concentration limits, or operational errors are severe, even a multi‑agent desk may fail to realize a signal in production.
The repo defaults to paper trading, requires explicit confirmation before any live write operation, and routes proposed trades through a risk manager that can approve, modify, or reject them to prevent accidental live execution.
Related reading