Vetox Anti-Raid — capability reference

What it is

Two join-time defences sharing one configuration document. Raid detection counts how many accounts younger than a set age joined inside a rolling window, then acts on the member who trips the threshold. Join Guard screens every join individually against up to ten named conditions, each combining up to five rules with AND/OR logic and firing up to five actions.

The problem it solves

Discord’s verification levels are coarse and static. They gate everyone identically regardless of what the account looks like, and they do nothing about a coordinated wave of accounts that all pass the same check. Raid tooling is built to satisfy a static gate.

A server needs two different instruments. A flood alarm that notices rate. And a per-account screen that reads age, avatar, banner and username shape before the account is through the door.

Anti-Raid is the door. Message filtering happens after someone is already inside it.

How it works

Raid detection runs on every join:

1. Account age is a pre-filter. An account older than the configured threshold is discarded and never counted — raising the threshold makes detection more sensitive, not less.
2. Members whose join timestamp falls inside the configured window are counted.
3. The alarm fires when the count including the joining member reaches the threshold.
4. A start message posts to the report channel, the action applies to the joining member only, and an end message follows.

Three actions: mute, kick, ban. The mute action creates or reuses the server’s mute role, then writes Send Messages: deny, Add Reactions: deny and Speak: deny overwrites for that role across every text, voice and stage channel, and records the mute as a permanent entry (no auto-expiry) in the moderation store — so an anti-raid mute is visible and liftable from Moderation Tools rather than being invisible state, and stays in place until a moderator lifts it.

Join Guard runs independently, on every join, whether or not a raid is in progress. Each enabled condition evaluates its rules, combines them with the condition’s match logic, and runs its actions in order on a match. A kick or ban aborts the remaining actions and every later condition — which makes action ordering meaningful, not cosmetic.

Both handlers require the Anti-Raid module toggle on the Server Setup page. It is off until you turn it on.

What is configurable

Raid detection

Start-message placeholders substituted at send time: [Usernames], [Users], [UsersCount]. The count refers to the other recent joiners, so it reads one below the threshold that fired. message.end sends verbatim with no placeholder substitution.

Account-age values map at 30 days per month for every value except twelve months, which is treated as a full calendar year (365 days) rather than 360. The underlying setting actually accepts all twelve monthly values from 1_months through 12_months; the dashboard’s picker offers the six most commonly used (1, 2, 3, 6, 9, 12) as presets.

Join Guard

Five rule types:

The six generated-name patterns: ends with three or more digits, starts with three or more digits, underscore then digits, digits then underscore, digits only, and a short letter-run followed by digits.

Seven action types: assign_role, kick, ban, timeout (minutes, default 10), send_dm, send_to_channel, and open_case.

open_case is the one worth understanding. It posts an amber embed carrying the member, their account age in days, a relative creation timestamp, the rules that matched and the condition name — with Kick, Ban, Timeout and Ignore buttons attached, restricted to the moderator roles named in the condition. A screen that produces a decision for a human rather than a punishment.

Eleven message variables are available to Join Guard actions: [User], [Username], [DisplayName], [UserId], [Avatar], [AccountAge], [AccountCreated], [ServerName], [MemberCount], [MatchedRules], [ConditionName].

Tier availability

One gate covers both halves, at Basic — $4.99 monthly or $44.99 yearly. The ceilings do not scale with tier: ten conditions, five rules and five actions are the same on Basic, Max and Black. Entitlement resolves live, so a lapsed subscription is treated as Starter on the next write.

Commands

None. Anti-Raid has no slash command. Its only in-Discord interactive surface is the four buttons on a Join Guard case embed.

That is deliberate for a system whose whole job is to run before anyone types anything.

Dashboard surface

• /server/:id/anti-raid — raid-detection thresholds, report channel, start and end messages, and the Join Guard condition builder.
• /server/:id/setup — the Anti-Raid module toggle both handlers require.

Permissions required

The bot’s highest role must sit above every member it acts on. This is the cause of most “the permission is granted but nothing happens” reports, and it is a position problem rather than a checkbox problem — see the permissions reference.

What it connects to

• Protection handles privileged accounts already inside the server. Anti-Raid handles arrival. Neither substitutes for the other.
• Logging records the resulting actions in the same timeline as manual moderation.
• Moderation Tools receives anti-raid mutes as ordinary punishment records, browsable and liftable.
• Delayed roles are the quieter alternative to the same problem: hold access for a fixed period after join instead of screening at the door.
• Command Management owns the module toggle both handlers check.

The chain: Anti-Raid → Protection → Auto-Mod → Logging → Moderation Tools.

Who it is for

Public, discoverable or advertised servers — anything with an open invite that a raid tool can find.

Join Guard specifically earns its place on servers seeing a steady trickle of throwaway accounts rather than one dramatic wave. A trickle never trips a rate threshold, which is exactly why per-join screening exists alongside it.

Practical use cases

Flood alarm with a named report. Threshold 15, window 5 seconds, account age 3 months, action kick, with a report channel and a start message using [UsersCount] and [Users] so staff see the wave named as it happens rather than reconstructing it later.

Quarantine rather than punish. One condition, match logic and, over account age under seven days plus default avatar plus a generated-name pattern. Actions: assign a quarantine role, then open_case. Nothing destructive happens, and a moderator decides from four buttons.

Keyword screening against a specific tool. username_contains with the handle patterns a particular raid generator produces, action ban. Narrow, and it costs nothing to leave running.

Observe before enforcing. Because a kick or ban aborts everything after it, put send_to_channel and open_case first while you are still calibrating whether a condition is safe to automate. Move the destructive action up once the case channel shows it firing only on real targets.

How it compares

Of the sixteen moderation and security bots examined in this research, join-rate raid detection is present in most and absent in a few — and the free/paid line falls in different places for reasons worth knowing.

Beemo leads on raid detection as a discipline, and it deserves the credit plainly. Its zero-configuration stance is a product position rather than an omission — its documentation states the algorithm is not configurable because it is designed to work dynamically, with no other configuration required or available. Its cross-server raid reporting improves detection for every protected server, a network effect no per-server rule engine can reproduce. If raid detection is the only thing you need, Beemo does it free and does it well.

Wick leads on what happens after a raid succeeds — its Panic Mode reconstructs pre-incident state, and it is the only product in this set that attempts recovery rather than only prevention.

The axis Vetox competes on is the second instrument: a configurable per-join screen with a review surface, sitting in the same product as the message filters, the logs and the punishment history. Beemo and Sapphire approach that screen from opposite directions — Beemo has rate detection without per-account rules, Sapphire has per-account rules without rate detection. Running both instruments from one configuration, with one log destination and one member history, is the platform argument rather than a depth argument.

One honest caveat on price: Beemo’s raid detection is free and Vetox’s is not. A server whose only requirement is flood detection has a $0 option that works.