Every audit log action is intercepted, scored with heat, and if limits are breached — the attacker is banned, damage is reverted, and the server enters lockdown.
Click attack vectors to see how heat accumulates and triggers Panic Mode
Click an attack vector above to simulate...
Every Discord audit log event passes through this chain
Audit log / on_message / on_member_update
is_filter_enabled(guild_id, action)?
Owner? Extra-Owner? Bot self? Role hierarchy?
If whitelisted: track via Betrayal Guard
deque per-user: 60s + 3600s windows
Ban attacker, revert damage, add heat
Rolling Windows: Actions are tracked in a deque per user per action type. Entries older than 3600s are pruned on each check.
Limit Math: Configured limits use max(0, limit - 1) — a limit of 1 means the FIRST action triggers punishment.
Ban Lock: Each punished user has a 5-second lock to prevent duplicate bans from concurrent events.
Exceptions: bot_add and prune do NOT use rolling limits — they trigger instant punishment on the first unauthorized action.
Click any filter to see exact behavior, recovery details, and limitations
banMonitors audit log ban events. Bans the attacker when they exceed limits. Auto-unbans victims via a background recovery queue with 1s rate-limiting between unbans. Also triggers the Wall Role if 15+ bans happen within 60 seconds.
Per Minute
1
Per Hour
1
Heat
45
The algorithmic brain behind automatic lockdowns
Heat is per-server, not per-user. Every filter action adds its configured heat value to the global pool.
A background @tasks.loop(minutes=1.0) decreases heat by decay_rate (default: 5) every 60 seconds. During Panic Mode, decay is paused.
When heat reaches 0, the entry is deleted from the database. When heat ≥ threshold, Panic Mode triggers.
/panicmode enable threshold:100 duration:300 decayrate:5The separate tracking, heat, and punishment system for whitelisted users
When any filter event fires, check_event_validity() runs. If the user is whitelisted, the normal filter is bypassed — but handle_betrayal(guild, user, action) is called instead. This function checks if Betrayal Guard is enabled for the guild, and if so, routes to handle_trusted_action().
1
Event fires
Any of the 16 filters
2
Whitelist match
User is whitelisted for this action
3
Normal filter skipped
Returns True → no normal punishment
4
Betrayal routed
handle_betrayal() called
5
Trusted tracking
Separate deque with trusted limits
Path A: Normal Trusted Action (within limits)
Called via add_trusted_heat(guild, action)
Example: ban action (heat=45) → trusted heat = max(1, 45//3) = 15
Path B: Betrayal Detected (exceeded limits)
Called via antinuke_tools.add_heat(guild, action)
Example: ban action (heat=45) → betrayal heat = 45 (full, unreduced)
Exact order from handle_trusted_action():
Ban the betrayer
guild.ban(member, reason=..., delete_message_days=1)
Strip ALL whitelist entries
Iterates every action key in whitelist_cache and removes the user's ID, then writes to DB
Activate Wall Role
activate_wall(guild, bot) — top 2 roles elevated + permissions stripped
Add FULL heat to server
tools.add_heat(guild, action) — NOT the 1/3 reduced version
Send betrayal log
Embed via webhook: betrayer mention, trigger action, and actions taken
Ban Lock Difference:
Betrayal Guard uses a 10-second ban lock (vs 5s for normal filters) to prevent race conditions during the whitelist strip + wall activation sequence.
Configurable per-action via trusted_limits_cache. Fallback: 8/min, 40/hour if guild has custom config but missing action key.
When betrayal fires, strip_whitelist() iterates every action key in the guild's whitelist cache, removes the user's ID from each list, and writes the entire updated whitelist to the database in one commit.
Yes. The full heat from a betrayal event feeds into the same add_heat() function that checks against the panic threshold. A severe betrayal can single-handedly trigger Panic Mode if heat ≥ threshold.
/antinuke betrayalguard enableRole hierarchy manipulation to physically block bans/kicks
1. Mass Ban Detection
AntiMember tracks ALL ban events in a 60-second rolling window. At 15+ bans, the Wall activates. Uses a cooldown to prevent re-triggering.
2. Prune Detection
AntiPrune calls activate_wall() immediately on any unauthorized prune event.
3. Betrayal Guard
When a whitelisted user exceeds trusted limits, activate_wall() is called.
get_wall_roles() selects the top 2 roles with the most members (excluding @everyone, managed, and bot-managed roles). Then:
ZEON Wall ~ 1 [ AN ]On deactivation, everything is restored from the snapshot: original name, permissions, and position.
/antinuke wallon/antinuke walloffBlocks managed/integration roles from granting dangerous permissions
Monitors on_member_update for new roles added to members. If a role is both managed (linked/integration) AND has dangerous permissions, it triggers.
Also detects roles assigned within 5 seconds of a member joining (invite link exploit).
Dangerous permissions checked (with force=True):
neutered_roles cache — future assignments of neutered roles silently remove themThis protection is separate from the normal member_update filter and runs as the AntiLinkedRole cog.
Maximum security — zero tolerance
Sets all 16 filters to: 1 minute limit / 1 hour limit / 100 heat. Whitelist is completely ignored.
Only Server Owner and Extra Owners are exempt. But for bot_add and prune, even Extra Owners lose immunity.
Z+ has no revert command. Revert by running /antinuke wizard.
/antinuke zplusDuring wizard setup, a role named ZEON Barrier [ Z+ ] is created with Administrator permission, assigned to the bot, and positioned just below the bot's top role.
Purpose: If someone removes admin from the bot's main role, the Barrier ensures the bot retains Administrator access.
If the Barrier role is deleted, the on_guild_role_delete listener automatically recreates it.
Every command in the security system
| Command | Permission | Description |
|---|---|---|
| /antinuke wizard | Server Owner | One-click setup: enables antinuke, creates barrier role + log channel, enables all 16 filters with wizard limits |
| /antinuke enable | Server Owner | Enables antinuke with all filters OFF — use /antinuke manage to toggle |
| /antinuke disable | Server Owner | Disables antinuke (settings saved) |
| /antinuke reset | Server Owner | Destructive reset: deletes ALL antinuke data (filters, limits, whitelist, barrier role, trusted limits) |
| /antinuke manage | Server Owner | Interactive button panel to toggle each filter on/off |
| /antinuke zplus | Owner / Master | Max security: all filters at 1/1/100, whitelist bypassed |
| /antinuke autorecovery enable|disable | Server Owner | Toggle auto-recovery (unban, channel/role recreation) |
| /antinuke betrayalguard enable|disable | Server Owner | Toggle Betrayal Guard monitoring on whitelisted users |
| /antinuke whitelist add @user action | Server Owner | Whitelist a user for a specific action |
| /antinuke whitelist remove @user action | Server Owner | Remove from whitelist |
| /antinuke limit action minute hour heat | Server Owner | Set custom limits for any filter |
| /antinuke wallon | Server Owner | Manually activate wall role |
| /antinuke walloff | Server Owner | Manually deactivate wall role (restore snapshot) |
| /antinuke logging #channel | Server Owner | Set log channel |
| /antinuke logdisable | Server Owner | Disable logging |
| /mainrole add @role | Server Owner | Add a main role (max 6) — protected from unauthorized stripping |
| /mainrole remove @role | Server Owner | Remove a main role |
| /mainrole show | Server Owner | List all configured main roles |
| /mainrole reset | Server Owner | Clear all main roles |
| /panicmode enable | Server Owner | Enable auto-panic: threshold, duration, decayrate |
| /panicmode disable | Server Owner | Disable auto-panic |
| /panicmode set | Server Owner | Update individual panic settings |
| /panicmode reset | Server Owner | Reset panic settings to defaults |
Exactly how ZEON responds — with accurate heat math
Scenario
A token-grabbed admin starts banning members rapidly.
ZEON Response
Ban filter fires on the 1st ban (limit=1 means max(0,1-1)=0 tolerance). Attacker is banned, victim auto-unbanned via recovery queue. +45 heat added. If 15+ bans in 60s, Wall activates independently.
Scenario
A Discord integration auto-assigns a managed role with Administrator permission to a new member.
ZEON Response
AntiLinkedRole detects the managed role with dangerous perms on member_update. Role is removed from the member. Role permissions are neutered to Permissions.none(). Role ID is cached — future assignments silently stripped.
Scenario
An attacker creates webhooks and uses them to spam @everyone across channels.
ZEON Response
AntiMention detects @everyone from a webhook_id source. Message is deleted. The webhook itself is fetched and destroyed. Separate from this, if the webhook was created by an unauthorized user, AntiWebhook adds +50 heat and bans them.
Scenario
Three compromised accounts simultaneously ban members, delete channels, and create spam roles.
ZEON Response
Attacker A: ban → +45 heat. Attacker B: channel_delete → +40 heat. Attacker C: role_create → +25 heat = 110 total. Exceeds threshold (100). Panic Mode auto-triggers: Z+ enabled, Wall raised, all 16 filters at max sensitivity for 300 seconds. After that, original config restored.
Scenario
A whitelisted admin starts mass-deleting roles after being compromised.
ZEON Response
Normal filter lets them through (whitelisted). Betrayal Guard separately tracks them: 12/min limit. On the 13th action, they are banned, ALL their whitelist entries across all actions are stripped, Wall is activated, full heat is added.
Scenario
Someone changes the server name, icon, banner, verification level, and vanity URL.
ZEON Response
AntiGuild saves a full server snapshot on bot ready. On guild_update, it detects the changes via audit log. Attacker is banned. All properties reverted — including re-downloading and re-uploading the original icon/banner binary data via aiohttp. Vanity URL changes are detected separately via audit log entry and the attacker is banned (vanity itself is NOT auto-restored).