# Vetox Anti-Raid — capability reference

> Vetox Anti-Raid — raid detection and Join Guard thresholds, five screening rules, seven actions, exact defaults, and how rival anti-raid bots compare.

- Canonical: https://discordtools.blog/blog/vetox-anti-raid-reference
- Published: 2026-10-13
- Author: The Index desk
- Facts checked: 2026-08-30
- Sources:
  - docs.vetox.io — Anti-Raid (https://docs.vetox.io/en/moderation/anti-raid) — checked 2026-08-30
  - docs.vetox.io — feature limits by tier (https://docs.vetox.io/en/premium/feature-limits) — checked 2026-08-30
  - Beemo — anti-raid, free forever (https://beemo.gg/) — checked 2026-08-30
  - Beemo documentation — moderation (https://docs.beemo.gg/moderation) — checked 2026-08-30
  - Wick — premium pricing (https://wickbot.com/premium) — checked 2026-08-30
  - Security Bot — premium (https://securitybot.gg/premium) — checked 2026-08-30
  - Sapphire documentation — automoderation (https://docs.sapph.xyz/automoderation.md) — checked 2026-08-30
  - GiselleBot documentation (https://gisellebot.com/docs/docs-101) — checked 2026-08-30
- Publication: The Index, an independent site not affiliated with Discord Inc.

---
## 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

| Setting           | Type            | Default    | Range                                             |
| ----------------- | --------------- | ---------- | ------------------------------------------------- |
| Account age       | enum            | `3_months` | 1, 2, 3, 6, 9 or 12 months in the dashboard       |
| Action            | enum            | `kick`     | `mute`, `kick`, `ban`                             |
| Window (`period`) | seconds         | `5`        | 1–300                                             |
| Threshold         | number of joins | `15`       | 2–100                                             |
| Report messages   | on/off, channel | off, unset | start and end messages, **2,000 characters each** |

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

| Bound                 | Value                   |
| --------------------- | ----------------------- |
| Conditions per server | **10**                  |
| Condition name        | 1–50 characters         |
| Rules per condition   | 1–5                     |
| Actions per condition | 1–5                     |
| Match logic           | `and` (default) or `or` |

**Five rule types:**

| Rule                | What it tests                                                                           |
| ------------------- | --------------------------------------------------------------------------------------- |
| `account_age`       | Age against a value, with `less_than` or greater-than, in hours, days or months         |
| `default_avatar`    | The account has never set an avatar                                                     |
| `no_banner`         | The account has no profile banner. Fetched once per join, and only when a rule needs it |
| `username_contains` | Case-insensitive match against a newline-separated keyword list                         |
| `generated_name`    | Any of six named patterns for machine-generated handles                                 |

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

| Capability                                     | Starter | Basic | Max | Black |
| ---------------------------------------------- | ------- | ----- | --- | ----- |
| Reading the configuration                      | Yes     | Yes   | Yes | Yes   |
| Raid detection — all settings                  | —       | Yes   | Yes | Yes   |
| Join Guard — 10 conditions, 5 rules, 7 actions | —       | Yes   | Yes | Yes   |

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

| Action                    | Bot permission                                    |
| ------------------------- | ------------------------------------------------- |
| `kick`                    | Kick Members                                      |
| `ban`                     | Ban Members                                       |
| `timeout`                 | Moderate Members                                  |
| `mute`, `assign_role`     | Manage Roles                                      |
| `mute` channel overwrites | Manage Channels                                   |
| Report and case messages  | Send Messages, Embed Links in the target channels |

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](/blog/discord-bot-permissions-reference).

## What it connects to

- **[Protection](/blog/vetox-protection-reference)** handles privileged accounts already inside the
  server. Anti-Raid handles arrival. Neither substitutes for the other.
- **[Logging](/blog/vetox-logging-reference)** 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](/blog/vetox-roles-reference)** 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.

| Product          | Join-rate detection                       | Per-account screening                                          | Free?                                            |
| ---------------- | ----------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------ |
| **Vetox**        | Yes — 2–100 joins over 1–300 s            | 10 conditions × 5 rules × 7 actions, with a button-driven case | Basic, $4.99/mo                                  |
| **Beemo**        | **Yes — the whole product, free forever** | Not offered                                                    | Free; moderation logs are the paid part          |
| **Wick**         | Yes, free tier then paid                  | New-account, no-avatar, username and advertising filters       | $5/mo for the advanced tier                      |
| **Security Bot** | Yes, free tier then paid                  | Age, join speed, avatar and "normal join" scored 0–100         | Free tier exists; behavioural protection is paid |
| **Gaius**        | Yes, free tier then paid                  | Join age, blank avatar, custom-picture requirement             | Price not published anywhere                     |
| **GiselleBot**   | Yes, free                                 | Anti-Young Accounts, 1 hour by default                         | Free; **all logging is paid**                    |
| **Sapphire**     | **Not offered**                           | 7 Join Guard filters, ANDed                                    | Free                                             |
| **ProBot**       | **Paid**                                  | —                                                              | $5/mo                                            |

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