PolyEngine is composed of a set of tightly scoped services that together process trading intent, execute orders deterministically, maintain the trading ledger, and produce verifiable execution history.
The architecture is event-driven and ordered, separating admission, execution, accounting, and distribution concerns while maintaining a single authoritative trading state.
High-Level Flow
Trading flows through PolyEngine as follows:
Order Intent → Admission (AAS) → Order State (SOS) → Matching Engine → Settlement → Ledger → Market Data / Proofs
Each stage has a distinct responsibility and produces explicit outputs consumed by the next stage.
Order Intent and API Ingress
All trading activity begins with order intent submitted through the Polyester UI or APIs.
Order intent includes new order creation, order modification, order cancellation, and trigger activation.
These requests enter PolyEngine through its API layer and are immediately routed to the Order Management System (OMS).
Order Management System (OMS)
Once order intent enters PolyEngine, it is handled by the Order Management System (OMS).
OMS manages the full lifecycle of orders before, during, and after execution. It enforces admission rules, tracks order state, and coordinates with the matching and settlement layers.
OMS is composed of two primary components:
- Account Admission Shard (AAS): determines whether an order is allowed to enter the system and places the necessary reservations.
- Symbol Order State (SOS): owns order state and manages lifecycle transitions throughout execution.
These two components operate together to ensure that only valid, properly reserved orders are ever exposed to the market and that order state remains consistent throughout execution.
Account Admission Shard (AAS)
The Account Admission Shard (AAS) validates whether an order is eligible to enter the system.
After a user submits order intent, the AAS does all of the following:
- Performs structural and risk checks
- Validates order parameters
- Calculates required reservations
- Places reservations against the trading ledger
Crucially, fund reservation happens at admission, before an order is visible to the market. This prevents over-commitment, double-spending, and invalid exposure.
If an order fails admission, it is rejected immediately and never reaches execution or matching.
Orders that pass AAS are handed off to SOS for active lifecycle management.
Symbol Order State (SOS)
The Symbol Order State (SOS) manages orders once they have been admitted.
After admission by AAS, SOS:
- Registers the order under its associated symbol
- Tracks all lifecycle transitions
- Monitors the order while it is active in the matching engine
- Emits authoritative order state events as the order progresses
SOS owns the canonical state of each order, including whether it is open, partially filled, fully filled, or canceled. While the matching engine determines how orders interact, SOS determines what the current state of each order is at every point in time.
SOS does not perform matching itself; it coordinates between admission, execution, and downstream consumers to ensure order state remains consistent, ordered, and observable throughout execution.
Matching Engine
Once an order is active under SOS, it becomes eligible for execution in the Matching Engine.
The Matching Engine maintains the full L3 order book for each market and handles:
- Applying price-time priority
- Matching eligible orders deterministically
- Producing executions when matches occur
Orders arrive at the matching engine only after passing admission and reservation. The matching engine does not reason about balances or custody; it operates exclusively on orders that SOS has made eligible for execution.
When executions occur, the matching engine emits execution events that are routed back through SOS and into settlement.
Settlement and Ledger Updates
Executions produced by the matching engine are processed by Settlement.
Settlement calculates the final outcome of each execution and:
- Applies fees and rebates
- Releases or adjusts reservations
- Transfers assets between the two counterparties of a trade
These changes are posted as atomic updates to the trading ledger, ensuring that partial fills, multiple executions, and final settlement are reflected correctly and exactly once.
Settlement is the point where matched intent becomes finalized balance movement.
Append-Only Immutable Database
Throughout the entire order flow, PolyEngine records every trading-related event in an append-only immutable database.
This database records:
- Admission decisions
- Order state transitions
- Executions and settlements
- Reservation and balance updates
- Internal transfers
Entries cannot be modified or deleted. New events are only appended, preserving a complete, ordered history of trading activity.
This database serves as the authoritative source for replayability, auditability, and proof generation.
Market Data Distribution
Market data is a direct byproduct of the same event flow that orders create throughout their lifecycle.
Order state events and execution events recorded in the append-only database are streamed into the market data pipeline, where they are transformed into L1, L2, and L3 order book views, aggregated into trades, candles, and statistics, and distributed to clients through edge gateways.
This delay is a deliberate design choice to preserve market fairness and reduce order-level exploitation, without affecting execution correctness or auditability.
All published market data reflects finalized execution events produced by PolyEngine.
Proof Anchoring and Replayability
From the immutable database, PolyEngine periodically generates cryptographic commitments that are submitted to Polyester Chain.
These commitments attest to:
- The ordering of events
- The correctness of execution
- The integrity of state transitions
Proofs are derived from the complete internal execution history, including order-level activity that may not be immediately visible in public market data feeds. The timing of market data distribution does not affect what is proven.
While execution events are observable through market data streams on different release schedules, proof submissions establish durable checkpoints that reflect everything that occurred, making the full trading history replayable and independently verifiable.
Separation of Process
Each component in PolyEngine has a narrowly defined role:
- API Layer handles intent ingestion.
- AAS decides whether orders are allowed to enter.
- SOS owns order lifecycle state.
- Matching Engine performs price discovery.
- Settlement updates balances and fees.
- Ledger enforces atomic accounting.
- Market Data reflects execution outcomes.
No single component bypasses another. This separation is what enables both performance and correctness.