LuckPerms Donor Ranks: What Each Plugin Actually Checks

What a donor rank is once you leave LuckPerms

A donor rank is two things that server owners tend to treat as one. In LuckPerms it is a group: a bucket of players that inherits from default and holds a list of permission nodes. In every other plugin on the server it is nothing at all. A plugin never asks what rank someone is — it asks whether the player holds one particular node, and your group is what supplies the answer. So "setting up VIP" is really a sequence of small, per-plugin decisions about which node gets checked and what happens when the check passes.

That sequence is the part that is never written down in one place, and it is what this page collects. The eight plugins below each gate something behind a permission, and they do not gate it the same way or document it to the same depth. InfiniteShops publishes a node for nearly every perk it has. Advanced Crates and InfiniteCrates describe a reroll ladder in detail but leave the node names to your configuration. AntiAFKPlus names a bypass node — and its product record and its on-site documentation spell that node differently, which is worth knowing before you paste it into a LuckPerms command.

One thing this page is not about: showing the rank. Granting a perk and rendering a prefix in chat are separate jobs, and the second one belongs to a chat formatter reading the LuckPerms prefix you already set. LuckPerms chat formatting with LPC covers that side. Everything below is about what the rank unlocks.

Which plugins gate what, and which ones name the node

Read the third column first, because it decides how you work. Where a record or its documentation spells out node names, you can write the LuckPerms commands before the server has ever started. Where it does not, the tier still exists — you define it inside that plugin's own configuration, and the node is whatever you called it there. Neither model is a defect, and both are common. Mixing them up is how a rank ends up half-wired: paid for, advertised, and silently inert in whichever plugins you assumed would publish their own node names.

InfiniteShops: the ladder that is actually written down

InfiniteShops treats ranks as a feature rather than a gate, which is why it is the plugin to wire first. The record lists permission-based price perks — "cheaper buy prices, better sell prices, or both, per rank or permission group" — next to tiered taxes and per-player multipliers, and states that all permission nodes are customizable in permissions.yml. The published node list is long: infiniteshops.editor, .blackmarket.*, .dailyshop.* with .vip, .vip_plus, .mvp and .mvp++ tiers, .transactionlog.admin, .npc, .sign with .bypass, .frame, .multipliers, .rank.self and .rank.other, .features.toggle, .convert, .sell.hand and .sell.all, .player.shop, .admin.shop and .admin.enchant. Two of those — .sell.hand/.sell.all and the .dailyshop.mvp++ tier — appear in the record but not in the on-site permissions reference, so confirm them against the plugin before you grant them.

The on-site InfiniteShops permissions reference goes further and gives a default for each node, which is the detail that saves an evening: infiniteshops.use, .shop.use, .shop.buy and .shop.sell default to true for everyone, while the rank perks default to false and only exist once you grant them. The perks a donor would actually pay for live in three separate subsystems, each with its own node family. The multipliers page documents permission-based multipliers under infiniteshops.multiplier.vip, .multiplier.vipplus and .multiplier.mvp. The taxes and discounts page documents tax reductions under infiniteshops.tax.vip, .tax.mvp and .tax.bypass, plus flat discounts under infiniteshops.discount.vip and .discount.mvp. The Daily Shop page documents purchase-limit multipliers under infiniteshops.dailyshop.vip, .dailyshop.vip_plus and .dailyshop.mvp, with infiniteshops.dailyshop.bypass.limit as the escape hatch.

Notice the spelling drift between those families. The multipliers page writes the second tier as .multiplier.vipplus, with no separator; the Daily Shop page writes the same tier as .dailyshop.vip_plus, with an underscore. Each is correct in its own subsystem, so copy each node from the page that documents it rather than typing it from memory. Neither source says what happens when a node does not match, so do not assume you will be told. Copy each node from the page you are configuring rather than from the last one you configured.

One more distinction worth keeping straight: Shopper Ranks are not donor ranks. They are earned, not bought — players "earn points through purchases and climb configurable rank tiers — unlocking permanent sell multipliers, random rewards, percentage discounts, and tax reduction" — and the permission nodes attached to them, .rank.self and .rank.other, are about viewing progress rather than granting it. The two ladders sit on top of each other happily. If the shop itself is not built yet, setting up server shops with InfiniteShops is the place to start, and the economy and shops hub lists the rest of that category.

Setting up a VIP group, node by node

The InfiniteShops documentation ships a worked LuckPerms example, and its shape is a reasonable template for the whole server: give the default group the everyday nodes, make the donor group inherit from default, then add nothing but the perks on top. The commands below are the ones printed on that permissions page; the order is what keeps a ladder maintainable once you have three tiers instead of one.

• 1. Give default what everyone gets — Run /lp group default permission set infiniteshops.use true, then the same for .shop.use, .shop.buy, .shop.sell, .blackmarket.use and .dailyshop.use.
• 2. Inherit rather than duplicate — Run /lp group vip parent add default so VIP starts with everything default holds, and every later change to default reaches VIP for free.
• 3. Add only the paid perks — Run /lp group vip permission set infiniteshops.dailyshop.vip true, then infiniteshops.multiplier.vip and infiniteshops.tax.vip — the three nodes the example treats as the VIP package.
• 4. Repeat per plugin, not per rank — Work through the table above one plugin at a time; for the plugins that publish no node names, define the tier in that plugin's own configuration first, then grant the name you chose.
• 5. Keep staff in a separate group — Admin access is not the top donor tier: /lp group admin permission set infiniteshops.* true, and the same separation for specializedcrates.admin and infinitecrops.limit.admin.

The crate plugins: reroll ladders you have to name yourself

Advanced Crates and InfiniteCrates build donor value out of the same mechanic, and it is one the player meets on every crate opening rather than once at purchase. Advanced Crates states it plainly: "rerolls are granted by permission, and a ladder of permissions gives some ranks more rerolls than others". Only players holding a reroll permission see the option at all, and each permission grants its own number of rerolls, "so donor ranks can reroll more often". InfiniteCrates describes the same shape — "permission-based rerolls, with ladders that give some ranks more rerolls than others" — as part of its reward configuration.

What neither record does is name the nodes, and that is not a gap you can close by guessing. Neither record names the reroll nodes themselves. Check the plugin's own documentation before writing the LuckPerms commands, because this page cannot tell you what to type. Advanced Crates adds one detail that matters for conversion rather than configuration: players without the next tier see a configurable message — the record calls it no-permission lore — explaining how to unlock it, so the ladder can advertise itself inside the crate menu instead of only on a store page.

SpecializedCrates is the odd one out, and it is worth saying so plainly rather than implying a feature it does not claim: its record describes no reroll system at all. What it does publish is the staff side. Everything runs under /scrates, with specializedcrates.admin covering all of it and per-command nodes for narrower roles — specializedcrates.config, .give, .history, .listcrates, .info, .luckychestcommand, .virtualcrates, .claim, and .virtualkeys with .other and .send. Its one rank-aware behaviour is a reward fallback rather than a permission tier: a rank reward a player already owns falls back to something else instead of being wasted, which is the kind of thing that stops a donor opening a crate and winning the rank they already bought. If you are still choosing between the three, choosing a Minecraft crates plugin compares them on everything else, and the crates hub lists the category.

Limits, gear and menus: InfiniteCrops, InfiniteFishing and GUIPlus

InfiniteCrops uses permissions for a job the others do not: throttling. Its placement and shop limits "cap crops, bushes or sprinklers per player with permission tiers (e.g. VIP 50, default 20) and cap shop purchases", managed with /ic limit create, remove and info. That VIP 50 against default 20 is an example in the record rather than a shipped default, so treat it as a sketch of the shape rather than a value to copy. All InfiniteCrops permission nodes are configurable in permissions.yml, and the published list covers admin and command access — infinitecrops.<item>.give, .crop.create, .crop.edit, .crop.delete, .greenhouse.remove, .market.open, .market.toggle, .market.sellall, .season.change, .season.skip, .hologram.create, .hologram.move, .hologram.delete, .limit.admin, .reload and .schematic — rather than the limit tiers themselves.

InfiniteFishing gates gear instead of allowances. Rods "can carry their own durability and permission requirements", and the record's line on the tier is exact: assign permission nodes so specific rods need a rank to use. Nothing in the record names those nodes, so as with the crate ladders they are yours to define per rod. That makes a fishing donor tier read as better equipment rather than a bigger number, which is a different kind of upsell to the ones above it. The fishing plugin setup guide covers the rest of that plugin.

GUIPlus is where a rank becomes visible to the player who does not have it yet. Its conditions system gates any item or scene, and the first player check in the list is has permission, alongside has items, level and XP amount; every condition-able element carries its own fail message, so a locked button can explain what unlocks it instead of doing nothing. The record stops there, but the on-site documentation goes further. The conditions page shows the has-permission condition taking a single node, and the commands and permissions page documents a per-GUI permission field set in the menu's own YAML — with it set, players without that node cannot view the GUI at all. For a donor menu that is the cleaner of the two: one field on the menu, rather than a condition maintained on every item inside it. That page also lists the plugin's command nodes, from guiplus.gui through guiplus.gui.edit and guiplus.gui.open.others.

Staff exemptions, and one node spelled two ways

AntiAFKPlus is free, and it is where donor ranks and staff exemptions overlap. Detection thresholds are per-rank and config-driven — the record's own example is "5 minutes for guests, 30 for donors, unlimited for staff" — and every consequence is permission-gated, with each AFK action being its own config entry carrying its own permission node. In practice that means an AFK policy is a ladder like any other perk: shorter for the people who cost you a slot, longer for the people who paid for one.

Then there is the bypass node, and this is the one place on this page where our two sources disagree about a node you are told to grant. The product record says the node is antiafkplus.bypass, and repeats it in the FAQ answer about staff being kicked mid-build. The on-site documentation, imported from the plugin's wiki, says antiafk.bypass — on both the AFK detection page and the FAQ — and names antiafk.admin for the in-game admin GUI. We are not going to pick one for you: grant the record's spelling, and if the player is still being detected, grant the documentation's. The documentation also offers a route that sidesteps the question entirely, because it does not use a node at all — set timeout: -1 for a LuckPerms group in config.yml, or run /antiafk exempt on a player, which the documentation describes as either a temporary or a permanent exemption.

Two closing notes that are per-plugin rather than catalogue-wide, because treating them as catalogue-wide is how a rank breaks on the second server. AntiAFKPlus is the only plugin on this page whose record claims Folia support — it detects Folia at start-up and switches to region-aware scheduling, with nothing to configure. And the Minecraft ranges in the table genuinely differ: AntiAFKPlus runs on 1.7-26.2 while InfiniteCrates starts at 1.20.6-26.2, so a ladder wired on one network is not automatically portable to another. Minecraft version support has every range in the catalogue, and what each plugin requires has the dependencies you will hit on the way.