Ccxt Laravel Package

Technical Evaluation

Architecture fit. kornrunner/ccxt is a PHP port of the CCXT unified exchange API — a synchronous, REST-only client that normalizes calls like fetchTicker, fetchBalance, and createOrder across ~110 exchanges. It integrates into Laravel as a plain Composer dependency wrapped in a service provider and facade, which fits the framework's service-container model. The architectural mismatch is that it is blocking and request/response oriented, so it belongs behind queued jobs and rate limiters rather than in the HTTP request path. It is also a library, not a managed gateway — every exchange-specific quirk (auth signing, nonces, rate limits, symbol naming) lands in our application.

Integration feasibility. Mechanically easy: add the package, bind an ExchangeClient interface, store credentials in config/env, and call it from jobs. The friction is version compatibility. The last release (Feb 2021) predates Laravel 9/10/11 and PHP 8.1+, so Composer constraint resolution against a modern Laravel app is likely to require workarounds (--ignore-platform-reqs, pinned dependencies, or a forked constraint set) — a red flag in itself. Exchange sandbox/testnet validation of signing and order lifecycle is mandatory before any production use.

Technical risk — high.

• Staleness in a fast-moving domain. Exchange REST APIs drift continuously (endpoint changes, auth scheme updates, deprecations, WebSocket-first migrations). A library frozen in Feb 2021 will silently fail against many of the 110 exchanges it advertises; the exchange list is a 2021 snapshot, not a supported matrix.
• Security surface. The package handles API secrets and request signing. Unmaintained crypto-adjacent code carries real liability, particularly for trading and any withdrawal-capable keys.
• Low adoption signal. 37 stars and no releases in years means minimal community scrutiny, few eyes on correctness, and no upstream fixes.
• Abstraction is the only real asset. The CCXT-style interface is portable; the implementation is not. That argues for isolating it behind an internal interface so it is cheap to replace.

Key questions.

• Which specific exchanges and operations (read-only market data vs. order placement vs. withdrawals) must be supported on day one?
• What are the target PHP and Laravel versions, and can the dependency constraints be satisfied without --ignore-platform-reqs?
• Has each required exchange been validated against current APIs and testnets?
• Would a maintained alternative be strictly better: official ccxt/ccxt PHP bindings, or a Python/Node CCXT sidecar service behind HTTP/gRPC?
• Who owns forking/patching the library when exchange APIs change, and what is the licensing posture (MIT) for redistribution?

Integration Approach

Stack fit. Treat the package as a low-level adapter, not an application dependency. Bind an ExchangeClient interface in the container, load per-exchange credentials from a secrets manager (not .env), and centralize rate limiting. All trading and market-data calls should run as queued jobs with idempotency keys, bounded retries, and circuit breakers — never synchronous in a controller. Add structured logging around every exchange call (request correlation, exchange, symbol, latency, outcome) because observability is the only way to detect silent drift.

Migration path. Do not let the package leak into domain code. Define our own ExchangeClient/MarketData contracts first, then implement a KornrunnerCcxtAdapter. This makes the vendor decision reversible and enables a strangler migration to the official CCXT PHP bindings or a CCXT sidecar microservice without touching business logic. If the exchange set is small, a thin direct HTTP client per exchange may be lower risk than a stale abstraction.

Compatibility.

• Verify Composer constraints against PHP 8.1+ and the target Laravel version in CI before committing.
• Validate request signing, nonce handling, and clock skew against each exchange's testnet.
• Check symbol/currency normalization per exchange — the "unified" layer is exactly where stale libraries break.

Sequencing.

1. Spike (1 sprint): one exchange, read-only (fetchTicker, fetchOHLCV), isolated branch; prove install, signing, and parsing.
2. Auth validation: testnet order lifecycle and balance calls; document per-exchange defects.
3. Harden: wrap behind interfaces, queue jobs, rate limiter, retries, kill switch, audit log.
4. Canary: production with tightened limits; monitor error rates before widening.
5. Decide: adopt, fork-and-maintain, or replace with maintained CCXT binding/sidecar based on spike findings.

Operational Impact

Maintenance. Effectively abandonware. We must assume ownership: vendoring/forking, patching exchange drift, and tracking upstream CCXT changes manually. Budget an ongoing engineering line item, not a one-time integration cost (roughly 0.25–0.5 FTE depending on exchange count). Any Laravel or PHP upgrade becomes coupled to this fork.

Support. No vendor SLA, no maintainer responsiveness, and minimal community. Internal expertise is the only support channel; onboarding documentation must be written by us.

Scaling. REST-only and synchronous. Scaling means more queue workers, but throughput is bounded by per-exchange rate limits, so the design must cap concurrency per exchange/account and cache market data aggressively. No native WebSocket or async means no low-latency streaming path — a WebSocket feed would need to be added separately. Horizontal scaling requires sharding by exchange or account to avoid shared nonce and rate-limit state.

Failure modes.

• Silent drift: exchange changes endpoint or signing → order and balance calls fail or return malformed data without obvious errors. Mitigate with schema validation and alerting.
• Rate-limit bans: naive fan-out triggers 429/418 and temporary IP or key bans.
• Auth failures: nonce collision, clock skew, or stale signature logic → rejected orders.
• Partial fills and idempotency gaps: retries can duplicate orders without idempotency keys.
• Upgrade lock: Composer conflicts block framework upgrades, creating security debt.
• Credential exposure: secrets leaked through logs or config errors in a stale, unaudited client.

Ramp-up. The CCXT API surface is well known, so a competent PHP developer can reach a read-only prototype in days. Production readiness is materially harder: expect 1–2 weeks to a validated POC and multiple sprints of hardening, with the highest cost in debugging undocumented exchange-specific behavior in unmaintained code.

Verdict. Acceptable only as a time-boxed POC or for low-risk, read-only market data on a small exchange set. For production trading, the maintenance and security profile makes replacement — maintained CCXT PHP bindings or a CCXT sidecar service — the default recommendation unless the spike proves the package's exchange coverage still holds.