How Shariah crypto screening actually works

What screening is — and when it runs

Screening, in keel, is a curation gate: the process that decides which assets may enter the allowlist at all. It runs once, at admission — not on every trade. The basis keel cites is explicit that sector and backing are “a listing criterion, checked once when curating the allowlist, not per-trade” (§28.4). What runs per-trade is enforcement: rail 1 passes every order intent — DCA purchases included — through the allowlist, mechanically and un-overridably.

The division of labour is the point. The rail enforces a ruling; it never contains one. The ruling lives in the attestation a human recorded, and the rail simply refuses everything that ruling did not admit.

What is computed

Some questions about an asset are arithmetic, and the engine answers them itself, from its own candle cache: does the history run deep enough to evaluate a rule, is the book liquid enough to trade, can the pair settle into the operator's configured currencies. History depth, liquidity, and settlement quotability are market facts — recomputed freely whenever the cache changes, carrying no scholarship at all. This half of the screen is ordinary measurement, and it is honest precisely because arithmetic is all it claims to be.

What is attested — never inferred

The other half is not arithmetic. Whether a token's core purpose serves a prohibited sector, whether it is an owned thing ('ayn) or a debt claim (dayn), whether bare holding pays a riba-like return, and what kind of contract the listing actually is — these are questions of fact-plus-scholarship about the world. No module in keel derives them from candles, and none pretends to. A human records each answer, with a source and a name, and the engine enforces the record deterministically. The screen's four attested axes:

• Sector (§28.4). A token whose core business is a haram line — gambling, alcohol, riba-based lending, and the rest of the prohibited sectors — is rejected. Aave/Compound-class lending tokens fail here.
• Backing (§65.5/§67.2). An 'ayn — an owned thing — passes; a dayn, a debt claim on an issuer, is refused: trading a pure claim is a different contract under different rules. An 'ayn backed by gold or silver draws a warning that the stricter bay' al-sarf regime applies: no deferment, and a 72-hour settlement bound.
• pays_yield (§28.4, the riba screen). Rejects an asset that “carries a guaranteed/expected return for holding it, which is riba-like… holding it is not a bare spot position.” The field's semantics are bare holder — what holding the asset without staking or lending earns — and are established by fetching the asset's own documentation, not by assumption. Solana's staking docs, for example, say rewards require delegation, with no rebasing — so bare holding earns nothing, which is exactly what the field asserts.
• Instrument (§71.4a). The allowlist is not juristically homogeneous, so admission names the contract, not just the underlying: only spot is admitted. CFD, future, perpetual, option, and leveraged-token listings are refused, recorded via keel assets attest-instrument — and an unattested instrument fails closed, like everything else.

Fail-closed: unknown is a rejection

When the attestation is absent, the asset is not “probably fine.” It is unknown — and the screen fails closed on unknown. Absence of evidence is treated as absence of the ruling: no attestation, no admission. The same posture runs through the whole engine. Rail 17 refuses to acquire an asset whose withdrawal capability nobody has attested, on the recorded reasoning that “silence is not evidence of possession.” The kill-switch ships engaged. A stale attestation is no better than none.

Fail-closed is not a convenience choice; it is the only honest default for a machine. A screener that passes the unexamined is silently issuing rulings on everything it never looked at — one implied fatwa per unlisted asset. Refusing to decide is the decision, and it puts the burden where it belongs: on the human who supplies the ruling, with a source and a name attached.

What a waiver can — and cannot — do

A documented exception (keel assets exempt) may waive exactly one criterion today: history. That set is not an accident of configuration. Liquidity, settlement, and the spot instrument shape can never be waived, and no Shariah criterion can be waived at all — nothing in the screen consults a waiver for them. A new asset with a thin price history may be admitted on a documented exception; a haram-sector token has no paperwork that admits it. Expanding the waivable set is a deliberate future decision, never a default.

Why the machine refuses to decide

Because the decisions are not the machine's to make. Whether a token with no genuine use or benefit, surviving only because holders hope to sell higher, qualifies as Māl — tradable property — at all is “exactly the kind of judgement the screen defers to a human.” The DOGE question is the live example: the source's own lean is recorded, and it remains a deferral, not a decision.

Nor does the engine adjudicate between schools. Where sources diverge — the knowledge base records identical retail FX ruled haram by one jurisdiction and halal by another (§66.6) — keel records both sides and enforces whichever ruling the operator supplies. Two operators following different schools get different answers from the same code, by design. The ruling lives in your attestation, not in the code.

And the engine is honest about its own premise. Every ruling above presupposes that crypto is Shariah-recognised tradable property — and on that, the highest available authority declined to rule: IIFA Resolution 237 (§71.1) convened a dedicated symposium on electronic currencies, debated the matter at its 24th session in November 2019, identified exactly this question as unresolved, and issued no ruling. A withheld ruling is not a prohibition; it is also not a permission. That BTC/ETH-class assets are tradable property is keel's well-supported interpretive position, held on the conservative branch the sources direct to (§29.2) — not a settled ruling the engine can cite as fact.

Screening in practice

The Compliance menu's screen view lists every allowlisted product with its admission verdict: which axes are attested, which computed checks pass, and exactly what is missing. Recording a classification is one command — keel assets attest --asset --sector --backing --pays-yield --source --attested-by — and the last two flags are required, because an unsourced claim is not evidence. The audit trail records who said what; your deployment follows your ruling; upstream stays neutral.

What the screen does not even look at

Admission is not the whole of compliance, and the screen is honest about where its jurisdiction ends. Non-compliant income is handled by a separate, report-only mechanism: interest and reward credits are segregated from realised P&L and the equity base, reported as owed to charity, never recognised as profit, and zakat is computed on purified wealth (§65.9, §33.1). The agent never disposes of those funds — it reports.

And some obligations no engine can see at all. The venue pays USDC rewards on idle balances; that interest is riba and accrues with no order placed — so no rail can catch it. Disabling rewards at the account level is the operator's obligation, listed first in the operator runbook. Screening keeps unadmitted assets out; purification reports what came in anyway; the rest is on you, in writing, on purpose.