4 · Attestations before anything is live
keel never derives a Shariah classification from market data — you record rulings, with sources, and the engine enforces them. This guide walks the "To go live" stage of the console's Setup checklist and the Gates view behind it: the work that makes a live profile possible.
Step 1 — Where the compliance work lives
The console's Setup page ends in a stage headed To go live — every attestation the rails refuse to trade without, each with its state and the command that records it. The Gates view is the other half of the picture: every action that increases what keel can do without asking again, and the interactive-terminal gate each one passes through. The view states it plainly: it cannot perform any of them.
Step 2 — Screen and attest the allowlist
The Setup checklist's step "Every allowlisted asset screened and attested" is judgement-shaped, and the page says what that means: keel can record your ruling; it must never choose it for you. Market facts are computed; Shariah classifications are attested, never inferred — an asset without an attestation is unknown, not fine, and the step's detail reads "unattested: ADA, BTC, …" until you clear it.
The step's own form — Record this attestation — asks for exactly the ruling: asset code, sector, backing ('ayn, dayn, or native), whether holding it earns a return, a source, and your name. Nothing is pre-filled or defaulted; an attestation without a cited source is refused like a missing one. The same action at the terminal:
keel assets attest --asset X --sector ... --backing ... --source ...Step 3 — Attest the venue subscription (rail 14)
Rail 14 refuses live BUYs until the operator attests the venue's subscription — the monthly allowance actually spent. What you pay the venue is a fact only you have; keel cannot read your billing. This one stays at the terminal — the checklist itself prints the command — and keel subscription show reads it back:
keel subscription attest --venue ... --tier ...Step 4 — Attest withdrawal capability (rail 17)
Rail 17 encodes qabd (§65.4): an asset that cannot be withdrawn may not have been validly possessed. keel withdrawals attest records withdrawal-capability attestations per product — the attestation carries a 7-day TTL and needs an interactive terminal, as both the checklist and the Gates view say outright.
keel withdrawals attest --enabledStep 5 — Attest the venue's trade scope (rail 20)
A credential that reads fine is not evidence it can trade: keel has watched a well-formed key pass every read and still have its first live order refused by the venue. Rail 20 closes that hole by failing closed — until a venue is attested, keel ships unable to place a live entry on it at all. keel scope attest --trading releases that veto, so it demands a typed yes at a terminal; --read-only only ever reduces capability and stays ungated. The record is bound to the credential that earned it, so a rotated key means re-attesting. Like rail 17, this is entries-only — exits are never affected, because an exit must always be able to leave.
keel scope attest --tradingStep 6 — Purification, honestly
keel purification reports non-compliant income owed to charity (KB §65.9) from what actually ran through the engine. Account-level duties no rail can see — disabling USDC rewards on idle balances, chiefly — appear in the checklist as the venue-interest step, and keel will never show that one as done: the venue's API does not expose enrolment, and a green check that verifies nothing turns an open risk into a false assurance. It stays on the operator's checklist, in the operator runbook.
Where this leads
With attestations recorded, a rule promoted through its gates, and the go-live runbook followed, the supervised first live order is the same confirm prompt you practiced in paper — with real consequences. Read the go-live runbook before that day.