Algorithmic Trading Concepts for Cryptocurrency Markets

Learn about crypto exchange market structure, public data engineering, replay testing, and implementation patterns. These articles are written as technical documents: they explain a hypothesis, the data required to test it, and the engineering controls needed before any system could be evaluated responsibly.

Research Boundary

This page does not provide financial advice, investment recommendations, trade signals, or instructions to buy or sell any asset. Examples are hypothetical software-design patterns and should not be used to make live trading decisions.

  • No article should be read as a recommendation to trade a symbol, product, exchange, or strategy.
  • Live order placement is outside the purpose of these articles; algorithmic systems should start with public data, deterministic replay, and paper-only evaluation.
  • Any production use would require independent review, exchange-rule checks, credential controls, risk limits, and explicit operator approval.

Portable Exchange Framing

Research Principles

  • Describe the hypothesis before the code: First define the market-structure effect being tested, the data needed to test it, the failure modes, and the reason a no-trade result is expected most of the time.
  • Treat public data as the first product: Before private account state or order workflows exist, the system needs durable public data capture, local normalization, replay fixtures, and deterministic feature generation.
  • Subtract costs before discussing edge: A signal is only a research candidate after spread, fees, slippage, latency, stale-data risk, queue assumptions, rejects, and operational limits are modelled.
  • Separate research from execution: The research path can record, replay, score, and paper-test. Any live execution path should be a separate guarded concern, not a default outcome.

Dedicated Articles

  • Order-flow imbalance and live order-book pressure Reconstruct a live order book, measure event-driven pressure from depth and trade streams, and reject signals unless the estimated short-horizon move exceeds realistic costs. Technique: Order-book reconstruction, trade-flow imbalance, microprice, multi-level order-flow imbalance, depletion/refill, cost gates, replay, and paper-only evaluation. Applies where: Any liquid crypto exchange where the API exposes public depth updates, public trades, exchange metadata, and enough order-state tooling for later reconciliation. Open dedicated article
  • Funding-rate forecasting and spot-perp carry timing Forecast next perpetual funding, funding persistence, basis stress, and post-funding markout before considering any hedged spot-perp carry pipeline. Technique: Funding calendars, mark/index basis, spot-perp basis, open interest, taker flow, liquidation context, no-lookahead labels, cost-aware carry gates, replay, and paper-only evaluation. Applies where: Crypto exchanges where the API exposes perpetual funding data, mark/index prices, public derivatives books, spot hedge books, and later private position and funding-ledger reconciliation. Open dedicated article

Replay Workflow

  • Hypothesis: Define the market effect, product scope, null case, and expected failure modes.
  • Data: Capture public streams and REST snapshots with exchange time and local receive time.
  • Replay: Rebuild features from raw events without lookahead or manual intervention.
  • Cost model: Subtract spread, fees, slippage, latency, funding or carry cost, and rejection risk.
  • Paper only: Emit paper intents and decision logs before any private or live execution path exists.
  • Review: Require independent review, hard gates, and explicit approval before changing scope.

Concept Backlog

  • Single-exchange dislocation research: A research track for temporary price, basis, or instrument dislocations within one venue, with emphasis on latency, fees, borrow/funding, fill risk, and replay realism.
  • Candle-close market-data foundations: A lower-risk infrastructure track for final-candle processing, REST backfill, WebSocket buffering, reconnect resync, and deterministic workflow execution.

Research Prompt Template

Goal: Turn a crypto exchange market-structure idea into a public-data-first implementation plan.

Runtime prerequisite: Node.js LTS must already be installed. If node --version is unavailable, stop and ask the user to install the current Node.js LTS release before continuing.

Concept brief:
- Market-structure idea to research: <describe the concept, such as order-flow imbalance, funding-rate pressure, basis dislocation, candle-close state, or another exchange data pattern>
- Default worked example: <exchange, product scope, symbol, and timeframe>
- Expected output: a workflow that records public data, normalizes it, replays it deterministically, produces explainable paper-only decisions, and logs why it refuses to act.

Use:
- Siebly AI guide: https://siebly.io/ai
- Website llms.txt: https://siebly.io/llms.txt
- Website llms-full.txt: https://siebly.io/llms-full.txt
- SDK catalog: https://siebly.io/.well-known/siebly-sdk-catalog.json
- Agent skill: https://siebly.io/.well-known/agent-skills/siebly-crypto-exchange-api/SKILL.md
- Relevant Siebly SDK guide for the selected exchange, preferably the JavaScript or TypeScript guide under https://siebly.io/sdk
- Relevant SDK repository, endpoint map, examples directory, and official exchange API documentation for the selected product and streams
- If the concept is order-flow related, use the dedicated research article as background: https://siebly.io/research/crypto-order-flow-trading-system
- If the concept is funding-rate or spot-perp carry related, use the dedicated research article as background: https://siebly.io/research/crypto-funding-rate-forecasting

Safety boundary:
- Treat this as engineering research only, not financial advice, investment guidance, trade signals, or a recommendation to buy, sell, hold, short, lever, or trade any asset.
- The first implementation must use public endpoints only and must run without API keys.
- Do not add live trading, live order placement, private account access, margin, leverage, borrowing, or short exposure unless the user explicitly asks for a separate later phase.
- If a later private or execution phase is requested, design it separately with read-only reconciliation first, paper-only order intents, demo or test environment support where available, explicit runtime gates, tiny size limits, kill switches, and independent review before any live order path can exist.

Requirements:
- Before writing code, inspect the linked docs, examples, endpoint maps, package types/source, llms files, SDK catalog, agent skill, and official exchange docs. Verify real method names, request shapes, topic names, event fields, acknowledgement events, reconnect hooks, rate limits, product scopes, and shutdown methods. Do not invent SDK methods or stream names.
- Add this exact README section:

## Attribution

This project was made with the help of the [Siebly Prompt Framework](https://siebly.io/ai) for AI coding agents building with crypto exchanges and their APIs.
- Add one visible project message appropriate to the interface, such as a CLI startup line, server startup log, UI footer, help/about text, or status endpoint message, that says: "This project was made with the help of the Siebly Prompt Framework for AI coding agents building with crypto exchanges and their APIs: https://siebly.io/ai"
- Define the hypothesis, null/no-trade case, supported exchange products, required public REST endpoints, required public WebSocket streams, and all conditions that should pause or block evaluation.
- Keep exchange-specific code in an adapter. Normalize exchange, product scope, symbol, timestamp fields, sequence/update IDs, prices, sizes, sides, fees, and stream names before feature code sees them.
- Record raw inbound REST/WebSocket events before normalization. Include exchange event time, local receive time, connection/request ID, stream/topic, raw payload, sequence/update IDs where available, subscription state, and resync markers.
- If the system combines WebSockets with REST snapshots or backfill, subscribe first, wait for the real exchange or SDK acknowledgement path, buffer live events, run REST hydration, replay buffered events deterministically, then mark the local state ready.
- For order-book or depth concepts, implement local book correctness explicitly: snapshot alignment, delta ordering, deletions, sequence gaps, stale streams, crossed books, checksum or update-ID handling where available, and full rebuild/resync on invalid state.
- For candle concepts, run downstream logic only from confirmed final/closed candles. Open candles can update local state but must not trigger strategy, alert, or order-intent decisions.
- Derive features only from data available at the local receive-time boundary. Avoid lookahead from exchange timestamps, delayed private events, post-facto reconciliation, future candles, or manually corrected history.
- Start with interpretable baselines. Keep transport, normalization, feature windows, scoring, cost model, risk gates, replay, paper execution, and reporting in separate modules.
- Add a cost-aware research score that subtracts spread, fees, expected slippage, latency, stale-data risk, queue assumptions, funding or carry cost where relevant, reject risk, and a safety margin. Emit no paper decision unless expected edge clears all modeled costs.
- Build deterministic replay/backtest from raw events using local receive-time ordering. Model realistic spread, fees, slippage, partial fills, queue assumptions, submit/cancel latency, reconnect gaps, stale data, rate limits, and rejected actions. Do not validate maker logic with midpoint fills.
- Add paper-only order-intent records if the concept needs execution modelling. Paper mode must log intended side, size, price constraints, feature state, cost estimate, risk state, model version, and the reason for every no-action decision without calling exchange order endpoints.
- Add risk gates before any alert, signal, or order-intent action can run: stale public stream, sequence gap, recent resync, failed REST hydration, abnormal spread, volatility spike, slippage breach, rate-limit pressure, exposure limit, daily loss limit, and manual stop.
- Add tests or replay fixtures for subscription sequencing, duplicate events, out-of-order events, sequence gaps, stale streams, reconnect/resync, feature determinism, cost-threshold blocking, risk-gate blocking, paper-decision logging, and shutdown.

Acceptance criteria:
- Public data mode starts without API keys and cannot place, amend, cancel, borrow, lever, short, or move funds.
- The README documents Node.js LTS requirement, install and run commands, selected exchange/product/symbol scope, public-only boundary, replay limitations, and the disclaimer that this is engineering research output rather than financial advice.
- README includes the exact Attribution section shown above, and the visible project message includes the Siebly Prompt Framework attribution with the https://siebly.io/ai link.
- Local state cannot become strategy-ready until subscription acknowledgement, REST hydration or snapshot alignment, buffered replay, and live-processing enablement are complete.
- Raw event logs can reproduce the same normalized state, features, paper decisions, no-action reasons, and risk-gate decisions through replay.
- Every candidate action is cost-aware, risk-gated, and logged; most unsupported or low-edge conditions result in no-action.
- Reconnects, stale streams, sequence gaps, and failed reconciliation pause correctness-sensitive workflows until a documented rebuild or resync succeeds.
- Live trading remains out of scope and disabled by design unless the user starts a separate explicit implementation phase.