SCALAR

A decision system for finding movement, inspecting execution, monitoring exposure and improving from evidence.

THESIS / 001

Trading software should reduce decision latency without hiding uncertainty. Scalar organizes the loop around four operator decisions rather than a collection of internal services.

PUBLICSHOWCASE LIVE

RADAR DATAHARDENING

OPERATOR APPPRIVATE

01 — Decision architecture

Discover → Execute → Monitor → Improve.

01Discover

Scanner

Radar ranks abnormal market velocity, participation and emerging setup structure across the scanned universe.

02Execute

Terminal

Market context and order preparation live together, while execution remains explicit and separately gated.

03Monitor

Portfolio

Positions, balances and exposure are treated as an operational state—not as a decorative dashboard.

04Improve

Performance

Execution quality, fees, churn, re-entry behavior and post-trade evidence close the learning loop.

02 — Public surface

Show the instrument, not the account.

01MARKET SOURCESPUBLIC FEEDS

02SCANNERVELOCITY + STRUCTURE

03PUBLIC CONTRACTSANITIZED GET

04RADARDELAYED + CACHED

METHOD / PAYLOAD-GROUNDED

The public demo will expose only an allowlisted projection of market-level fields. No account identifiers, private execution state or operator controls enter the public deployment.

03 — Trust boundary

Public by construction, not by bypass.

Public

Product narrative, methodology and a sanitized read-only Radar surface.

Private

Wallets, balances, positions, fills, postmortems and account-specific analysis.

Gated

Order submission, credentials, paid compute, service controls and operator tooling.

The public experience is a separate deployment with a narrow data contract. It does not relax authentication on Scalar's operator frontend or mixed private API.

Discuss Scalar ↗