Stack.bet provides personal limits, account cooldowns, and self-exclusion for different levels of player protection. These controls can restrict access or make a decision harder to reverse, but they do not make gambling safe, prevent every loss, or replace outside support when play is causing harm.
Three different player-protection controls
The strongest control is not always the one with the longest label. What matters is when it takes effect, what it restricts, and whether it can be relaxed later. The current Stack.bet controls work as follows.
Control | Purpose | When it starts | How it ends or changes |
|---|---|---|---|
Personal limit | Sets a stake, rolling loss, or session boundary | New and safer limits take effect immediately | Less protective changes require cooling off and later confirmation |
Cooldown | Starts a fixed short break | When the account confirms the cooldown has started | At its scheduled end; it cannot be ended early online |
Self-exclusion | Requests a longer exclusion of at least six months | After the submitted request is reviewed and applied | Not automatically at the minimum end date; reactivation rules still apply |
Personal stake, loss, and session limits
Signed-in players can configure three personal boundaries:
A maximum stake per bet, measured in USD.
A rolling 24-hour loss limit, measured in USD.
A session-duration limit, measured in minutes.
The account may also have stricter game-policy or administrator-set ceilings. A personal setting cannot raise the account above those boundaries. If the current limits cannot be loaded, Stack.bet keeps changes disabled rather than asking the player to make a decision from incomplete information.
Limits are protective account controls, not spending recommendations. Choose amounts and time periods that reflect what you can afford to lose, and stop if play is no longer entertainment. The current controls are available from the responsible gaming page after login.
Safer changes are immediate; less protective changes are delayed
A new personal limit or a reduction to an existing limit takes effect immediately. For example, lowering a maximum stake or shortening a session limit does not wait through a cooling-off period.
Increasing or removing a limit follows a different path. The current safer value remains in force for at least 24 hours. When that period ends, the requested change still does not become effective by itself: the player must return and positively confirm it.
This design separates an immediate protective decision from a later decision that would allow more play. A pending increase or removal should not be described as an active limit until the cooling-off period and confirmation are complete.
Account cooldowns
A cooldown is a fixed, player-initiated break. The current choices are 24 hours, 3 days, 7 days, or 30 days. Once the account confirms that the cooldown has started, gameplay is unavailable until its scheduled end and the cooldown cannot be ended early online.
Current responsible-gaming policy can also restrict deposits and affiliate access during a player cooldown. A cooldown is not the same as closing the account or submitting a self-exclusion request, and this article does not claim that every account function is locked. Read the live account message before attempting another action.
Use a cooldown when an immediate fixed break is the appropriate protection. If a longer and more difficult-to-reverse restriction is needed, review the separate self-exclusion process.
Self-exclusion starts with a reviewed request
Stack.bet currently offers minimum self-exclusion periods of 6 months, 1 year, and 5 years. A signed-in player chooses a period, confirms that they understand the minimum, and submits a request for administrator review.
Submission is not the same as activation. While the request is pending, the account has not yet been excluded. The self-exclusion page shows the request reference, submission time, and review state so the player can distinguish a pending request from an active restriction.
If the request is applied, the exclusion cannot end before its minimum period. Use the self-exclusion page to submit or view the current state, and contact Stack.bet support if the status appears wrong or urgent assistance is needed.
A minimum end date is not automatic reactivation
A player-managed self-exclusion remains active when its minimum period ends. The player must first request reactivation. The current process then applies a 24-hour cooling-off period and requires the player to return and positively confirm the request.
Until those steps are completed, the exclusion remains active. It should never be described as automatically expiring after 6 months, 1 year, or 5 years.
This online reactivation path applies only to player-managed exclusions. Administrator- or system-managed exclusions cannot be reactivated from the player account, even if a displayed minimum period has ended. Support can explain the visible status, but this article does not promise that support will remove or shorten a restriction.
Support and outside help
Responsible play means treating gambling as entertainment, not as income; avoiding the urge to chase losses; setting limits; taking breaks; and never gambling money needed for daily responsibilities. If gambling is affecting work, relationships, borrowing, or the ability to stop, take that concern seriously.
Stack.bet’s responsible gaming page lists independent organizations that support people experiencing gambling problems, including Gamblers Anonymous, Gambling Therapy, and GamCare. Stack.bet support can help with an account control or status question through the contact page.
These controls and this article are not medical, financial, or legal advice. They cannot guarantee that harm or loss will be prevented. The product disclosures explain the current real-money, crypto, and service risks.
Methodology and change control
This article was reviewed on against Stack.bet’s current public responsible-gaming and self-exclusion controls and the matching limit, cooldown, request-review, and reactivation rules.
Account controls are operational features and may change. The signed-in account state and the current Terms and Conditions govern a specific request. If the available durations or lifecycle rules change materially, this article and its last-reviewed date must be updated with them.