Understand the implemented per-order and rolling twenty-four-hour notional checks that keep prediction-market paper orders bounded and auditable.
August 3, 2026 · 4 min read
The per-order check compares one requested simulated notional with the plan-scoped maximum for a paper order. The rolling twenty-four-hour check totals relevant paper-order notional across the preceding twenty-four hours and compares the new request with the plan allowance. Both checks apply only to paper orders inside TEMIRIN.
The rolling window is calculated from persisted paper-order timestamps at the evaluation time. A passed paper check records that the user-entered simulation satisfied the implemented per-order, rolling twenty-four-hour, per-market exposure, and portfolio-concentration conditions at that moment.
A rolling calculation depends on paper-order timestamps and the notional field used by the server. Show the requested amount, relevant period start, existing total, limit, and result in consistent units. That makes a block reproducible from the exact rolling boundary and stored inputs.
If a record is missing or malformed, return a visible blocked result rather than assuming unused allowance. Preserve the original paper-order timestamp and audit event so later reporting can reconstruct which records were inside the window when the request was evaluated.
For a support check, choose one evaluation time and list every included paper record by stable ID, creation time, and notional. Sum those persisted values, add the new user-entered request, and compare the result with the plan allowance. Save the calculation inputs beside the audit reason so a second reviewer can reproduce the same answer from the ledger.
The same paper-order request is checked against per-market exposure and portfolio-concentration limits using stored portfolio context. Those checks prevent one simulated request from being reviewed in isolation when the saved snapshot already shows meaningful exposure.
Display every binding reason. A request can be below the per-order maximum yet fail the rolling total, per-market exposure, or concentration check. Do not silently reduce the paper order or describe the result as an individualized recommendation; return the requested amount and the reason the simulation was blocked.
An in-app approval can refer to the same watchlist-derived opportunity while remaining a separate authenticated record. A provider-configured Telegram or Slack alert has its own delivery ledger, and the user creates any paper order explicitly in the workspace.
The decision endpoint enforces the configured price-move guard. Users initiate any evidence-driven fresh review manually. If evidence, role, exposure, or policy context changes, users should open a fresh review; if price moves beyond the configured threshold, the endpoint rejects the stale decision conditions.
Test a request exactly at the per-order maximum, one just above it, several paper orders whose rolling total reaches the allowance, and one whose earliest record falls outside the twenty-four-hour period. Add per-market and concentration failures so each reason can be distinguished.
For every case, retain the request, timestamps, stored snapshot reference, plan value, outcome, and audit-safe error context. Recalculate the result from the same inputs and verify that unchanged data produces the same answer. This tests the implemented paper ledger without pretending that a simulated result was executable at the venue.
Review the explanation from a user perspective. It should name the paper order, user-entered simulated notional, rolling twenty-four-hour evaluation time, each implemented check, and any blocked reason in plain language.
Use a fixed set of test timestamps to verify the rolling boundary precisely. Include a paper order just inside the twenty-four-hour period, another just outside it, and a new request that moves the total from below the allowance to above it. Confirm that the displayed total, period start, plan value, and blocked reason agree with the server result. Repeat with a request above the per-order maximum and with per-market or concentration context that blocks independently. The resulting records should remain clearly simulated, retain their audit timestamps, and name the four implemented checks consistently.
Document the exact evaluation time and preceding twenty-four-hour boundary. This keeps support explanations aligned with the implemented query and makes the result reproducible from persisted paper-order timestamps.
The per-order check compares one simulated notional with its cap. The rolling check combines relevant saved paper-order notional inside the preceding twenty-four hours with the new proposed record.
Use the persisted creation times of the relevant paper orders and a clearly recorded evaluation time. The preceding twenty-four-hour boundary should be reproducible from the ledger.
Block the simulated save, identify the applicable limit, show the current amount and proposed notional, and retain a safe audit reason. The control should not silently reduce or rewrite the user-entered amount.
