Most guild loot systems eventually arrive at the same uncomfortable moment: one member quietly queues up dozens of requests for the next month while everyone else is still figuring out what they want. The officers see the queue, the queue feels unfair, and someone has to either reject perfectly valid requests or let the rest of the guild lose faith in the system.
A single weekly cap doesn't fix this. A single pending cap doesn't either. You actually need both, working together. That's what Raidium's request queue does.
Why one limit is never enough
If you cap pending requests only, a member can submit, get fulfilled, submit again, get fulfilled again — the cap never bites because the pool drains. They consume the entire guild's weekly throughput while the cap dutifully reads zero.
If you cap weekly fulfilled only, members race to submit on Monday morning. The pending pool balloons, officers can't tell who's reasonable and who's gaming the system, and the queue stops being a queue and starts being a backlog.
The trick is to count both at once. Raidium's validation does this in one expression:
Weekly usage = pending requests (any week) + fulfilled requests (this week)
That single number is what gets compared to the per-category limit. The pending side stops anyone from sitting on a pile of unprocessed requests. The fulfilled side stops anyone from cycling through fulfillments faster than the rest of the guild.
The three categories, each with their own cap
Requests are split into three categories, each with an independent limit configurable per guild:
- Item Log — default cap of 10 items per week. The general-purpose category for boss drops and most rewards.
- Accessories — default cap of 5 items per week. Tighter limit because accessory drops are typically rarer and more valuable.
- Upgrade Consumables — default cap of 20 items per week. Looser limit because consumables move in volume.
Limits are per category, not pooled. A member maxing out their accessories cap doesn't affect their item log allowance. This matters because guild economies almost never have a uniform scarcity curve — a one-cap-fits-all approach forces officers to either set the cap too high (which fails for accessories) or too low (which strangles consumables).
The whole system can be toggled off at the top level, or any single category can be disabled if your guild doesn't use it. Disabling a category blocks new requests in that category while leaving existing ones intact for cleanup.
What "weekly" actually means
The week boundary isn't UTC midnight on Monday. It's whatever your guild configures: a day of week, an hour, a minute, and a timezone. A guild that raids on Sunday nights in AEST might want their week to roll over Sunday at 23:59 Sydney time so members get a fresh allowance before the raid week starts. A US guild might prefer Monday 06:00 EST.
The boundary affects two things: when fulfilled-this-week resets, and when the new allowance becomes available. It does not retroactively reclassify already-fulfilled requests — once a request is in last week's bucket, it stays there.
Cancellation, the grace period, and the refund question
Members can cancel pending requests. Whether the items count back toward their allowance depends on a single per-guild setting: the cancellation grace period, configurable from 0 to 24 hours.
- Cancel within the grace period → items refunded. The cancelled request no longer counts against your weekly usage.
- Cancel after the grace period → items not refunded. The cancellation goes through, but you've already burned that allowance.
The rationale: a one-hour default protects honest mistakes (wrong item, fat-fingered quantity) without giving anyone a 24-hour escape hatch on every request they submit. Set it longer if your guild prefers leniency, or zero if you want every submission to be final.
Rejection works differently. If an officer rejects a request, the items are always refunded — rejection is not the member's fault and shouldn't penalize their cap.
Partial fulfillment
Real loot drops aren't all-or-nothing. A member might request three of an item and the guild only has one available. Raidium handles this at the item level: an officer can fulfill a subset of the requested items and leave the rest as still-pending or rejected, without forcing the entire request through one of those buckets.
This matters for the dual-limit math because partial fulfillment lets the queue keep moving without forcing anyone into a full reject + resubmit cycle, which would otherwise cost the member an entire round-trip through the pending limit.
How this plays out in practice
A worked example. Imagine the Accessories category with a cap of 5 per week, no grace period.
- Monday: member submits 3 accessory requests. Pending: 3. Fulfilled this week: 0. Weekly usage: 3.
- Wednesday: officer fulfills 2 of those. Pending: 1. Fulfilled: 2. Weekly usage: 3. (The math holds — the items moved buckets.)
- Thursday: member tries to submit 3 more. New weekly usage would be 1 (pending) + 2 (fulfilled) + 3 (new) = 6. Over the cap of 5. Blocked.
- Member submits 2 instead. Now: pending 3, fulfilled 2, weekly usage 5. At cap.
- Sunday rollover: fulfilled-this-week resets to 0. Pending stays at 3. Weekly usage: 3. Member can submit 2 more.
This is the behaviour officers can defend in chat: nobody got blocked because a single number was arbitrary. They got blocked because the combined picture of "what you're sitting on plus what you've already taken this week" hit the cap.
What this replaces
If you've run guild loot through a spreadsheet, a pinned Discord message, or a Discord bot with a single counter, you've probably encountered every failure mode this design exists to fix. The dual limit isn't an arbitrary feature; it's the smallest set of constraints that produces a queue you can actually trust.
For existing Raidium guilds, the request settings live under your admin panel — adjust the per-category caps to match your actual loot economy, set the grace period to match how forgiving you want to be, and pick a week boundary that aligns with your raid schedule. New guilds get sensible defaults out of the box.
Request queue not currently visible in your guild? Make sure the system is enabled in Admin → Request Settings and at least one category is turned on.