Skip to main content
Righteous

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.

Syntax

,antiraid raid <on|off> [++punish <p>] [++joins <n>] [++window <s>] [++duration <s>] [++lockdown <on|off>]

Example

,antiraid raid on ++punish ban ++joins 10 ++window 10
FlagMeansAcceptsDefault
++punishwhat happens to each joinerwarn, timeout, mute, jail, kick, softban, banban
++joinshow many joins trip it2 to 5010
++windowhow many seconds they have to land inside5 to 12010
++durationhow long the response stays armed60 to 3600 seconds600
++lockdownalso raise the server's verification levelon / offoff

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

PunishmentBot needsGood for
warnnothingA dry run. Nothing happens to the member at all
timeoutModerate MembersA likely false positive. Reversible, and needs no roles set up. Fixed at one hour
muteManage RolesServers that already have a mute role configured
jailManage RolesServers that already have a jail role configured
kickKick MembersRarely the right call on a join raid: they can rejoin
softbanBan MembersClears what they posted and then unbans, leaving no permanent ban
banBan MembersA 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. Each takes ++punish from the same list as above, and each is armed and disarmed on its own.

Young accounts: antialt

,antiraid antialt acts on accounts younger than a number of days.

Syntax

,antiraid antialt <on|off> [++punish <punishment>] [++threshold <days>]

Example

,antiraid antialt on ++punish kick ++threshold 7
FlagMeansAcceptsDefault
++punishwhat happens to the joinerany punishment abovekick
++thresholdhow new the account has to be, in days1 to 3653

No profile picture: antipfp

,antiraid antipfp acts on members joining with no profile picture. It has no threshold. An avatar is either there or it is not.

Syntax

,antiraid antipfp <on|off> [++punish <punishment>]

Example

,antiraid antipfp on ++punish kick
FlagMeansAcceptsDefault
++punishwhat happens to the joinerany punishment aboveban

Everybody: antijoin

,antiraid antijoin 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. This is the one anti-raid setting only the server owner can change.

Syntax

,antiraid antijoin <on|off> [++punish <punishment>]

Example

,antiraid antijoin on ++punish kick
FlagMeansAcceptsDefault
++punishwhat happens to the joinerany punishment aboveban

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

Arm it with ++lockdown

++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.

Syntax

,antiraid raid on [++lockdown <on|off>]

Example

,antiraid raid on ++punish ban ++lockdown on

How the level gets put back

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.

When lockdown is skipped

Lockdown is skipped entirely if the bot lacks Manage Server, or if your verification level is already at High or above.

Unstick a server left on High

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.

Syntax

,antiraid unlock

Review and reset

,antiraid list shows every anti-raid rule and its settings.

Syntax

,antiraid list

,antiraid reset turns all of them off. The Anti-Raid page of the ,config panel arms and edits the same rules.

Syntax

,antiraid reset

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. One incident issues at most 200 punishments, so a very large wave cannot turn into a flood of API calls that takes the bot down. When that ceiling is reached the summary says so rather than quietly stopping. Only punishments actually taken count against it: a whitelisted or unpunishable member costs nothing.

Punishments are also paced: at most two run at a time in one server. A big wave therefore takes noticeably longer to work through than it took to arrive. That is a queue, not a cap: nothing in flight is dropped when the pace limit is reached.

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.