an attempt to process and execute highly-concurrent transactional tasks across Discord environments and verify state consistency through cryptographic auditing
Bronx is a lightweight, modular C++ Discord Bot framework built on D++ for high-performance economy systems. It features transaction-level gambling verification, dynamic global feature flags, concurrent cache management, and multi-server orchestration.
this incredible video on Event-Driven Architecture from the System Design community before reading the rest of this README. It provides an excellent introduction to handling race conditions in distributed systems and motivates the design of this framework.
The process of reliable transaction management is broken down into five stages: (1) formulating a bounded context, (2) recording pre-execution state data, (3) choosing an atomic locking mechanism, (4) designing a verification function to assess consistency, and (5) selecting an asynchronous approach for logging. At each stage, we discuss how prior system design knowledge may be embedded into the process. (adapted from the video)
- Installation
- Quick Start
- Application Commands
- Architecture
- Execution Workflow
- Auditing & Interactive Dashboard
- Parallel Server Optimization
- Comparing Analytics
- System Outputs
- Troubleshooting
- License
Requirements: C++17+, D++ (DPP) Library, MySQL, CMake.
git clone https://github.com/siqnole/bronxbot.git
cd bronxbot
mkdir build && cd build
cmake .. && make -j4No external message broker is required for basic operations—local memory fallback is built-in.
./bronx_bot --mode prod --shard-count 4The terminal dashboard will appear showing the connection status, shard latency, and incoming event stream. The bot automatically routes new commands using the parent-subcommand router structure.
In any Discord channel the bot is in, use:
/gamblingaudit
The evaluation embed opens with user constraints—showing win rates and total generated transaction histories.
./bronx_bot --mode dev --debug-guild 123456789012345678| Alias | Default Setup | Description |
|---|---|---|
--mode {dev,prod} |
dev |
Run in development or production environment. |
--export-db PATH |
— | Save current local db cache to SQL dump. |
| Command | Subcommands | Description |
|---|---|---|
/gamble |
slots, coinflip, dice, roulette |
Core economy verification games. |
/fish |
cast, inventory, sell, info |
Incremental interaction system. |
/gamblingaudit |
— | Personal dashboard for transaction validation. |
| Command | Required Permission | Description |
|---|---|---|
/log config |
Administrator |
Route system webhooks into Discord channels. |
/gambaudit |
Manage Server |
Audit a specific user's transaction history. |
| Command | Scope | Description |
|---|---|---|
/feature toggle |
Owner Only | Global killswitch for beta features (e.g. logger_beta). |
To bypass Discord's 100-slash-command limit, inputs are linearly mapped from parent commands to subcommands logic maps. This ensures the router always receives well‑formatted inputs, independent of the nested depth.
auto [subcommand, params] = parse_slash_subcommand(event, "gamble");To prevent race conditions during high‑frequency calls (like spamming /gamble coinflip), a Transaction mapping is applied immediately after the initial wallet extraction:
std::string txn_id = create_gambling_transaction(
db, user_id, "slots", bet, winnings, balance_before, "", "slots_data"
);The string ID is generated via a UUID v4 engine randomly initialized once and kept track of during the execution block. This technique allows us to confidently track atomic wallet updates.
- Input: Normalized Discord
slashcommand_t - Cache Layer: Projects input to memory checks (e.g., Message Cache limits outputs).
- Hidden Layers: Subsystem processing routines (e.g.,
bronx::db::gambling_verification). - Output: Application embed or message string sent back to the API.
The bot relies heavily on lambda architectures hooked into DPP's core listeners.
The total safety requirement is a boolean-check flow:
if (!verify_gambling_transaction(db, user_id, txn_id, balance_before, balance_before + winnings)) {
send_error("verification failed - race condition detected");
return;
}- verify_gambling_transaction: Asserts the absolute equivalence between expected balances and the true database values.
- If it fails, any wallet update is halted—eliminating double-spending without needing harsh SQL locks.
All user-responses conform to our Style Guide and utilize a soft-color embed template for aesthetic continuity. The layout includes:
- Primary Output: Core action text set directly in the description (
bronx::create_embed). - Outcome Status: Lowercase, functional formatting (
amount: +$2,000). - Error Bounds: Red/Orange fallback warnings if checks fail.
A background thread handles async webhook dispatches to keep interaction replies fast (under 3s).
For every critical action, the script records:
- Discord Timestamp
- Event Type (
GAMBvsGBHK) - User Metadata
- Contextual amounts and before/after balances.
These are written direct to the database via native MySQL APIs.
The user wallets are updated through atomic update_wallet calls only when the pre-verification passes. Database configurations natively use single-threaded mutex mappings (std::lock_guard<std::mutex>) when executing critical inserts.
The Evaluation embed mode loads user history and presents an interactive dashboard.
- The
gamblingauditmodule queriesget_gambling_stats(db, user_id)to automatically discover historical data. - This ensures the audit always covers the exact balance sequences a user was trained/exposed to in the system.
A custom button row allows interactive scrubbing through the history logs. The history panels update instantly, while the loss metrics (Total Wagered) remain static.
If the command was executed on a user suspected of exploits, an owner Step Slider / Limit param (/gambaudit max:200) forces deeper history recall. Scrubbing through history logs shows visually how the user's wallet progressed over time.
To manage different economy rules across various Discord guilds, the bot relies on database configuration rows in guild_settings.
The database utilizes specific columns to structure each server's experience. Supported domains:
| Setting Key | Type | Default | Description |
|---|---|---|---|
guild_id |
bigint | required | The root Discord identification node. |
prefix |
varchar | . |
Command prefix for legacy routing. |
economy_mode |
enum | global |
Determines if wallet stats sync globally or per-server. |
beta_tester |
tinyint | 0 |
Flips on experimental slash features for the guild. |
Example Config Retrieval:
bool is_beta = db->get_guild_setting(guild_id, "beta_tester") == "1";Each server is essentially routed as a separate event inside DPP's shard cluster. The events execute concurrently; thread isolation ensures one server doing heavy gambling doesn't throttle another server's normal chatting endpoints.
After tracking numerous transactions across the ecosystem, use the integrated tools to generate comparison views.
auto stats = get_gambling_stats(db, user_id);This populates structures tracking:
- Metrics: Unverified transactions, Verified transactions, Win rate %, Max balance reached.
.gambaudit 123456789012345678 100
This forces the analyzer to span the latest 100 vectors for that specific user, compiling result sets in real time.
| Target | Description |
|---|---|
history table |
Primary archive containing all temporal metadata, domain bounds, and IDs. |
webhook_logs |
Async dispatch routing pointing to target Discord Channels. |
terminal stdout |
Live JSON/String output of the active C++ event loop threads. |
These happen when interaction_create takes longer than 3 seconds. The bot automatically falls back to defer() patterns for operations known to scrape history tables.
This happens when multiple connections execute simultaneously on the same user. The verification_check accurately blocks the write to prevent double-spending. The user must retry their original sub-command.
Check your webhook configuration using /log status. If the logger_beta feature isn't enabled via the Database, the async threads will short-circuit and remain dormant.
If the cluster fails to respond, ensure:
- Database connections aren't saturated (threadpool checks).
- DPP Token is valid and not rate-limited.
- Intents for message reading are enabled via the Discord Developer Portal.
Copyright © 2026, BRONXBOT
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction—including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software—and to permit persons to whom the Software is furnished to do so, subject to the following strict conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Furthermore, the Software must be used ethically. It must not be used for surveillance or for malicious data collection. Under no circumstances may the Software be used to comply with, supply, or assist ICE, Israel, the US Government, or any foreign government body/agencies.
Additionally, any modifications, alterations, or tampering with the Software differentiating it from its original form must be explicitly documented and appended to this document as an act of public accountability and transparency, particularly if the Software is being utilized commercially or hosted as a public bot.
DISCLAIMER:
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.