Antiraid
Punish a burst of joins, gate young accounts, and lock the server down until the wave passes.
Anti-raid reacts to people joining. Where anti-nuke watches what your existing members do, anti-raid watches the door — a sudden burst of joins, accounts created yesterday, accounts with no avatar, or nobody at all while you close the server.
Anti-raid needs Administrator, with one exception.
,antiraid antijoin is Server Owner only,
because a door that turns everybody away is too blunt to sit behind a permission somebody can be
granted.
Turn on burst detection
,antiraid raid on is the main one. It counts
joins and responds once too many land too close together.
,antiraid raid on [++punish <punishment>] [++joins <n>] [++window <s>] [++duration <s>] [++lockdown <on/off>]| Flag | Means | Accepts | Default |
|---|---|---|---|
++punish | what happens to each joiner | warn, timeout, mute, jail, kick, softban, ban | ban |
++joins | how many joins trip it | 2 to 50 | 10 |
++window | how many seconds they have to land inside | 5 to 120 | 10 |
++duration | how long the response stays armed | 60 to 3600 seconds | 600 |
++lockdown | also raise the server's verification level | on / off | off |
When it trips, everybody in that burst is punished, not just the joiner who happened to cross the line. The people who arrived a second earlier are the raid, not bystanders standing next to it.
Every further join while it is armed pushes the disarm time forward, so duration is measured from
the last arrival rather than from the moment it started. Once things go quiet the response disarms
itself and posts a summary.
Try it as a dry run first
Arm it with ++punish warn and watch your protection log for a while. A warn rule posts the
incident and does nothing to anybody, which is the only safe way to find out whether your numbers
match how your server actually fills up.
Pick a punishment that matches the worry
| Punishment | Bot needs | Good for |
|---|---|---|
warn | nothing | A dry run. Nothing happens to the member at all |
timeout | Moderate Members | A likely false positive. Reversible, and needs no roles set up. Fixed at one hour |
mute | Manage Roles | Servers that already have a mute role configured |
jail | Manage Roles | Servers that already have a jail role configured |
kick | Kick Members | Rarely the right call on a join raid — they can rejoin |
softban | Ban Members | Clears what they posted and then unbans, leaving no permanent ban |
ban | Ban Members | A confident, unambiguous raid |
mute and jail need the matching role set with
,config muterole or
,config jailrole. Without one, the punishment
cannot be applied.
Gate accounts before they get in
Three smaller rules run on every join, independently of burst detection.
,antiraid antialt on acts on accounts
younger than a number of days. ++threshold <days> accepts 1 to 365 and defaults to 3, and the
default punishment is kick.
,antiraid antipfp on acts on members with
no profile picture. Default punishment ban.
,antiraid antijoin on acts on everyone who
joins, full stop. It is a closed door, not a filter — use it while you sort something out, and turn
it off afterwards. Default punishment ban. This is the one anti-raid setting only the server owner
can change.
Each takes ++punish from the same list as above.
antijoin catches everybody
There is no threshold and no exception for a legitimate new member. Leaving it on is the most common way to quietly stop a server growing.
Lock the server down while a raid is running
++lockdown on on the raid rule raises the server's verification level to High for as long as the
response is armed, then puts it back. It is off by default and it is the only anti-raid action whose
effect outlives the incident, which is why it gets its own safeguards.
The level to restore is written down before it is raised, so a restart in the middle of a raid does not leave your server stuck on High. When the raid ends the bot only lowers verification if the level is still exactly what it set. If a human changed it during the incident they had context the bot did not, and forcing it back could weaken a server somebody deliberately hardened.
Lockdown is skipped entirely if the bot lacks Manage Server, or if your verification level is already at High or above.
If a server is left raised anyway, ,antiraid unlock
puts it back. That command needs Administrator and forces past the checks above. With no record of a
raise it refuses rather than guessing a level it never saw.
Review and reset
,antiraid list shows every anti-raid rule and its
settings. ,antiraid reset turns all of them off.
The Anti-Raid page of the ,config panel arms and edits the same
rules.
Incidents post to the channel you set with
,antinuke log <channel>, falling back to the
general log channel from ,config logchannel.
Common issues
A big raid produced fewer punishments than there were joiners. There is a ceiling on how many punishments one incident issues, so a very large wave cannot turn into a flood of API calls that takes the bot down. When it is reached, the summary says so rather than quietly stopping.
The server is still on High verification after the raid ended. Run
,antiraid unlock.
Nothing happened when people joined. Check that the punishment's permission is present — a ban
rule with no Ban Members does nothing. mute and jail additionally need their role configured.
Real members are being caught by antialt. Lower ++threshold, or switch the punishment to
timeout so a mistake costs nothing to undo.
A restart happened mid-raid. Verification is restored as normal, but the punishment sweep does not resume. Re-punishing people after a restart would be a second, unasked-for round.