A practical guide to implemented paper-order risk limits in TEMIRIN using configured records, explicit market identity, current controls, and human review.
August 3, 2026 · 5 min read
A TEMIRIN paper order is a user-created simulation. The request needs an exact market and outcome, direction, paper price, notional, and creation time before the server can evaluate it. Keep the paper-only label visible on the ticket, response, ledger, journal, analytics, and export. A pass means the simulated record met the implemented checks for its stored context; it does not move funds or create an external transaction.
Validate units at entry. Prediction-market prices, probabilities, shares, and dollar notional can be confused when labels are abbreviated or copied from another screen. Preserve the raw user-entered values and normalized server values together with any safe error. Never replace the request price with a current quote after submission. Historical risk review is reproducible only when its original inputs remain unchanged.
The per-order check compares the requested paper notional with the applicable maximum for a single simulated record. Calculate it on the server after validating the amount and identifying the workspace and plan. Store the threshold, observed request, result, and safe blocked reason. A client-side preview can help the user correct an entry, but it should not become the authoritative risk response.
Test values below, exactly at, and above the documented boundary, including decimal precision and currency-unit cases. If a source or category maximum-stake override is part of current policy context, show which stored value applied without calling it a separate paper-order check. The record should distinguish the four enforced paper checks from supporting policy fields so a reviewer can identify why the request stopped.
The rolling twenty-four-hour check looks backward from the new request time and includes earlier paper notional still inside that window. It is not a calendar reset. Use server timestamps, stable workspace identity, and the stored paper ledger to calculate the total. Retain which earlier records contributed so support can reproduce the response without relying on the current clock or a summary number.
Boundary tests should place earlier requests just inside and just outside the window, then evaluate a new request at a fixed time. Cover simultaneous submissions and retries so duplicate requests do not quietly distort the total. If the required ledger cannot be read consistently, return a safe blocked state with an operational reason rather than treating missing history as unused capacity.
The per-market exposure check aggregates relevant simulated records for the exact market identity. Use stable market and outcome identifiers instead of shortened titles. Similar questions, opposite outcomes, and contracts with different date windows cannot be combined safely by name. Preserve market status and any unavailable identity field so an incomplete request cannot pass through a convenient text comparison.
Document how opposing paper outcomes are represented in the stored exposure calculation and keep the convention consistent. The check should use the implemented ledger rule, not a reviewer’s informal assumption about offsetting. When a market resolves or leaves the watchlist, keep the historical paper records attached to the identifier they used. A later configuration change must not rewrite the earlier exposure result.
The portfolio-concentration check needs the relevant stored portfolio context and a declared denominator. Preserve the configured public-wallet snapshot time, supported positions, missing values, and the concentration calculation used for the response. Public data may be delayed or incomplete and one address cannot represent every holding. Those limitations should be visible beside the paper result rather than hidden inside a precise percentage.
Keep the paper request separate from the external wallet observation. The requested notional is an amount the user entered for simulation; the wallet snapshot is read-only context. A passed concentration check does not reserve capital or prove that the visible balance is available. If a critical position or denominator is unavailable, the result should fail safely and name the missing context required for another review.
For each paper request, retain per-order, rolling twenty-four-hour, per-market exposure, and portfolio-concentration results with their inputs, thresholds, safe reasons, and evaluation time. Store applicable policy context separately: stake cap, source and category states, maximum-stake overrides, confidence setting, free-capital percentage, price-move guard, and kill switch. This structure shows exactly what the server checked and what the reviewer knew.
Build a regression set containing one pass, one block for each of the four checks, an unavailable-data case, a rolling-window boundary, and a concurrent request. Recalculate from the stored ledger and snapshot. Confirm that journal and export views retain paper status and the same reasons. When rules change, apply new behavior prospectively and keep the original response with the historical record.
Reconcile the user-facing reason with the server result for every fixture. The interface should name the same observed value, threshold, and paper context that the stored response contains, without exposing internal secrets or replacing a specific block with a generic warning. This comparison catches display drift while keeping the server record authoritative for later support and audit. Confirm that the exported row preserves the same check names and does not flatten several independent results into one status.
The server checks the user-entered request against per-order, rolling twenty-four-hour, per-market exposure, and portfolio-concentration limits using the stored context available then.
It uses the preceding twenty-four-hour window at request time. Test records near the boundary retain their timestamps so the calculation can be reproduced.
It means the simulated request satisfied the four implemented server checks for that stored context. The result remains a clearly labeled paper-only workspace record.
