BlazeBans

BlazeBans is built around one idea: a punishment is a record, not an event. Every action creates a row with an ID, a reason, who issued it, when it expires, what scope it applies to, and any evidence attached. Everything else in the plugin reads from that record.

That gives you:

• Seven punishment types. Ban, mute, warn, kick, IP ban, IP mute, and voice mute through the voice chat addon.
• A searchable history. Per player, per staff member, or across the whole server, with filters by type and status.
• Evidence on the record. Attach a proof URL when punishing, or afterwards, and require it for the punishments where you always want it.
• Reusable reasons. Templates hold a duration, a reason, and a broadcast. Ladders escalate them automatically for repeat offenders.
• Accountability. Staff profiles show what each moderator has issued, and one command can roll back everything a compromised or rogue account did in a time window.
• Network awareness. A punishment is global or scoped to one server ID, and the same database can back every server on a network.

On Paper and Folia, BlazeBans downloads the libraries it needs on first startup, such as database drivers, so that first start needs an internet connection. Velocity has no equivalent, so the Velocity jar carries everything with it and is noticeably larger.

There are four layers, and most confusion comes from mixing them up.

Commands are what staff type. Their names and aliases are configurable in settings.yml, so /ban can become /punishban without touching anything else.

Records are what gets stored. A record has a scope (global or a specific server ID) that decides which servers enforce it. See Servers and scope.

Enforcement is what happens to the player. Paper enforces on login and on chat; Velocity enforces at the proxy. A record with no matching scope on this server is still stored, just not applied here.

Presentation is everything the player and staff see: ban screens, broadcasts, menus, Discord embeds. All of it lives in config files and none of it is hard-coded.

A moderator sees someone using a movement cheat. They run:

/ban Steve 30d Movement Cheats

BlazeBans checks the moderator's permission, their duration limit, whether Steve is exempt, and whether their staff weight is at least Steve's. It stores a BAN record with a generated ID, the reason, the proof URL, and an expiry 30 days out. It removes Steve with the configured ban screen, broadcasts to staff, posts to Discord if that is enabled, and fires the API events other plugins listen for.

Steve's next login is denied by the same record until it expires or someone revokes it. /history Steve shows it. /blazebans profile Steve shows it beside his other records and his linked accounts.

None of those steps are optional add-ons. They are what one command does.