Open source · Apache-2.0 · by CodeGate Software
Shariah compliance you can audit, not just trust
keel is an open-source engine for spot crypto trading. Before any order is placed, it passes through safety rails no code can override and an asset screen that refuses what is not attested. Everything it enforces is written down — ruling by ruling, with sources — so you can check it yourself.
The honest result, stated first
No shipped rule family is net positive at the taker fee actually paid on Coinbase — about 1.2% on each side of a trade. Every signal rule keel ships has now been measured at its shipped defaults across 24 assets, re-run on v0.16.0 and priced at what each asset's own book plausibly costs: 0 of 240 configurations cleared. Not one, at the fee this account actually pays.
Fees are not the whole cost, and we had been understating the rest. keel prices each asset's spread from its own liquidity — and when we finally measured that against the universe, not one of the 24 assets trades at the 5 basis points our earlier numbers assumed. The range is 1.1 to 36.8 times that floor, with a median near ten times it. Charged honestly, the median result across the matrix drops by 0.09 and the one configuration that had looked positive disappears. The error in our own cost model was larger than the best genuine improvement any rule change of ours has produced.
That correction reaches a claim this page used to make, so we are withdrawing it here rather than quietly editing it. We said the rules sit at break-even inside the venue's fee-free monthly allowance — a 14.9% win rate against a 14.88% break-even. That 14.88% was computed at the 5 basis points nothing actually trades at. Re-derived at the spread the assets are actually assumed to pay — a median ten times that floor — break-even inside the allowance is 20.5%, against the same 14.9% win rate. Roughly five and a half points underwater, inside the window we used to call break-even. The allowance is still the single largest term in the result, worth around 14 points of break-even — more than any change we have made to a rule. It is the boundary between decisively negative and clearly negative, not between negative and profitable.
The point of this project is the enforcement machinery and the honest measurement of what runs through it, not a claim of profit. Every result is compared against a simple buy-every-period (DCA) benchmark, and the reference rules currently do not beat it after fees. We would rather you know that on the front page than discover it yourself. And we are working hard to improve the results of the algorithms and the strategies. We will report our progress here.
Read the experiment record How execution is priced Read the announcement
-
Screening that fails closed
Market facts are computed; Shariah classifications are attested by a human — with a source and a name — never inferred from price data. An asset without an attestation is rejected, not passed by default.
Verify in the repository: compliance/screen.py
-
Twenty-one rails no order can skip
Spend caps, drawdown breakers, exposure limits, no-martingale, feed-staleness checks, and a kill-switch that fails closed: when something breaks, it refuses rather than allows. Then the fiqh-derived rails — the venue subscription attestation, the constructive-possession (qabd) check, which holds that an asset you cannot withdraw may never have been validly possessed, and a refusal to sell a base the venue reports the account does not hold, because selling what you do not own is bay' ma la yamlik.
Verify in the repository: execution/guards.py
-
Gates that refuse to flatter
A rule walks candidate → paper → live. Promotion clears performance floors and an overfitting check: the probability of backtest overfitting, computed by combinatorially symmetric cross-validation (PBO/CSCV). A rule that looks brilliant on a single in-sample parameter set is exactly what that second gate exists to distrust.
Verify in the repository: agent.py — RULE_REGISTRY
-
An evidence stack that can say no
Every backtest trial is appended to a hash-chained trials ledger — keel trials verify walks the chain and reports any break. Around it, research modules that answer the honest questions: rule-family significance tested against break-even priced at the fee actually paid, probability of backtest overfitting (PBO/CSCV), Deflated Sharpe and Minimum Backtest Length, Monte Carlo and candle-bootstrap resampling, rolling-origin walk-forward. All report-only, under one rule — the Strathern rail: a score may report, and may gate, but may never be a ranking key.
Verify in the repository: keel/research/
-
A read-only MCP server for your assistant
Point your own assistant at your own keel: keel mcp serves eight read-only tools over stdio — doctor findings, the capability inventory, profiles, orders, the veto log, the purification report, the trials ledger, the research corpora. It cannot place, halt, attest, promote or arm anything: the write surface does not exist, and PRAGMA query_only = ON enforces read-only at the engine level. No hosted chatbot, no account — the server is a local process on your machine.
Verify in the repository: keel/mcp/tools.py
The engine's boundary, in its own words
keel is not a fatwa engine. It is an enforcement engine for a ruling you supply.
keel never derives a Shariah classification from market data. You record one — with a source and an attributed name — and keel enforces it deterministically. The ruling lives in your attestation, not in the code, so two operators following different schools get different answers from the same code, by design.
No scholarly review of keel's fiqh basis has occurred. The basis is one operator's sourced reading, published as a document precisely so it can be audited and challenged — and each operator is responsible for their own attestations.
Scholarly review: not reviewed — an open question, by design
The fiqh basis states plainly what a scholarly review would cover and what it would and would not signify. Until someone walks that path, the status is: not reviewed.