We understand everyone is different, and for some people who struggle with gambling or addiction, it can be easy to get into trouble without realising when to stop.
While HivePredict is a platform designed to be fun, we also acknowledge that it is unethical to run a betting platform without strong safety controls. In this latest update, safety is a major focus, with features designed to stop people from getting in over their head.
Prediction markets can be fair and still be risky for people who need stronger boundaries. This release is our first responsible-betting milestone: user-controlled safety settings with on-chain actions, server-side enforcement, and clearer product boundaries.
What shipped
1) Dedicated Safety Settings page
Safety controls are now separated from the public profile into a dedicated Safety Settings page for account owners.
This keeps profile pages focused on identity/performance while moving risk controls into private account settings.
When threshold is reached, the indexer automatically starts a cooldown and records a safety event.
The next prediction/market attempt is blocked with a clear reason and refunded in batched transfer flows.
6) On-chain safety actions + indexer handling
Added a new custom_json operation: hivepredict_self_exclude_user.
Added a new custom_json operation: hivepredict_start_cooldown.
Added a new custom_json operation: hivepredict_set_safety_limits.
Added indexer handling to persist exclusion state and immutable safety events.
Added schema support for:
users.self_exclusion_type
users.self_excluded_at
users.self_excluded_until
users.self_exclusion_source
users.cooldown_started_at
users.cooldown_until
users.cooldown_reason
users.cooldown_source
users.loss_streak_threshold
users.loss_streak_cooldown_hours
users.monthly_stake_limit_hive
users.monthly_stake_limit_hbd
users.safety_limits_set_at
users.safety_limits_locked_until
new safety_events table for durable audit history
7) Hard server-side enforcement in market flows
Self-excluded users are blocked from:
creating new markets
placing new predictions
Cooling-off users are blocked from:
creating new markets
placing new predictions
Spending limits are enforced server-side for:
new predictions
creator opening bets in market creation
Enforcement occurs in indexer handlers (source of truth), not only web UI.
If a blocked transfer is observed in the official batched flow, refund logic is queued with explicit reason codes (for example User self-excluded, Cooling-off active, or Monthly spending limit exceeded).
8) Clear UX for blocked actions
Prediction form checks safety state and monthly budget, then disables invalid submissions.
Market creation flow does the same for opening-bet checks.
Safety Settings now includes:
self-exclusion controls
short cooldown controls
monthly spending limits
loss-streak auto-cooldown controls
safety history timeline
UI shows precise status messages including cooldown end times and lock windows.
9) New safety API surface
Added GET /api/users/:username/safety for:
current safety state
cooldown state
loss-streak settings and current consecutive losses
monthly limit state, month usage, and lock window
recent safety events
This endpoint powers Safety Settings and action prechecks in prediction/create-market UX.
Why this matters
This release shifts safety from operator-only controls toward user agency:
users can proactively stop participation,
users can proactively cap monthly exposure,
enforcement is deterministic and verifiable,
and the product explains exactly why an action is blocked.
It also establishes the data model needed for the next stages of responsible-betting features.
Expanded transparency reporting on safety activations and blocked attempts.
This is a foundational step, not the finish line. We’ll continue shipping safety as a core product capability, not an afterthought. If you haven't already, check out HivePredict. And as always, thank you to the community who have embraced this and have helped it grow and flourish.
Shipping Safer Betting Controls on HivePredict | Ecency
