Architecture
Senticore separates fast execution from trustworthy settlement by running matching, state materialization, and custody on distinct layers.
Component map
Six integration surfaces
Most crypto exchanges expose two ways in: REST and WebSocket. Senticore exposes six logical integration surfaces, each routed through the same canonical sequencer.
| Surface | For | Why |
|---|---|---|
| Public Market Data HTTP | Apps, dashboards, data consumers | Cacheable, unauthenticated, separated from trading paths |
| Trading HTTP | Retail traders, app backends | JSON over HTTPS, canonical signed actions |
| Public WebSocket | Real-time market data | Sequence-numbered, gap-recoverable |
| Private WebSocket | User account streams | Authenticated handshake, per-user channels |
| FIX Gateway | Institutional desks, OMS, quant funds | Industry-standard protocol with session sequence recovery |
| BSL Business Line API | Liquidity providers, quote engines, HFT systems | Bulk operations, compact byte submission, ack / durable / full results, cancel-on-disconnect, execution stream, quote obligations |
All surfaces converge into the same matching engine, risk checks, canonical state, and settlement path.
How this compares to other DEXs
| Surface | Hyperliquid | dYdX v4 | Senticore |
|---|---|---|---|
| Public Market Data HTTP | Yes | Yes | Yes |
| Trading HTTP | Yes | Yes | Yes |
| Public WebSocket | Yes | Yes | Yes |
| Private WebSocket | Yes | Yes | Yes |
| FIX Gateway | No | No | Yes |
| BSL compact order entry | No | No | Yes, through the Business Line API |
| Dedicated liquidity-provider bulk + execution stream + COD | No | No | Yes |
Comparison is based on publicly documented integration surfaces as of May 11, 2026. A venue may expose adjacent generic actions; the table marks "Yes" only when the surface is publicly documented as a dedicated integration surface. Sources: Hyperliquid API docs, Hyperliquid WebSocket docs, dYdX Integration Documentation, and dYdX WebSocket docs.
Sequencing layer
The sequencing layer validates signatures and credentials, accepts actions into the mempool, assigns deterministic order, and writes accepted events to a durable log before execution state is materialized. Ordering is a single deterministic primary - a single-writer design in the tradition of LMAX and exchange matching cores, not a multi-node consensus - with leader-lease failover for high availability. Determinism is the integrity anchor: the same accepted sequence always reproduces the same state root.
The durable event log is the replay boundary. It supports recovery, state verification, and incident analysis without making API read models the source of truth.
Execution layer
The execution layer runs matching and risk.
| Component | Responsibility |
|---|---|
| Matching engine | Maintains order books and generates fills |
| Risk engine | Applies collateral, position, exposure, and product constraints |
| State materializer | Converts accepted actions and fills into canonical account, order, balance, and settlement state |
Persistence layer
Three database boundaries keep concerns separated:
| Boundary | Responsibility |
|---|---|
| Canonical state | Authoritative execution and ledger state, write-heavy, backed by a durable event log |
| Read projections | Query-optimized views for public API, private API, streams, and the web application |
| Metrics and audit events | Operational observability, business metrics, and incident analysis |
This boundary keeps trading-state writes, user-facing reads, and operational control surfaces separated.
Settlement layer
Settlement is a separate layer, not a sequencer subroutine. It prepares checkpoint payloads, coordinates publisher quorum signatures, and commits roots on-chain.
| Contract | Role |
|---|---|
StateCommitment | Stores state and withdrawal roots signed by the publisher quorum |
MultiCollateralVault | Holds collateral and executes proof-backed withdrawals |
SPT Token | Proposed token for incentives, governance, and fee alignment |
Data flow: a typical trade
- A user or delegated credential signs a trading action.
- The client submits through HTTP, FIX, or the BSL Business Line API.
- The access layer validates credentials, action shape, and permissions.
- The action enters the mempool and receives deterministic ordering.
- The accepted event is recorded in the durable log.
- Matching and risk checks produce fills, rejects, or state transitions.
- Canonical state is materialized and read projections are updated.
- WebSocket streams publish market and account updates.
- Settlement roots are built and signed by the publisher quorum.
- Roots are committed on-chain for verification and withdrawal execution.
What we do not show
For clarity the diagram omits:
- internal admin and operational interfaces,
- per-process detail of sequencing primitives,
- monitoring, alerting, and incident-response infrastructure,
- staging and pre-production environments.
These are part of the operational surface and remain in internal operations documentation.
Continue with the trust model, threat model, and integration overview.