ccxt - Moses Yebei

The Problem

Developers building crypto‑trading bots need a single, language‑agnostic client that hides the quirks of each exchange’s REST/WebSocket API. Maintaining separate wrappers for 100+ venues quickly becomes a maintenance nightmare and introduces subtle bugs when normalising data across markets.

What This Does

ccxt ships a generated SDK for every supported exchange in JavaScript/TypeScript, Python, C#, PHP, Go, and Java. The core source lives under language‑specific folders (js/, python/, cs/, php/, go/, java/). Each folder contains an Exchange class per venue that implements a uniform set of methods (fetchTicker, createOrder, cancelOrder, …).

The CLI (cli/ts/cli.ts) offers a thin wrapper that can invoke any method from the command line, useful for quick debugging or scripting. Example scripts are in examples/ (e.g., examples/python/asyncio/asyncio.py) and the documentation lives in wiki/ and the README.md.

How It Is Wired

Execution starts at the language‑specific entry point:

JavaScript/TypeScript – cli/ts/cli.ts parses CLI args, loads the target exchange module from js/src/ (or ts/src/ after compilation) and calls the requested method on the exchange instance.
Python – the generated package python/ccxt is imported; its __init__.py registers all exchanges in python/ccxt/exchanges. A call such as ccxt.binance().fetchTicker('BTC/USDT') follows the path Exchange.fetchTicker → _request → self.handle_errors → self.rateLimit.

All language ports share a static dependency tree under */src/static_dependencies/, e.g. js/src/static_dependencies/ethers/ and js/src/static_dependencies/node-fetch/. The most connected module is js/src/base/types (imported by 10 other modules) and the StarkNet type definitions (js/src/static_dependencies/starknet/types/index) which sit at the hub of 9 importers. No circular dependencies were detected, keeping the import graph shallow.

The library does not touch a database; its side‑effects are limited to HTTP calls to exchange endpoints and optional file writes performed by example scripts. The core SDK functions are pure aside from network I/O, which confines the blast radius to the HTTP client modules (node-fetch, requests in Python, etc.).

How To Use It

# Clone the fork exactly as requested
git clone https://github.com/moses-y/ccxt.git
cd ccxt

# Install the TypeScript CLI (npm is present)
npm ci          # uses cli/package-lock.json
npm run build   # compiles ts/ → dist/cjs

# Run a quick ticker fetch via the CLI
node dist/cjs/cli.js binance ticker BTC/USDT

For Python development:

python -m venv .venv
source .venv/bin/activate
pip install -r python/requirements.txt   # (if present) or `pip install .` to install the local package
python -c "import ccxt; print(ccxt.binance().fetchTicker('BTC/USDT'))"

The examples/ directory contains ready‑to‑run scripts for each language; run them with the appropriate interpreter (node, python, dotnet run, etc.). Configuration (API keys, secrets) is expected in environment variables as documented in each example’s header.

Real‑World Use

A trading firm can embed the Python SDK in its back‑testing pipeline:

import ccxt, pandas as pd

exchange = ccxt.binance({'apiKey': os.getenv('BINANCE_KEY'),
                         'secret': os.getenv('BINANCE_SECRET')})
df = pd.DataFrame(exchange.fetchOHLCV('ETH/USDT', '1h'))
# feed df into strategy engine …

The same code works unchanged in a Node service by swapping the import path to require('ccxt').

Code Health & Issues

Critical – Secrets in workflow .github/workflows/post-release.yml (GH_TOKEN).
High – GitHub Actions not pinned to commit SHA in .github/workflows/*.
Medium – No least‑privilege permissions declared for GITHUB_TOKEN (post‑release workflow).
Medium – Dependabot not configured for 14 manifest files.
Medium – Dockerfile uses mutable ubuntu:22.04 base image.
Medium – No dependency‑vulnerability scan in CI.
Medium – Large binaries (dist/ccxt.browser.min.min.js.map, 27 MB) should be moved to LFS.
Medium – Checkout step keeps credentials (persist-credentials: false missing).
Medium – package.json contains a postinstall script that runs uninspected code.
Low – Workflow jobs lack explicit timeout-minutes.

Measured static analysis also flagged:

High cognitive load – Deep nesting (8‑level) in examples/cs/examples/create-order-ws-example.cs and cs/ccxt/static/Portable.BouncyCastle/.../BasicGcmExponentiator.cs.
High duplicated code – Identical 6‑line blocks across 122 files (e.g., StarkSharp contract helpers).
Medium resilience – Broad except: clause in playground/lib/runners/pyproxy/sitecustomize.py.

The Bottom Line

ccxt delivers a mature, multi‑language SDK that eliminates the need to hand‑code exchange adapters, making it valuable for anyone building crypto‑trading tools. The codebase is large and contains duplicated patterns and some security hygiene gaps (exposed secrets, unpinned actions). Teams should address the high‑severity CI issues and consider refactoring the deep‑nesting/duplicate sections before extending the library. For projects that need rapid market access across many exchanges, ccxt is a solid foundation; for security‑sensitive environments, a short remediation sprint is advisable.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

9,868 files

C#1449
TypeScript1432
JavaScript1383
Python1232
Markdown1158
PHP1020

ReactNext.jsExpressLaravelTailwindDockerTransformers

Module dependencies

The 10 most depended-upon modules of 819, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_js_src_base_types["types"] n1_dencies_starknet_types_index["index"] n2_dencies_starknet_types_index["index"] n3_ls_calldata_parser_interface["interface"] n4_rknet_types_lib_contract_abi["abi"] n5_ls_calldata_parser_interface["interface"] n6_ies_starknet_types_cairoEnum["cairoEnum"] n7_et_types_lib_contract_legacy["legacy"] n8_et_types_lib_contract_sierra["sierra"] n9_es_starknet_utils_hash_index["index"] n5_ls_calldata_parser_interface --> n2_dencies_starknet_types_index n1_dencies_starknet_types_index --> n6_ies_starknet_types_cairoEnum

Findings

LowSecret-shaped paths present; the code-health audit confirms or clears them examples/js/credentials.json

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical1

high1

medium7

low1

Keep secrets out of workflows a fork can triggercritical

.github/workflows/post-release.yml

GH_TOKEN (publish or cloud scope)

Contributor-controlled input reaches a job holding a publish token or cloud credential, so a pull request becomes credential exfiltration.

Fix: Move secret-using steps into a workflow_run job that never checks out pull request code, or gate on an environment with required reviewers.

Pin third-party GitHub Actions to a commit SHAhigh6 occurrences

.github/workflows

docker/login-action@v4, docker/build-push-action@v7, rhysd/changelog-from-release/action@v3, shivammathur/setup-php@v2

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Declare least-privilege permissions for GITHUB_TOKENmedium

.github/workflows/post-release.yml

1 workflow(s) declare no permissions, 1 of them reference secrets

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

14 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium

Dockerfile

ubuntu:22.04

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Move large binaries to Git LFS or out of the repositorymedium10 occurrences

dist/ccxt.browser.min.min.js.map

10 blobs over 5MB: ccxt.browser.min.min.js.map 27.8MB, ccxt.browser.min.js.map 27.8MB, ccxt.browser.js 19.7MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Set persist-credentials: false on checkoutmedium

.github/workflows/release-js-only.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Review the install lifecycle script and disable scripts in CImedium

package.json

postinstall

Install scripts are the execution vector for every npm compromise from event-stream onward, and a postinstall that fetches a binary makes the build depend on a URL nobody reviews.

Fix: Move the work into an explicit build step, or set ignore-scripts in CI and run it by name.

Set timeout-minutes on the workflow jobslow4 occurrences

.github/workflows/deploy-playground.yml

4 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.