Halal crypto bot explained: how HalalCrypto works end-to-end

The six AI agents

The system is organised as six cooperating agents, each with a single responsibility. Decoupling responsibilities is what allows us to update one agent without disturbing the others — for example, refining the Signal Engine without touching the Halal Filter — and what makes the Halal Filter's veto authority absolute.

Trade lifecycle

From candidate setup to closed position:

1. Signal Engine emits a candidate (e.g. "ETH-USDT, breakout, confidence 0.78").
2. Halal Filter checks ETH against the four-gate framework. Passes.
3. Risk Engine sizes the position based on current equity, ETH's 14-day ATR, and remaining tier heat. Outputs order ticket.
4. Sanctions Screen confirms ETH is not sanctioned. Passes.
5. Execution Layer places the spot buy order on the user's exchange via the encrypted API key. Stop-loss at -2%, target triggers at 3%/5%/pyramid.
6. Order fills. Observability Layer logs the fill, updates the dashboard.
7. Exit triggers monitor continuously. First trigger to fire (3% in 4h, 5% in 1h, pyramid extension, or -2% stop) closes the position.
8. Observability Layer logs the close, recalculates portfolio heat, and frees capacity for the next signal.

Total elapsed time from signal emission to order placement is typically under 2 seconds. Total elapsed time from order placement to fill is exchange-dependent (typically under 1 second on Binance for our routing sizes).

Where data lives

Three distinct data domains, each with its own storage and access controls.

• Trade and portfolio data: per-user trade history, position state, and performance metrics. Stored in our application database, encrypted at rest, region-isolated. Accessible only via authenticated dashboard sessions.
• Customer-identifying data: email, billing details, account preferences. Segregated from trade execution data. Accessed only by the dashboard and billing services.
• API key vault: exchange API keys for every connected user. Hardware-backed, encrypted with per-user keys derived from a master HSM key, accessible only to the Execution Layer at trade time.

We do not share data with marketing partners, analytics providers, or third-party services beyond what is operationally necessary. Sentry-style error logs strip identifiers and never log API keys or trade-specific dollar amounts.

Where keys live

Exchange API keys are the most sensitive data we hold. They are stored in a hardware-backed key vault separate from the application database. Encryption is AES-256-GCM with per-user encryption keys derived from a master HSM key.

The Execution Layer reads a user's key on demand at trade time, decrypts in memory, places the order, and discards the plaintext immediately. The key never appears in logs, never crosses an external service boundary, and never persists in plaintext anywhere on disk.

We additionally require that withdrawal permissions be disabled on the key. With withdrawals off, even a worst-case scenario — full compromise of our infrastructure — cannot result in user funds leaving the exchange. The bot's authority is bounded by the API key's permissions, and those permissions exclude the only operation that could move funds.

How exits work

Every position has four possible exit conditions, evaluated continuously by the Execution Layer:

• 3% target in 4 hours: base case. Limit-sell order at +3% from entry, GTC.
• 5% target in 1 hour: fast-momentum case. Triggered exit at +5% within 60 minutes of entry.
• Pyramid extension: partial profit at 3%, trail the remainder. Trail tightens with position age.
• -2% hard stop: stop-loss order placed at trade entry, registered on the exchange.

All four are registered as orders on the exchange itself, not just in the bot's internal state. That means the exchange enforces them even if our infrastructure goes down — your stop will trigger regardless. Resilience comes from defence in depth, not from any single component.

How re-screens work

Halal screening is not a one-time check. The Halal Filter re-evaluates every coin on every trade decision against the latest gate state. Beyond that, three triggers fire event-driven re-screens:

• Continuous Gate 1 monitoring: any major tokenomics, governance, or revenue-mix announcement triggers immediate re-screen by the screening committee within 48 hours.
• Quarterly Gate 2 refresh: on-chain treasury data and reserve attestations recomputed every quarter.
• Daily Gate 4 refresh: sanctions lists pulled and matched daily.

If a coin transitions from pass to fail and you currently hold a position in it, the system suspends new entries immediately and unwinds the existing position in an orderly manner — typically over the next available exit window rather than a forced market dump. You receive an email notification within 24 hours explaining what changed, why the verdict shifted, and what the unwind looked like.

Frequently asked questions

Citations

• AAOIFI Shariah Standards — primary screening reference.
• Saudi Permanent Committee for Scholarly Research and Ifta — fatawa informing operational design.
• Al Rajhi Bank Shariah Board — public reviews informing infrastructure constraints.