ThrillPots Release Notes
| Release Name | Release Month | Release State |
|---|---|---|
| ANTICIPATION | January 2026 | Final |
IMPORTANT: As with most of our releases, the intent is that all packages are deployed to their latest versions (stipulated in Docker Images).
General
This release is not mandatory
POTENTIALLY BREAKING CHANGES
- ThrillPots Gateway service now only sends JackpotUpdate events when the ticker values have changed.
- ThrillConnect service now only sends JackpotUpdate events when the ticker values have changed.
- New env vars:
TCS_OPTIMIZED_TICKER_UPDATES, default: true; Enables optimized jackpot update eventsTCS_WEB_MAX_BODY_BYTES, default 102400; Controls the maximum body size for http requests
- New indexes on
thrillpots.log_contributions- for clients with high volumes we recommend creating the indexes prior to the upgrade. Instructions here
INFRA + DATABASE CHANGES
-
Removed unused indexes on the
thrillgate.player_bonusescollection:instance_id- [
player_id,instance_id]
-
Added extra indexes on
thrillpots.log_contributionscollection:player_idsource_gameround_idwallet_tx_credit_id
New Features
ThrillPots
-
Exclusion Rules for contributions and jackpot visibility
- Exclusion rules make it possible to restrict access to jackpots based on:
- Game Code(s) -- you can now prevent certain game codes from participating in the jackpot
- Game Category(s) -- you can now prevent certain game categories from participating in the jackpot
- Player ID(s) -- you can now prevent certain players from participating in the jackpot
- Player Segment(s) -- you can now prevent certain player segments from participating in the jackpot
- Vertical ID(s) -- you can prevent certain verticals from participating in the jackpot (eg "sports")
- The "Get Jackpot For Source" APIs now support an additional query parameter (
game_code) which can be passed as context for exclusion rule checks. This will allow you to determine whether a jackpot should be shown to a player in the context of a specific game or not.
- Exclusion rules make it possible to restrict access to jackpots based on:
-
ThrillPots now stores the wallet-level credit transaction ID in the documents stored in
log_contributionsandlog_winnerscollections. This new field (credit_tx_id) can be used to easily reference the credit transaction that the operator wallet would have received.
ThrillPots Gateway
-
Websocket Connection metrics added:
- A new prometheus metric (
websocket_connections) has been added to the metrics accessible on the/metricsendpoint - The metric is categorised by source IP, for example:
# HELP websocket_connections Open Websocket Connections by Source TID Account. # TYPE websocket_connections gauge websocket_connections{ip="127.0.0.1"} 1- For load balanced environments, the
X-Forwarded-Forheader is respected. Support for other platform headers can be added on request.
- A new prometheus metric (
-
WebHook HMAC signing is now available. When configured, webhook payload will be signed with the computed HMAC included in
X-Server-Authorizationheader.- A new admin API for setting HMAC secret for webhook signature. More details
ThrillGate
- New Admin API exposes endpoints to allow purging of REDIS cached objects:
DELETE /admin/cache/clear/:model_idmodel_idcan be one of the following values:WalletProvider
ThrillConnect
- Token preflight validation via Regex or JWKS. More details
- Exposed APIs to provide Latest Winners functionality to frontend clients. More details
ThrillOffice
- New ThrillPots Template Management admin view
- New ThrillPots Source Management admin view
- New ThrillPots Exclusion Rules Management admin view
- New Jackpot Model Switching admin interface
- Reconciliation view now features multiple view modes. The supported modes are:
- Delta mode: only shows the monthly movement per jackpot
- Groupped mode: group all instances into one consolidated row per month
- Jackpot state management - admin users can now pause and unpause the jackpot instance
Changes/Improvements
ThrillPots
- Improvements to Community Payout Strategy: Random Active Players
- Improvements have been made to the random selection mechanism for players that fall under the Active Players Payout Strategy.
- Always Fair Multicurrency minimum bet constraints are now configurable for Percentage Based Jackpots.
- Model Switching is now currency aware. Migrating to a model with a different currency can happen by explicitly passing
convert_currency: truein the request parameters. The API handles the currency conversion based on the current rate definitions and stores the exchange rate used in the audit log. - Empty string idempotency keys in contribution requests are now treated as nil
- Added support for payload signature on contribution outcome webhook callback
ThrillGate
- Improved transaction handling on retry exhaustion
- Improved pending transaciton monitoring
- Added the ability to settle witheld transactions via batch transaction api
ThrillConnect
- Optimized jackpot update events - updates are broadcasted only if the pot values had changed; Can be disabled via env
TCS_OPTIMIZED_TICKER_UPDATES=false - Improved handling for failed tokens during WS authentication. The new system holds a cache of failed tokens and ignores re-attempts of authentication using failed tokens. This is expected to prevent unintended flooding of failed token authentication requests from flooding deeper into the system.
- New admin APIs for token validations
- Administration APIs are now audited
- Get Jackpot For Source now accepts
game_codequery parameter to enforce exclusion rules - Deduped
allowed_sourceson jackpot update events - HTTP request body size limited to 100kb; Can be overwritten via env var
TCS_WEB_MAX_BODY_BYTES - Added support for custom CORS headers
ThrillOffice
- Dashboard: top players cards now display the brand
- New optimized reporting APIs for dashboard use:
- API audit now enabled in limited proxy mode
- Improved organisation scoped filtering
Bug Fixes
ThrillOffice
- File export - filename length limited to fit OSs constraints
- User modal - fixing incorrect default state being org bound
ThrillGate
- If the operator platform exchanges the
tokenpassed in SWAuthRequest with another token to be used, the new token is now honoured and used.