Safeguards are the protections embedded throughout PolyEngine that prevent invalid, unsafe, or inconsistent trading states from ever occurring.
Safeguards stop incorrect actions at admission, enforce deterministic behavior during execution, and guarantee correctness at settlement.
Admission-Level Safeguards
The first line of defense occurs before an order ever reaches the market.
At admission, the Account Admission Shard (AAS) evaluates every trading action against a fixed set of constraints. These checks ensure that only valid, fund-backed intent is allowed to proceed.
Admission-level safeguards include:
- Verification that sufficient balance is available to reserve funds
- Enforcement of reservation limits and exposure constraints (e.g., preventing a new order from exceeding a subaccount’s allowed exposure even if total balance appears sufficient)
- Validation of order parameters and structure (e.g., rejecting an order with an invalid price, size, or unsupported combination of modifiers)
- Rejection of orders that would violate self-trade prevention rules
- Enforcement of subaccount permissions and policy constraints
If any safeguard fails at this stage, the order is rejected immediately and never becomes visible to the market. This prevents invalid intent from affecting liquidity, sequencing, or downstream execution.
Execution-Time Safeguards
Once an order is admitted and active, additional safeguards apply while orders interact in the matching engine.
These safeguards ensure that execution behavior remains fair, ordered, and deterministic even under high throughput.
Execution-time safeguards include:
- Explicit sequencing of orders before matching (e.g., two orders arriving at nearly the same time are matched in a deterministic, reproducible order)
- Strict enforcement of price-time priority
- Guarantees that post-only orders never remove liquidity
- Prevention of self-referential or circular execution paths (e.g., avoiding execution paths where an order could indirectly trade against itself)
- Deterministic handling of partial fills and simultaneous interactions
Because execution is deterministic, the same ordered inputs always produce the same outcomes. This makes execution behavior explainable, reproducible, and verifiable.
Settlement Integrity Safeguards
Safeguards continue through settlement to ensure that execution results are applied correctly.
Every execution is settled through an atomic ledger update. Balance changes, fee application, rebate credits, and reservation adjustments are applied together as a single indivisible operation.
Key settlement safeguards include:
- Atomic balance updates with no partial outcomes
- Exact correspondence between executions and ledger changes
- Consistent handling of partial and full fills
- Prevention of double application or skipped settlement
If settlement cannot be applied in full, none of it is applied. There is no state in which one side of a trade is finalized while the other is not.
Safeguards as a System Property
Safeguards in PolyEngine are a system-wide property enforced across admission, execution, and settlement. Each stage assumes that upstream safeguards have already been applied and adds its own guarantees before handing control to the next stage.