RAPHAEL CEX — BUILD PLAN
What else shall be done for creating
This page describes the road from the standing backend to a working exchange desk. It describes, never claims: no dates, no volumes, no revenue.
The creation record for Raphael CEX: what the 150-programme backend already provides, and what else shall be done before the exchange desk can exist end to end. This page stays private to the demonstration site until the materials are approved and uploaded.
The backend is not a promise: the full Rust fleet directory compiles on the live host, and the core services — ledger, core banking, identity — run there behind enforced authorization. Every payment, fill and custody movement the exchange ever makes will route through that foundation, which already refuses unauthenticated calls at the door.
No completion percentages. No "soon". Every item in the build plan is labelled done, in progress or planned, backed by a verifiable record where one exists — never by a claim.
the creation list — what else shall be done for building Raphael CEX, in order; labels state the facts, nothing is claimed ahead of its record
The 150-programme Rust backend directory compiles on the live host, and the ledger, core-banking and identity services run under process supervision on loopback with durable storage. The authorization law is enforced at the wire: unauthenticated requests are refused before any data moves.
The market book and matching engine join the fleet directory as a backend programme: instruments, order types, matching rules and the execution ledger recording every fill against the settlement fabric — with the same loopback + authorization walls as the rest of the backend.
Identifiers for exchange operators, reviewers and customers are issued from the operator workspace — identity derives from the verified sign-in session at the registry; nothing accepts a client-claimed identity.
Fills post through the Veritas Gold settlement path into custody and reserve, under maker-checker review. The exchange never settles on a private side ledger.
Customer acceptance, restrictions and sanctions checks ahead of any trading; read-only reconciliation views over every fill, cancel and settlement event for the audit trail.
The operator console and the customer-facing portal as separate API clients with every required state — signed-in, pending, refused, recovered — reading only live registry truth.
The pages this demonstration site is building today travel to the public domain only after the desk materials are approved — this build plan among them. Until then the site stays behind the demonstration gate.
outline-level planning text — simulated demo content, to be replaced by the desk's real materials
A single exchange surface whose market activity settles straight into the shared backend fabric — one book, one ledger, one audit trail — created in verifiable slices from a foundation that already exists.
Platform participants who need transparent market access with settlement they can reconcile at source, without bolting on an external reconciliation layer.
All market behaviour in this plan is simulated. No listing fees, revenue shares or volume targets are claimed, and no launch dates are promised: each build item lands when its record does.
Desk materials that would define scope, controls and steps:
outline-level engineering text — planned work is labelled, never claimed as shipped
Loopback-supervised ledger, core banking and identity services with enforced authorization, ready to carry exchange workloads.
Market book, matching engine and execution ledger as backend programmes with the same walls as every other fleet service.
Fills posting to custody and reserve through the Veritas Gold path with maker-checker review.
Read-only reconciliation views over every fill, cancel and settlement event, fed by the audit anchors the backend already produces.