Skip to content

Engineering challenge 01: separate estimated pressure from observed liquidation events #5

Closed

Description

@Zawwarsami16

Observed code path

There are two different sources behind the liquidation-pressure presentation:

  1. estimatePressureMap(state) in src/logic/zaiEngine.js assigns market.liqLong and market.liqShort from open interest and heuristic adjustments.
  2. connectLiveStreams(state, onTick) in src/services/market.js listens to Binance Futures @forceOrder and adds event notionals to those same fields.

Because scheduled market syncs also invoke estimatePressureMap, a user could reasonably mistake the combined or overwritten values for purely observed exchange liquidations. The README now distinguishes estimates and observations, but the runtime data model should too.

Proposed separation

  • Keep derived estimated pressure in distinct state fields (e.g. pressureEstimateLong, pressureEstimateShort) instead of the observed event counters.
  • Keep observed liquidation event notionals in separate counters with an explicit observation window and source/status.
  • Make the UI label each output as estimate or observed event volume, with appropriate source and freshness.
  • Ensure a periodic REST sync doesn't reset observed event totals or silently mix them with an estimate.

Reproducible acceptance test

Use synthetic market input and a synthetic @forceOrder event in a local development environment; no access to production accounts is needed.

  1. After a market refresh, calculated pressure estimates exist and observed event totals remain unchanged.
  2. When one liquidation event arrives, only the appropriate observed counter increases.
  3. After the next refresh, the event count persists for its defined window and the pressure estimate may recompute independently.
  4. When sources fail or the observation window rolls over, the interface reports the relevant status without presenting an estimate as a measurement.

A test plus a small PR would be especially valuable. Avoid real credentials, live trading, or stressing third-party services.

Discussion question: What is the least confusing way to present inferred liquidation risk beside actual exchange liquidation events?

For broader ideas, use Discussions.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions