Eigenstate
Systems

Trading Infrastructure

An interactive order and reconciliation demo. Drop a trade notification, recover the missing fill record, then complete or cancel the remaining order.

Constructed data, with no connection to a real account. The demo illustrates its own rules, not production system performance.

Try the order and reconciliation demo →

What you can try

Follow a buy order from start to finish

After recovery, finish at the target of two units or cancel and keep one. Both endings can leave the books in agreement with the provider.

  • Compare normal delivery with a dropped fill notification.
  • Separate an unfinished target from a disagreement in the books.
  • Read the same fill again without counting it twice.

The problem behind it

A trade can happen before the internal system records it. If a fill notification is lost, decisions based on the local books start from an incomplete picture of the position.

I built the replay so a reader can follow that missing record through recovery, then finish the order. Its two endings make the distinction visible: the books can agree whether the target is reached or the remaining order is cancelled.

Keep the target separate from the record of execution

A strategy specifies the position it wants. An order requests a trade; the provider executes it. The internal books learn about fills through notifications or queries. Reconciliation compares those books with provider records at the same checkpoint.

  • The strategy supplies a target; order acceptance alone does not create a holding.
  • The provider records execution; the internal books record fills they receive.
  • A position snapshot establishes the quantity to compare at a stated cutoff.
  • Fill history supplies evidence for a missing entry; recovery retains the trade’s ID.

When the records disagree

The provider has executed one unit, but its notification did not reach internal bookkeeping. The provider snapshot shows one; the books still show zero.

Retrieve the fill history for the same checkpoint, find the missing fill ID, record it once and compare again. Without the supporting record, the difference stays unresolved.

Step through the replay →

What I want to examine next

Examine what changes when fills continue to arrive during reconciliation, rather than pausing activity at the checkpoint.

Technical details, assumptions and verification

The model holds new fills still during comparison so the reader can examine one missing record. It assumes order acceptance and includes provider confirmation in the cancel action. Risk decisions, rejected orders, cancellation races, concurrent fills, corrections and other sources of position changes are outside this example. The comparison checks position quantity at a shared cutoff; equal quantities alone do not establish that every underlying record is correct.

Type
Execution and observability infrastructure
Domains
trading infra / execution / risk / observability

Available material

  • A browser-computed example with normal delivery, a dropped notification and recovery.
  • Downloadable constructed inputs and the same JavaScript calculation module used by the page.
  • Regression checks for pending notifications, partial fills, missing evidence, recovery and duplicate reads.

The replay calculates each state from its inputs. The downloadable inputs and JavaScript module use the same rules as the page.

  1. target
  2. order submission
  3. partial fill
  4. notification delivery
  5. position comparison
  6. record recovery if needed
  7. fill or cancel remainder
  8. final position check

The missed-notification example at comparison

target
2 units
provider_position
1 unit, through fill F1
local_position
0 units before recovery
position_difference
local minus provider = −1
recovery_evidence
F1: a buy of 1 unit, missing from the local books
remaining_order
1 unit remains open throughout recovery

Compare position records at the same cutoff. Find and record the missing fill once, then recheck. The target and remaining order stay unchanged.