A daily loss limit should do one job well: stop the tracker from helping a user add exposure after a boundary chosen in advance has been reached. It is not a prediction model, not a moral lecture, and not a claim that browser storage cannot be bypassed. It is a friction layer at the moment friction matters.
The engineering standard is stricter than “show a warning.” The submit path must receive a typed decision. The locked state must survive a refresh. Open bets must count as exposure. A rollover must follow a declared calendar rule. Corrupt state must fail closed with a cure instead of quietly resetting the day.
Define the boundary before writing the component
The product needs a clear definition of daily loss. Settled losing tickets and unsettled exposure are different fields. A win may change net account balance without erasing the fact that the user already crossed a precommitted loss boundary. Decide which behavior the policy intends and name it in the interface.
The safest placement check uses worst-case additional loss. It asks whether settled losses plus open exposure plus the proposed stake would cross the configured limit. It does not subtract a hoped-for payout from the exposure. A ticket cannot fund itself before it settles.
Keep deposits and withdrawals outside the daily-loss calculation. Otherwise a deposit can make the guard appear healthy without changing what happened during the session. The bankroll ledger may track those flows, but the limit state should keep its own purpose intact.
Use a closed result type at the submit boundary
type PlacementDecision =
| { kind: 'allow' }
| {
kind: 'block';
reason:
| 'limit-reached'
| 'proposed-exposure-crosses-limit'
| 'state-stale'
| 'state-corrupt';
cure: 'wait-for-rollover' | 'lower-exposure' | 'reload-state' | 'reconfigure-limit';
};The form handles every branch. An allowed decision can proceed to placement and record the new open exposure. A blocked decision renders the reason, the cure, and the effective rollover. There is no optional error string that a caller can forget to display.
The decision function should be pure. Give it validated state, proposed exposure, and the current instant; receive a result. Persistence, rendering, and sportsbook navigation belong outside the function. That separation makes the guard testable without a browser.
Model state explicitly
interface LossLimitState {
configuredLimitAmount: number;
periodStartedAtMilliseconds: number;
settledLossAmount: number;
openExposureAmount: number;
lockedAtMilliseconds: number | null;
pendingIncreaseAmount: number | null;
pendingIncreaseEffectiveAtMilliseconds: number | null;
revision: number;
}Names carry their units because boundary math is where vague fields become bugs. “time” and “amount” are not enough. The state also needs a revision so multiple tabs can identify an older write rather than clobbering a newer one silently.
Validate every field after reading storage. Amounts must be finite and non-negative where the policy requires it. Timestamps must be finite. A pending increase needs both an amount and an effective time or neither. Illegal combinations return state-corrupt and block placement until the user deliberately reconfigures.
Choose one calendar policy and publish it
A daily boundary is a calendar decision, not a duration added to the previous timestamp. Compute the next boundary from the configured local calendar and rollover hour. Adding a fixed duration can drift across daylight-saving transitions.
The application should display the time zone and exact next reset in the locked message. Travelers and users with devices set to different zones should not have to guess which clock controls the limit. If the product supports a home zone, store that explicit zone rather than inheriting every device change.
Test spring and fall transitions in the zones the product supports. Test a lock immediately before rollover. Test a device clock moving backward. The expected behavior should follow the policy, not whatever the host runtime happens to do.
Count open exposure before placement
The guard is weakest in the gap between clicking submit and settlement. Every accepted ticket adds its worst-case loss to open exposure as part of the same application transaction that records the ticket. Settlement removes that exposure and, for a loss, adds the settled amount to daily loss.
Two tabs make this harder. Both can read the same state and approve separate bets before either write becomes visible. Use a single writer, a storage lock with revision checks, or a server-backed policy when stronger enforcement is required. A storage event can update the interface but does not by itself make a read-modify-write sequence atomic.
When the ticket submission fails, roll back the reserved exposure. When the outcome is corrected, apply an idempotent settlement keyed to the ticket. Duplicate settlement events must not count the same loss twice.
Make increases harder than decreases
A user should be able to lower the limit without friction. Raising it during a locked session defeats the purpose, so the increase belongs in a pending state that becomes effective only after the published cooling-off and rollover policy are satisfied.
Do not hide the pending change. Show the current limit, requested limit, effective time, and a control to cancel the increase. The policy should never silently replace a lower boundary because the application reopened.
The exact delay is a product and regulatory decision that needs its own source. This article does not invent one. The invariant is directional: lowering protection is delayed; strengthening protection is immediate.
Local storage is friction, not enforcement
A determined user can clear or edit browser storage, use another device, or place a bet outside the tracker. Say that plainly. The client-side tool can block its own workflow and create a pause. It cannot control every external sportsbook.
For stronger enforcement, sync the policy to an authenticated service and make the server the conflict authority. Even then, the tracker can only govern actions routed through it unless the operator provides an integrated restriction. Link users to operator limits and support resources rather than presenting the browser guard as a vault.
Test the failures that appear under pressure
- Rollover transition: the calendar policy produces the same declared local reset through daylight-saving changes.
- Aggregate exposure: individually acceptable tickets are blocked when their combined open exposure crosses the boundary.
- Failed submission: reserved exposure is released when no ticket is created.
- Duplicate settlement: replaying the same settlement does not change state twice.
- Multiple tabs: stale revisions cannot overwrite a newer exposure total.
- Corrupt storage: invalid state blocks placement and explains how to reconfigure.
- Pending increase: the lower active boundary remains in force until the declared effective time.
These are regression tests, not demo cases. Removing any one of the guards should make the suite fail. The visible banner is the least important part of the feature; the submit boundary and state transitions are the contract.
Integrate without making claims the app cannot enforce
The tracker can call the decision function before its own save action, reserve exposure when placement is recorded, and settle idempotently when a result arrives. The article does not claim that the bettor desk currently enforces every state above. The shipped interface should be verified separately.
Bankroll Management Basics explains why the boundary belongs outside the handicap. the tracking guide covers the ticket ledger the guard depends on. Stronger device-level or operator controls remain appropriate when a browser friction layer is not enough.
The watchpoint
The feature is ready when every path that creates exposure must handle the closed decision type, multiple tabs cannot undercount open tickets, rollover follows the published calendar policy, and corrupt state blocks rather than resets. The promise is modest on purpose: the tracker will not help you cross your own line without making the override explicit.
Bankroll growth from recorded Kelly outcomes
Growth paths are shown only when a verified source supplies recorded bankroll observations for the requested Kelly strategy.
Drawdown by recorded Kelly fraction
Drawdown comparisons are shown only when a verified source supplies observed outcomes for each Kelly sizing strategy.
