Running keys

Moderation

Two tools for keeping a drop under control: bans, which stop someone claiming, and grants, which let a moderator hand a key to a specific person or to a whole role.

Bans

A ban stops a member claiming keys. There are two scopes, and they behave differently:

Scope	Effect
Server-wide	The member cannot claim from any pool in the server, now or in future. This is checked first, before the pool is even looked up.
Pool	The member cannot claim from that one pool. Every other pool in the server is unaffected.

Bans are recorded against the member's Discord account, so leaving and rejoining the server does not clear one. Banning someone already banned, or unbanning someone who is not, changes nothing and simply tells you so.

Bans block claiming, not grantingA ban is a check on /claim. It does not prevent a moderator from granting that member a key with /grant or from including them in a /grantrole sweep. If someone must not receive keys at all, do not grant to them, and be careful with a bulk grant to a role they hold.

Deleting a pool also deletes the bans scoped to it. Server-wide bans are unaffected by pool deletion.

Moderator roles

Each pool carries its own list of moderator roles. They control exactly one thing: who may run /grant on that pool. The rules:

The caller must hold every role in the list, not just one of them.
A pool with no moderator roles cannot be granted from at all. /grant refuses with "No mod roles set for this pool."
Moderator roles are independent of Discord permissions. Someone with a moderator role but without Manage Server can grant from that pool and nothing else.

That separation is the point. A partner running a stream giveaway, or a community manager handling support requests, can be given the ability to hand out keys from one pool without being given control of your server.

Granting a key to one member

/grant user:@member pool:name takes a key from the pool and sends it to that member by direct message. You get an ephemeral confirmation telling you whether it arrived.

Access is by the pool's moderator roles, not by Manage Server.
The pool's keys-per-user limit still applies. Granting to a member who has already reached it is refused.
Private pools can be granted from. Visibility only affects self-claiming.
If the member has direct messages from server members turned off, you are told the message could not be delivered. The key is still consumed. Ask them to open their DMs and grant again from the remaining stock.

Granting to everyone with a role

/grantrole role:@role pool:name gives one key to every member holding that role. It requires Manage Server. Before anything is spent, KeyBot shows how many members hold the role and how many unclaimed keys the pool has, and waits for you to confirm.

When it finishes you get a tally:

Line	Meaning
Granted	Members who were issued a key.
Failed DM	The key was claimed for them but the direct message could not be delivered, usually because their DMs are closed. These keys are spent.
No Keys Left	The pool ran out partway through and these members got nothing.
Failed	An error occurred for that member. The run continues rather than aborting.

A bulk grant ignores the per-member limitUnlike /claim and /grant, /grantrole does not check how many keys a member has already claimed from the pool. Everyone holding the role receives a key, including people who claimed one earlier. Run it against a role you control, and check the member count on the confirmation screen before saying yes.

After a bulk grant, KeyBot re-checks the pool's stock and posts a low-stock or empty warning if the sweep drained it. The run is also recorded in your log channel.

NextDashboard →