raid & nuke protection.

raid cleanup, the antinuke command allowlist, automatic guards, and channel nuking solve different problems. the first is a manual response, the next limits who can use certain havoc commands, and the guards watch for bursts of harmful activity. nuke replaces a text channel with a clone, either now or on a schedule.

honeypot setup creates a writable trap channel with a warning panel and persistent kick/ban counts. its optional channel_type choice is honeypot (the default) or random, which generates a 16-character name from lowercase letters and digits. any message from a non-exempt account triggers the configured action, including command messages. the default is a kick. this is a channel rule, not proof of automation. havoc attempts a private notice before removal; closed dms do not prevent the action.

,honeypot setup
/honeypot setup channel_type: random
,honeypot hide @Members
,honeypot action kick
/honeypot status

server and bot owners, staff with moderation permissions, antinuke admins, exempt roles, bots and webhooks are ignored. havoc needs the configured kick/ban permission and sufficient role hierarchy. the trap also needs view channel, send messages, embed links, read message history and manage messages. new arrivals must retain view and send access; existing role overwrites can affect that access.

cleanup searches up to 200 messages from the last hour in each accessible text channel and active cached thread, deleting only the caught account’s messages. inaccessible channels and failures are reported through moderation logging. archived threads are not scanned, and interrupted background cleanup is not retried after restart. ban mode also requests discord’s one-hour message deletion.

raid sorts current non-bot members by join time and selects everyone whose join falls inside the supplied duration. it then applies the chosen action at half-second intervals and creates a case for each successful target. the command runner needs ban members to start it and also needs the permission for the chosen action.

,raid 20m ban coordinated join raid
/moderation raid duration: 10m action: timeout reason: review recent joins

the lookback is capped at seven days. timeout always lasts one hour and is stored for scheduled release. raid does not inspect account age, messages, roles, or intent: join time is the complete selection rule.

guard uses discord audit-log entries to identify the acting member. after at least four distinct destructive targets in 15 seconds by the same member, it bans them by default or kicks them if you choose that action. channel, role, and webhook deletions plus member bans and kicks count. rapid webhook creations or updates and channel or role edits can raise an alert but never trigger punishment by themselves.

,log add #staff-log moderation
,guard action ban
,guard on
,guard status

the server owner, protected accounts, havoc itself, and members on the antinuke trusted-admin list are exempt. havoc must be able to view the audit log and have ban members or kick members, as selected, with a role above the actor. one deletion is not enough to punish someone, and an unknown actor is never punished. if a log route is configured, alerts go to the moderation log. the guard starts off in each server.

raidguard alerts when 12 non-bot members join within 30 seconds. a join wave alone does not prove any individual account is malicious, so it never kicks joiners just for joining. separately, when one non-staff member posts the same message at least eight times across two or more channels within 20 seconds, it attempts to kick that member. it skips commands, trusted administrators, protected accounts, and members with manage server permission.

,log add #staff-log moderation
,raidguard on
,raidguard status

the repeat-spam kick needs kick members permission and sufficient role hierarchy. when the existing automod spam rule is enabled, that rule handles messages instead, so the two systems do not punish the same burst twice. the guard starts off in each server and uses the moderation log route for alerts.

only the server owner can change the antinuke administrator list. the owner does not need to be listed and always passes the antinuke check. every other member must satisfy the command’s ordinary discord permissions and have their user id in this allowlist.

,config antinuke list
,config antinuke add @operations-lead
,config antinuke remove @former-admin

::server owner

always exempt from the antinuke allowlist requirement and solely controls membership.

::antinuke admin

a specifically trusted member who may pass the extra gate, provided they also hold the command’s normal permission.

::everyone else

blocked from protected command paths even if they hold administrator in discord.

command restrictions can narrow who invokes a command, but they do not replace the antinuke gate. see permissions & security for the interaction between discord permissions, role hierarchy, and server command restrictions.

running bare nuke in a text channel clones that channel, keeps its name, position, and permission overwrites, then deletes the original by default. the replacement has a new channel id. lock, hide, and lockdown restoration records are copied so later recovery still points at the replacement.

havoc journals each replacement before deleting the source and can resume a partially completed operation after interruption. that protects the replacement process from a restart; it does not turn deletion into a reversible action.

schedules repeatedly replace one channel. each cycle updates the saved channel id to the latest replacement, posts the configured announcement without mentions, creates a scheduled nuke case, and schedules the next cycle. the minimum interval is one hour and the maximum is one year.

,nuke archive #daily-chat on
,nuke add #daily-chat 24h a fresh daily chat is ready
,nuke list
,nuke view #daily-chat

only one active schedule may exist for a channel. manual nuke refuses to run while that channel has an active schedule; remove the schedule first. removing it cancels future cycles but does not restore channels retired by earlier cycles.

raid can fail per target when havoc’s role is not high enough or its action permission is missing. the bulk task reports completed and rejected totals. nuke requires a text channel havoc can clone, edit, and delete; it pauses rather than deleting when the recorded replacement disappears or recovery cannot identify a safe source.

raid creates moderation cases for successful targets, while manual and scheduled replacements create management cases. configure event routing in logging before relying on those records during an incident.