Hierarchy and exemptions

Every account has a weight from 0 to 1000. A staff member can punish someone only when their own weight is at or above the target's.

With LuckPerms

staff-hierarchy:
  group-weights:
    helper: 10
    moderator: 50
    admin: 100
    owner: 1000

BlazeBans reads each player's primary and inherited groups from LuckPerms and uses their highest matching weight. Group names are matched case-insensitively.

A player in no listed group has weight 0, which is why ordinary players can be punished by anyone.

This is the recommended setup. It is one place to maintain, and it follows your existing group structure automatically as people are promoted.

Without LuckPerms

Grant blazebans.weight.<number>:

blazebans.weight.10
blazebans.weight.50
blazebans.weight.100

Any value from 0 to 1000. The highest node found on an account wins, and it also wins against a group weight, so the two can coexist.

What it produces

With the weights above:

Equal weights can punish each other, deliberately. Two moderators of the same rank should be able to deal with each other's accounts if one is compromised.

To stop that, give each rank a distinct weight and put staff one step apart.

exempt:
  luckperms-groups:
    - "admin"
    - "owner"

Members of these groups cannot be punished by any player, regardless of who is trying.

This is stronger than weight. Weight lets a higher-ranked staff member act; a group exemption stops everyone.

Console bypasses it.

Leave this list empty if you want an owner to be able to ban a rogue admin. Use it when you want a rank that is untouchable in game and can only be dealt with from console.

exempt:
  players:
    - "ServerOwner"
    - "BuildTeamLead"

The strongest of the three. These names cannot be punished by anything, including console.

This is the only exemption console respects, which makes it the way to protect an account absolutely.

Use it for the owner account and for anything whose removal would break the server. Keep the list short, and remember that a name here is a name, not a UUID: if the account changes name, update the list.

punishments:
  prevent-self-punishment: true

On by default. Stops staff punishing their own account.

Mostly this catches typos rather than intent, which is reason enough to leave it on.

Separate from all of the above:

These are per-punishment-type, so you can make someone unbannable while leaving mutes available. Useful for a build team account that must stay online but should still be quietable if something goes wrong.

When a player runs a punishment command, in order:

1. Do they hold the command permission?
2. Is the target themselves, with self-punishment prevention on?
3. Is the target in exempt.players?
4. Is the target in an exempt LuckPerms group?
5. Does the target hold the matching blazebans.bypass.* node?
6. Is the issuer's weight at or above the target's?
7. Is the duration within the issuer's tier?
8. Does the issuer hold the scope permission?

The first failure stops the command with a message explaining which check it was.

blazebans.admin bypasses steps 4, 6, and 8. Console bypasses everything except step 3.

Small server, trusted staff. Weights only. Set group-weights to match your ranks and leave the exemption lists empty. Anyone senior can deal with anyone junior.

Larger team. Weights, plus exempt.players for the owner account. Leave luckperms-groups empty so senior staff can still act on a compromised admin account.

Formal structure. Weights, exempt.players for the owner, and exempt.luckperms-groups for administrators. Admin accounts can then only be dealt with from console, which means it takes server access rather than a permission.

The tradeoff is always the same: stronger protection means a compromised senior account is harder to stop. Weight-based hierarchy handles that well and is the right default for most servers.

"Target is exempt." They are in exempt.players, in an exempt group, or hold a blazebans.bypass.* node.

A weight refusal. The target outranks the issuer. Check both accounts' groups in LuckPerms, and check for a stray blazebans.weight.* node inherited from a parent group.

A duration refusal. The issuer's tier caps them below the requested length. See Duration limits.

A scope refusal. The issuer lacks blazebans.scope.global or the node for the named server. See Servers and scope.

When a check is behaving unexpectedly, run the command from console. If it works there, it is one of steps 4 through 8; if it does not, the target is in exempt.players.