GDD: Guild

Overview

A Guild is a persistent, named group a player belongs to. One player, one guild. It is the game's first many-to-many social unit — everything social we ship today is either a pair (friends + Bond) or a duo (party). The Guild is the layer where a player belongs to a place rather than to a person, and where they can be missed when they stop showing up.

The goal metric is D7–D30 retention through social anchoring: give a player a reason to open the app that is not the core loop, and a set of people who notice their absence.

Guilds are an industry staple: every benchmark in the research corpus ships one, and this feature is built as a baseline expectation of the genre, not as an experiment. There is no A/B rollout, no holdout cohort and no experimental gating anywhere in this document — the feature ships to everyone, and its adoption and retention are read from standard product analytics the same way as any other feature's.

Evidence base: reports/guild-research-2026-07-22.md and reports/guild-research-addendum-2026-07-22.md. The second one carries the benchmark teardowns (Legend of Mushroom — where the guild is called a Family — plus Clash of Clans, AFK Arena, Idle Heroes, SWGoH and six others) and the guild-lifecycle base rates cited throughout this document.

The central design problem

Every guild mechanic in the benchmark corpus assumes contribution is an active player choice: which squad you send, how well you played, which energy you spent. Lootborn's combat is server-authoritative and automatic — the player has no input during a fight. Imported naively, "contribution" collapses into power × time online.

The design's answer is to copy shapes, not invent counter-devices, and the split runs down the middle of the feature. The cooperative daily layer — donations, member help, the guild boss — takes Legend of Mushroom's mechanics as shipped, and those mechanics happen to be capped and participation-shaped: a first-free donation ladder with flat experience, help paid only for the first few per day, boss chests granted to everyone equally at level thresholds. The competitive seasonal layer — clan points — is deliberately left open to spend: bigger and paying guilds are expected to dominate the ladder, as they do every other competitive surface of the game. Cooperation is capped because the benchmark caps it; competition is open because that is the monetization design.

Relationship to existing social systems

The Guild must not re-implement what exists. It composes with it:

Layer	System	What it gives
Pair	Friends + Bond	Long-horizon 1:1 loyalty, gifts, combat bonus in party
Duo	Party	A build axis — the partner's class and skills
Group	Guild	Belonging, a shared score, a place to be missed from

(A suzerain / vassal system appears in earlier design materials but is not part of the live game experience; this document treats it as nonexistent.)

Concretely: the Guild does not get its own gift system (friends have one), its own 1:1 chat (private channels exist), or its own power-bonus pairing (Bond and party own that). It gets a roster, a chat channel, a shared progression bar, and shared content.

Mechanics

The producer's specification is the baseline; the guild boss, the guild economy, the Guild Showdown and the Guild War are designed in §15–§18. Everything ships together — the increment sequencing of earlier drafts was dropped by decision, and ## Scope describes a single release.

---

1. The guild entity

A guild has:

• Emblem — chosen from a pre-authored set. Deliberately not player-uploaded: no image moderation pipeline, no NSFW risk, and emblems stay legible at the small sizes they render at.
• Name — unique, scoped per realm, not globally. Realms segment by language and timezone and each has its own database, so a global namespace would let a guild on one realm block a name on another it can never meet, and would require a central reservation registry for no player-visible benefit. The benchmark precedent points the same way: Clash of Clans does not rely on the name as the identity key at all — clans are identified by a Clan Tag, with direct lookup by tag as a first-class search path, and Lootborn Warriors shows a copyable numeric Guild ID right on the guild card.
• Guild tag — a short, globally unique handle rendered next to the name. Required, because realm merges are planned. It is what makes realm-scoped names safe: support, analytics and any future cross-realm event reference the tag, and a merge cannot produce an ambiguous guild. Global uniqueness must come from the tag's construction, not from hashing an identifier — a short tag truncated from a UUID collides, and realm databases are independent so nothing would catch the collision. The tag therefore carries a realm component plus a value unique within that realm, which each realm can allocate on its own with no cross-realm registry and no coordination. Uniqueness then holds by construction, including across a merge, because two realms can never mint the same realm component.
• Description — free text, player-authored.
• Leader — exactly one, always present while the guild has members.
• Level and experience — driven by member donations.
• Member count — current and maximum; the maximum is a function of guild level.
• Member list — each entry carries rank, level, and last-online time.
• Required player level — optional join gate set by the leader.
• Join type — automatic, or by application.

Merge collision policy. Because merges are planned, two guilds with the same name will eventually land in the same realm, and the design has to say what happens rather than discovering it in an incident. The rule: the older guild keeps the name; the other is suffixed automatically and granted a free rename that bypasses the rename cooldown, with a mail explaining why. Age is the right tiebreaker because it is objective, not gameable, and not correlated with spend.

Two further merge consequences: merges must land at a season boundary, so clan points and the seasonal ladder do not have to be reconciled mid-season, and a merge instantly doubles guild supply while leaving both realms' member caps untouched — which is exactly when the dead-guild recycling in §12 has to already exist.

Guild information is public: any player can inspect any guild, whether or not they are in one. This matters for recruitment — a player deciding where to apply needs to see what they are applying to.

2. Membership states

There are exactly two membership states — not in a guild and in a guild — and everything else is a flag that can coexist with the others. A player without a guild may simultaneously hold incoming invites and several outgoing applications; these are not alternative states and the UI must not present them as such.

• Not in a guild. Independently, they may have: zero or more incoming invites, and zero or more outgoing applications.
• In a guild. Invites and applications cannot exist in this state — joining resolves all of them (below).

Accepting an invite, or an application being accepted, resolves all of a player's other pending applications and invites — they are dropped, and the guilds that were holding them see them disappear from their queues.

3. Discovery and joining

Recommended list. A player without a guild can request a list of recommended guilds. The producer spec defines this as a random selection of active guilds; "active" needs a definition, and the one this document proposes is at least one member online in the last 72 hours. By decision, the list is sorted by seasonal rating (clan points, descending; ties broken by guild level, then by guild age), not randomly sampled — the browse list doubles as a shop window for the ladder, and a newcomer lands on the guilds that are actually alive at the top.

Unavailable guilds stay visible. A guild the player cannot join right now — full, or above their level requirement — still renders in its rating position, with the action disabled and the reason on it ("Full", "Lv 20+"). Hiding them would misrepresent the realm's guild landscape; showing them sets a goal. Only Dormant and Retired guilds are excluded (§12) — they cannot receive applications at all. If the list is empty, the screen leads with "Create guild" instead of an empty state.

Each row shows: emblem, name, guild level, season rating, members (current / max), required player level, join type, and whether this player already has an open application to it.

Search is by exact name or exact guild tag, no partial matching. The tag, not an internal identifier — the tag is the handle a player can actually read off a friend's profile and retype. This is a deliberate simplification: exact search exists to let a player join the specific guild a friend told them about. Browsing is what the recommended list is for.

Joining takes one of two paths:

1. Automatic — if the guild has auto-join enabled, the player joins immediately. Checks first: not already in a guild, guild not full, player meets the level requirement.
2. Application — if auto-join is off, the player sends an application. Duplicate applications from the same player are rejected. The leader accepts or declines; the same checks run again at accept time, because the guild may have filled up in the meantime.

There is deliberately no shareable invite link: joining goes through the list, exact search, or a direct invite — nothing that can leak into a public channel and pump auto-join guilds from outside.

Invites. A leader can invite a player who is not in a guild. A player may hold several invites; each shows the guild's data and who sent it. Accepting runs the standard checks; an invite cannot be accepted by a player who has since joined a guild elsewhere.

Join incentive. A player who joins their first guild receives a one-time reward. This is the single sourced piece of onboarding guidance in the corpus — discovery and a join incentive ship with the feature, not as follow-up polish.

4. Creating a guild

Available to a player not currently in a guild and not under the post-leave cooldown — creating is not a way around it. Requires a name, a description, an emblem, and a hard-currency payment. The creator becomes the leader.

The cost exists to suppress vanity guilds: on a realm-bounded population, a hundred one-person guilds is worse than ten full ones, because guild supply is what the leaderboards and the Showdown consume.

Name and description are player-authored text and go through the same moderation pipeline as SetUsername, plus a rename cooldown.

5. Roles and permissions

Four ranks: leader, deputy, guard, no rank. Ranks carry real permissions from V1 — they are not decorative. Assigning ranks stays leader-only, deliberately: it is the one power that changes the power structure itself.

The matrix is cumulative — each rank has everything below it, plus its own additions:

This table is the single source of truth for permissions. The UX and the tech spec below derive from it; where anything disagrees with this table, this table wins.

Power	No rank	Guard	Deputy	Leader
Donate, chat, take part in guild content, leave	✓	✓	✓	✓
Accept / decline applications		✓	✓	✓
Invite players		✓	✓	✓
Kick unranked members		✓	✓	✓
Kick guards			✓	✓
Edit join settings — auto-join, minimum level			✓	✓
Edit the description			✓	✓
Mute a member in guild chat			✓	✓
Assign and remove ranks				✓
Rename the guild, change the emblem				✓
Transfer leadership, disband				✓

Read it as two jobs: guard is the recruitment rung, deputy is the operations rung. Note what deliberately stays leader-only: anything that changes the guild's identity (name, emblem) or its power structure (ranks, leadership, disband).

Four rules make this safe rather than a griefing surface:

• Nobody acts on an equal or higher rank. A guard cannot kick a guard, a deputy cannot kick a deputy. Only the leader can act on a deputy.
• Kicks below the leader are rate-limited. Clash of Clans caps its second rung at one kick per 20 minutes; the same guard stops a compromised or disgruntled officer emptying a roster in a minute.
• Rank slots are limited and scale with guild level. AFK Arena does exactly this — deputy and officer counts grow with the guild's level. It bounds the blast radius, makes a rank feel earned, and gives guild level a second consequence beyond the member cap.
• Every privileged action is written to the event log — kicks, rank changes, and settings changes alike. A permission with no audit trail is how a guild loses trust in its own leadership.

The reason recruitment specifically must sit below the leader is a liveness problem, not a feature request. In the spec as written, the leader is the only person who can admit anyone. A leader who stops playing on a Monday leaves a guild unable to recruit until the 7-day succession rule fires on the following Monday — and a guild that cannot admit anyone for a week on a realm-bounded population is a guild that is quietly dying while looking alive. Recruitment is the one power whose absence is actively harmful.

Every benchmark that documents its permissions delegates recruitment below the leader. Clash of Clans grants "accept join requests" and "invite" to its second rung (Elder) — the same rung that cannot promote, cannot edit settings, and cannot even message the clan — with kicks rate-limited to one per 20 minutes as the abuse guard. Idle Heroes gives its Officials the same admin surface as the Guild Master. Puzzles & Survival puts "accept join requests" at R4, one rung below the R5 leader. Nobody ships a single-recruiter guild.

No guild-vs-guild power sits on any rung, and that is the design. Nothing in the shared-content layer is opt-in, assigned or scheduled by a person: the boss is always live and has nothing to start (§15), Showdown pairing is automatic and has nothing to sign up for (§17), and war defenders are selected automatically from the roster (§18). Every one of those would otherwise be a button whose owner can go quiet on a Wednesday and cost the guild its Sunday — the same liveness argument that pushes recruitment down to the guard rung, taken to its conclusion. A permission that exists only to be pressed on time is a failure mode with a UI.

6. Leader succession

Leadership transfers when the leader leaves the guild, or has been inactive for more than 7 days. A guild with members always has a leader.

The succession order must be fully deterministic, because it runs unattended and two guilds in the same state must resolve the same way:

1. The longest-tenured active deputy. Rank first, then tenure in the guild — not power, not level, and not donation volume, none of which should decide who inherits authority.
2. Failing that, the longest-tenured active guard.
3. Failing that, the member with the most days online in the last 7, ties broken by longest tenure, then by the lower character identifier as a final deterministic tiebreak.
4. If no member has been online in the succession window at all, the guild is dormant, not leaderless-by-accident — it enters the dormancy path in §12 rather than promoting an absent player.

"Active" here means online within the succession window, and it is the same threshold everywhere it appears — one config knob, not several.

The former leader keeps their membership and is demoted to deputy, not kicked. They lapsed; they did not resign. Demoting rather than removing means a returning founder finds their guild intact and can be handed the role back, which is a much better outcome than discovering they were ejected from something they built. If the deputy slots are full, the demotion cascades down — to guard, and to no rank if the guard slots are full too: the former leader lands in the highest rank with a free slot, displacing nobody and never overflowing a slot count. A voluntary leadership transfer resolves the outgoing leader's rank through the same cascade.

Both the outgoing and incoming leader are mailed, and the transfer is written to the event log.

This is the only inactivity rule in the producer spec, and it covers only the leader. Section 12 covers the rest.

Benchmark calibration. 7 days is at the aggressive end, which is defensible for a realm-bounded population but should come with a warning ladder rather than a silent flip. Clash of Clans runs the most fully specified rotation in the market: at 60 days offline the whole clan is warned, at 74 the leader is notified, at 83 both are notified again, and only at 90 does the longest-serving active Co-Leader inherit — logging in at any point cancels it. Idle Heroes is far tighter: an inactive leader loses the role at 20 days, and an active member is auto-promoted to officer at 7. The principle worth taking from Clash is not the timescale but the visible countdown: succession that announces itself lets the guild solve the problem socially before the system solves it mechanically.

One structural rule to carry over: Clash never auto-promotes an unranked member to leader — if no ranked candidate exists, rotation simply does not fire. Our spec's fallback to "most active member of the last 7 days" is the more forgiving choice and is right for our population size, but it means a guild can hand leadership to someone who never asked for it. The inheriting player must be told clearly, not silently handed a settings tab.

7. Member management

Who may do what is the §5 matrix, not a second list here. Restated only to show where the work lands in practice:

• Guard and above — accept or decline applications, invite a player who is not in a guild, kick unranked members.
• Deputy and above — additionally kick guards, and mute a member in guild chat.
• Leader only — change a member's rank.

Every one of these is bounded by the rank-relative rule (never act on an equal or higher rank) and by the kick rate limit.

Any member can leave voluntarily. Kicks, departures and rank changes are written to the event log.

Leaving and being kicked are not the same event and must not share a cooldown. One is a choice, the other is done to you, and a single rule covering both is either useless or weaponisable.

• Voluntary leave → a global cooldown of 60 minutes before joining — or creating — any guild. Deliberately short, by decision. An hour is enough to make leaving a considered act rather than a mis-tap, and to stop a player cycling through five guilds in one session; it is not enough to strand anyone. The player is told the length in the leave confirmation, before they commit.

Naming what this hour does not do matters, because the earlier draft leaned on it too heavily: it is not the anti-hopping device. Hopping is stopped where the reward is, not at the door — Showdown points earned while guildless are void, switching mid-week forfeits the day and clears the player's points from the old tally, each reward tier pays once per account, war joiners spectate the round, and the donation cap counts per player per day across guild changes. Every one of those holds regardless of how long the cooldown is. A long lockout would add nothing to them except punishing the ordinary player who joined the wrong guild. - Being kicked → no global cooldown at all, only a cooldown on reapplying to that guild. A global lockout here would hand any guard a button that removes a player from the entire feature for a day, which is a griefing tool, not a brake. The per-guild cooldown exists for a different reason: to stop a rejected or removed player re-applying in a loop and turning the application queue into a nuisance. It is therefore longer than the leave cooldown — a day is the suggested default — and that asymmetry is not a harsher punishment: it blocks exactly one guild, the one that removed them, while every other guild on the realm stays open immediately.

A player who is kicked can therefore join a different guild immediately — which is the correct outcome, because the feature's goal is that they are in a guild, not that they are punished for someone else's decision.

A membership that ends because the guild was disbanded or retired carries no cooldown of any kind — the player chose nothing, and there is no guild left for a per-guild cooldown to point at.

8. Guild settings

Per the §5 matrix, the deputy and above can toggle auto-join, set a minimum player level for entry, and edit the description. Renaming the guild, changing its emblem, transferring leadership and disbanding stay with the leader.

9. Event log

The guild keeps a chronological log of joins, kicks, and voluntary departures. It is the roster's memory: it is what lets a returning member see that the guild is alive, and what lets a leader see churn.

Extension beyond the producer spec: the log should also carry rank changes and guild level-ups. Rank changes because they are the one leader action with no other trace, and level-ups because they are the guild's shared achievements and the log is where a member who was offline finds out about them.

10. Guild chat

Not in the producer spec, and required. The chat system already specifies a Clan channel: a player is auto-joined on entering a guild and removed on leaving, everyone can read, and write permission is on by default but can be revoked per member. The chat design assigns that to the guild head; we widen it to deputy and above, per §5, for the same liveness reason as recruitment — a moderation power only the leader holds is a moderation power that lapses when the leader does.

Donations and an event log do not create social attachment. A channel where people talk does. Shipping the roster without the chat ships the bookkeeping of a guild without the guild.

Assume most members never post — no evidence was retrievable on guild chat posting rates — and design so non-posters still get value from every other part of the feature.

11. Donations, guild experience and guild level

Each member may donate up to 5 times per day. The first donation of the day is free; each subsequent one costs hard currency, with the price rising per donation within the day. Every donation grants the same amount of guild experience and gives the donor a personal reward. Guild level raises the member cap; surplus experience carries into the next level.

Three properties of this design are worth naming because they are doing real work:

• Flat experience per donation decouples guild progress from spend within the day's five slots — a whale's fifth donation moves the guild exactly as far as an F2P player's first. The whale still contributes 5× the F2P player who donates once, but the ceiling is the same for everyone, and that ceiling is the anti-stacking device.
• The free first donation is the daily hook. It is a one-tap action that costs nothing, contributes visibly, and is the reason a lapsing player opens the guild tab.
• The personal reward means donating is never purely altruistic. Contribution that only benefits other people does not survive contact with a lapsing player.

The escalating cost curve is a hard-currency sink. Where it lands relative to existing sinks (arena tickets, AFK skips, chest upgrades) is a balance question for TECHGD, not a design question — but the shape is: cheap enough that donation 2 is a normal purchase, steep enough that donation 5 is a whale action. Legend of Mushroom runs exactly this curve — first donation free, each subsequent one +20 gems, capping at 100 — and pays the donor guild contribution plus a speedup coupon each time.

Lootborn Warriors (in-game screens) ships the same flat-XP principle from the other side: three donation tiers — Basic on soft currency (1/day), Premium and Exclusive on premium currency (1/day and 10/day) — and every one of them grants the guild the same 10 Guild XP, while the paid tiers pay the donor progressively more personal guild currency (200/300/500). Eleven paid donations enrich the payer and barely move the guild: flat XP is what both benchmarks actually run.

The capped-contribution principle, and why it matters more here than anywhere. Clash of Clans' Clan Games is the reference implementation of the anti-whale device this feature needs. Each member can earn at most a fixed number of points toward the clan's reward tiers; everything past the cap counts only toward a personal achievement and never toward the clan total. Payout is participation-shaped: completing one task earns a member the identical full reward set as a member who maxed the cap, and the only bonus for maxing is one extra item — flat, not proportional. Supercell's stated reason for raising the cap was to let smaller clans reach every tier.

Every daily contribution ceiling in the corpus follows the same logic and is deliberately small: AFK Arena's 100 activity points a day convert from quests the player would do anyway; Legend of Mushroom caps helping other members at the first 10 per day; Last War allows 30 donations a day regenerating one per 20 minutes. The consensus is that a member's daily ceiling should be reachable by an ordinary player, so that the ceiling — not the player's wallet — is the binding constraint. That property, not the specific number, is the anti-whale device.

Our 5-donations-a-day cap already has this shape. The thing to protect is that nothing ever lets anyone exceed it for money. The cap is counted per player per day, across guild changes — switching guilds mid-day does not grant a fresh set of donations.

A second contribution vector, and why it is not in this release. Legend of Mushroom pays contribution for helping other members' timers, capped at the first ten helps a day. It costs the helper nothing, it is pure reciprocity, and it is completely orthogonal to power — which makes it the cleanest possible contribution lane for an F2P player. It is cut, for one reason: it needs a member-visible wait to help with, and we do not have one. Nothing in our loop is a timer another player can shorten, so shipping this means first building that primitive — a larger change than the payout justifies, and one that would have to earn its own place in the core loop rather than ride in on the guild.

It is recorded here, and in the explicit cuts, as the first thing to add if live data shows F2P members with no way to contribute. That is the signal to watch: donation counts concentrated in the paying tail, with the rest of the roster contributing only boss attempts.

12. Inactivity and dead guilds

This is not an edge case — it is the base rate. The one large-scale academic study of guild lifecycles (>300,000 characters across five WoW servers, 2005–06) found that 54% of the guilds observed in July were gone five months later, that roughly a quarter of all guilds visible at any moment disappear within a month, and that monthly member churn sits near 25% and is roughly flat across every size band — from two-member guilds to guilds of 150+. Bigger rosters do not churn less; they churn proportionally the same and lose more people in absolute terms.

The same study's survival model (71% classification accuracy) found guild size to be one of the strongest predictors, and its advancement model found size negatively signed: smaller guilds progress faster.

Two caveats travel with these numbers: it is subscription-MMO data from 2005–06, and it measures emergent size under no cap, in a game whose raids demanded 40 players. It is a base rate for how guilds decay, not a cap recommendation. But as a base rate it is the only one that exists, and it says plainly that a guild feature without inactivity handling will, within a season, consist mostly of husks.

Live-game policy varies widely and gives us a range to sit in: Puzzles & Survival auto-disbands an alliance after 7 days of inactivity or when it drops below five active members — the most aggressive rule found. Idle Heroes auto-kicks any non-leader inactive for 30 days. Clash of Clans has no automatic member kick at all, only the leader rotation. The only merge tool documented anywhere in the corpus is AFK Journey's leader-to-leader guild merge.

What the design must handle:

• Inactive members occupying seats. The roster already surfaces last-online per member, so the leader has the information; what is missing is a reason to act and a tool that scales. Proposal: surface an "inactive" marker on the roster past a configurable threshold, and give the leader a bulk-kick action for members past it. Automatic kicking is not proposed for V1 — a player returning from a week away to find themselves ejected is a worse outcome than a slightly stale roster.
• Dead guilds — every member inactive. These are worse than inactive members because they consume names and pollute the recommended list. A guild therefore has an explicit lifecycle rather than an implicit one:

Active → Dormant → Retired.

A guild goes Dormant when no member has been online for a configurable window. Dormant guilds disappear from the recommended list and cannot receive applications or invites, but are otherwise untouched: the roster, the level, the chat history and the name all persist. Any member logging in returns the guild to Active immediately — dormancy is a visibility state, not a punishment, and it must be invisible to a returning player beyond a line in the event log.

A guild is Retired only after a much longer window with no login by anyone. Retirement is the destructive step and must be spelled out, because "the name is released" quietly implies all of it: memberships are dissolved, pending applications and invites are dropped, the guild vanishes from every list and leaderboard, its season score leaves the ladder, and the name is released for reuse — but the tag never is. The entity itself is soft-deleted and kept for an audit window, so support can still answer "what happened to my guild".

The tag is retired permanently, not recycled. It is the handle that analytics, support tickets, moderation history and any future cross-realm record point at; reissuing it to a different guild would silently merge two unrelated histories under one identifier, and nothing downstream would notice. Names are display text and may be reused freely — a new guild called "Ironclad" is a different guild with a different tag, and every system that matters keys on the tag.

A player returning after their guild retired is guildless, is told so on entry with the guild's name and the date, and is routed to the No-Guild screen — never into an empty guild view. Their personal guild currency and personal reward tracks survive; see the next bullet for exactly what does and does not.

Note that Retired is currently the only path that dissolves a populated guild, since V1 has no automatic kicking. A guild of thirty players who all quit on the same day sits Dormant for the full window before anything happens to it, which is the correct trade — the alternative is destroying guilds that were merely on holiday. - The economic form of the problem: in any design where the guild's access to content is funded by a pooled member resource, idle seats throttle everyone. This becomes load-bearing at the guild boss. - The insulation that makes all of this survivable — stated precisely, because the naive version of it breaks the collective progression. What is bound to the player and survives leaving, being kicked, or the guild retiring: personal guild currency, personal reward-track progress, and anything already purchased with them. Both AFK Arena and Idle Heroes confirm this explicitly — leaving forfeits nothing already earned.

What is bound to the guild and does not travel: guild level, guild experience, guild technologies, and the guild's season clan-point total. These are collective by definition; if they moved with the player, a guild's entire progression could be assembled by recruiting people who had accumulated it elsewhere, and hopping would become the optimal way to level a guild.

The line is: what you earned, you keep; what the group built, stays with the group. Against a 54% five-month guild death rate, the first half of that stops one guild's death from becoming several players' churn; the second half stops the whole collective layer from being farmable.

13. Clan points and the seasonal leaderboard

The producer spec: every fight between two real players who are both in guilds awards +1 clan point to the winner's guild. Points are tracked per player for the season (which is what the intra-guild leaderboard sorts on) and reset at season end. The guild leaderboard sorts guilds by clan points and ships alongside the existing seasonal player leaderboards.

Bookkeeping is two counters, both season-scoped.

• The guild's season total, incremented at the moment of a qualifying win. It belongs to the guild: a member joining, leaving or being kicked later does not move it, because it was never derived from the roster — it is a running count of wins that happened under the guild's banner.
• The player's personal season points — what the intra-guild board sorts on, and what personal season rewards pay out on. They are the player's and travel with the player.

Spend is deliberately not insulated, and that is a decision, not an oversight. Roster size is bought with donations, extra arena tickets are bought with gems, and both raise a guild's ceiling on the ladder. The seasonal ladder is the competitive surface of this feature, and it rewards big, active, paying guilds the same way every other competitive surface of the game already rewards paying players. An earlier draft carried three devices that decoupled the ladder from spend — a per-player daily cap at the free ticket allotment, a top-N scoring slice, and seasonal contributor slots. All three were removed by decision: the cooperative layer (donations, the boss) stays capped because its benchmark caps it; the competitive layer is open. The namesake competitor ships exactly this shape: Lootborn Warriors' in-game Guild CP Rankings ladder ranks guilds by the raw total combat power of their members, across merged servers, with no cap of any kind.

Two boundaries remain, and neither is a spend cap:

• Qualifying fights: arena only. The arena is the game's only live real-player PvP surface, and every arena fight costs a ticket, free or bought, so every clan point has a price. If another PvP surface ever ships, it qualifies only if each fight carries a comparable per-fight cost — a costless rematch loop would let two cooperating accounts mint unbounded points. Tagged arena bots are excluded as non-real opponents, and fights between members of the same guild award nothing — otherwise any intra-guild pairing the matchmaker happens to serve would be a guaranteed +1 for the guild regardless of who wins.
• The opponent must also be in a guild — the producer spec as written, confirmed as a deliberate recruitment device. A win against an unguilded opponent pays no clan point, and telling the player why turns every arena session into a nudge toward joining a guild. Early on, that means many wins pay nothing — accepted: the empty award is the advertisement. Guild status of both fighters is read live at match end, never from the defender's stored snapshot, which may predate a guild change.

Season-end guild rewards go to the members of the guild at season close, banded by the guild's final rank, and are delivered through the existing weekly-ratings mail path. Personal season rewards ride the player's own points and follow the player regardless of guild. Membership at close is the simplest eligibility rule; it admits a last-day joiner into the guild reward, which is accepted for the same reason the ladder itself is open. With the leave cooldown set to an hour (§7) this is the one place the short cooldown is actually felt — a player can be inside a high-ranked auto-join guild minutes before rollover. It stays accepted: the guilds worth hopping into at season close are full or application-only precisely because they are winning. If live data shows roster churn spiking in the last hours of a season, the fix is a minimum membership age on the guild band reward alone — not a longer cooldown on everyone.

What a season actually pays, and what the prize really is. Three things, kept deliberately separate:

• Guild band rewards — guild currency and a chest to every member of the guild at season close, banded by final rank. Material, but small enough that finishing a season low is not a progression setback. Losing a season must cost standing, not power.
• Personal band rewards — the same shape, paid on the player's own season points, following the player.
• Prestige, which is the actual prize. The top three guilds of a realm carry a season badge on their emblem frame through the following season; the top guild is announced realm-wide in chat at rollover and its members carry a unique frame for the season. All of it is cosmetic and expires — never power, never a currency multiplier. Lootborn Warriors pays its own top ranks in exclusive cosmetics for the same reason: a prize that grants power turns the ladder into a rich-get-richer loop, and a prize that expires is a prize that has to be defended, which is the entire point of running a second season.

14. Guild identity in the world

Emblem and name render next to the player wherever the player renders — profile card, chat messages, leaderboards, arena opponent lists, party, friends. This is the cheapest retention mechanic in the feature: it makes membership visible, which is what makes it feel like an identity rather than a menu.

The Profile GDD already reserves a "Clan / Guild link" slot for exactly this.

---

15. Guild Boss

The roster needs something to do together. The guild boss is the cheapest way to give it a shared score with a weekly rhythm.

The model is Legend of Mushroom's Blazing Cave, taken whole rather than assembled from several games. The tempting alternative is to combine that game's attempt cadence with a squad-RPG's kill reward and a Clash of Clans contribution cap — three well-evidenced mechanics that no shipped game runs together, and whose interactions nobody has tested. One coherent source beats three good ideas that have never met.

• The boss ladder is endless and never resets. Each level is a boss the guild wears down and defeats together; there is no final level and no terminal kill to race for, and no reward is tied to who dealt the blow. The ladder is the guild's permanent record — a guild does not start over on Monday, it picks up where it stopped, which is what makes the boss the one guild activity that rewards a long, unspectacular membership. There is therefore no "boss cycle." Two timers exist in this system and neither touches progress: attempts regenerate, and unclaimed chests expire.

• What a level is, and how it scales. A level is one row of a config table — { level, hp_pool, chest_tier } — and nothing more. HP grows on a curve steeper than a guild's power growth, so the ladder is always a wall the guild is pushing against rather than a checklist it finishes: the rate of advance is the score, not the level number. Chest tier steps up in bands (every tenth level) rather than every level, so a level is a small visible win and a band is the thing worth organising for. Where the curve sits is TECHGD's; the shape is not negotiable, because a curve that flattens turns an endless ladder into a solved one and the guild's shared activity into a daily chore with no horizon.

• Damage is pooled across the whole guild, and the pool advances the boss through a ladder of levels. Reaching a level threshold grants a chest to the entire guild — a guaranteed one, plus a chance at a better one.

• Reward is collective and equal. It is not scaled by individual damage share. This is the load-bearing property, and it is what makes the design safe in auto-combat: there is no per-member payout to rank, so there is no public weekly ranking of guildmates by spend — the risk named at the top of this document. A member who contributed a little and a member who contributed a lot open the same chest.

• Attempts regenerate on a timer and bank shallowly — one attempt every 8 hours, banking to a maximum of two. Deep enough to forgive one missed session, shallow enough to punish two. This is a gentler anti-lapse device than a hard daily reset, and it maps onto our existing daily-key dungeon gating. Attempts are not purchasable and are not granted by spend in other systems.

• Unclaimed chests clear at the daily server reset — exactly where the source clears them. The guild either collects or it does not.

• Visible per-member contribution, so the guild can coordinate. Every member's attempts today are visible to the whole guild, next to the guild's pooled progress on the current level. Attempts, never damage. That is the entire social layer — no game in the corpus has a rubber-band, damage boost, or carry mechanic.

What this design deliberately gives up, so nobody rediscovers it as a bug:

• A member of a dead guild gets nothing from the boss. Rewards are purely collective, so there is no personal track to fall back on. This is a real cost given that a documented 54% of guilds die within five months, and it is the reason the personal insulation in §12 matters — guild currency and personal reward tracks are where an individual's payout is protected. The boss is not.

• A guild carried by one very strong member still reaches higher levels than a balanced guild of the same size. Collective thresholds remove the within-guild ranking-by-spend problem completely, but they do not equalise between guilds. This is the residual, and it is the one thing worth watching once the feature is live: if boss levels correlate with a single member's power rather than with turnout, a per-member contribution cap can be introduced then.

• How the chest is split among members is not documented in any source. Our answer is the simplest one consistent with the rest: every member of the guild at the moment the threshold is reached receives the chest. Claiming requires still being a member — leaving or being kicked with a chest unclaimed forfeits it.

Legend of Mushroom runs a second, different guild boss — a scheduled event with a sign-up window, a fixed short battle, and rewards for signing up, participating, damage contribution and first kill. It is a live-ops shaped format rather than an always-on one, and it is deferred, not merged into this one.

Lootborn Warriors' own Guild Raid (in-game screens) sits on the other side of the same fork: a leveled HP-pool boss, three attempts per member per day, timer-rotated affixes, a cross-guild raid leaderboard — and a public per-member damage ranking inside the guild. That last element is exactly what the Legend of Mushroom model avoids and what the central-problem section of this document rules out; the boss stays LoM by decision, and the LW raid is recorded here so nobody re-imports its damage board by accident.

16. Guild currency, shop and technologies

Once the boss exists, the guild has a faucet and can have an economy.

• Guild currency is earned from boss contribution and daily guild activity, and is personal — the member spends their own.
• The guild shop sells things with no other reliable source at that point in progression. Exclusivity is what gives the guild tab a non-substitutable reason to exist — and also what converts opting out into a felt penalty, so what goes in the shop must be accelerative, never required.
• Guild technologies are a collective research track funded by donations, granting small passive bonuses to all members.

Two currencies, two shops, no conversion. The feature ends with three payout surfaces — boss, Showdown, War — and it would be easy to let them blur into one wallet nobody can reason about. They do not:

Faucet	Currency	Sink
Donation — the donor's personal reward, on every donation	Guild Coin	Guild shop
Daily guild activity — the day's first boss attempt	Guild Coin	Guild shop
Guild Showdown — the weekly reward tier, victory or consolation	Guild Coin	Guild shop
Guild War — the match reward, by result	Honor Coin	War shop
Guild Boss — level chests	items directly	—
Guild Gifting — gift chests	items directly	—

Three rules hold it together. Guild Coin is personal — earned by the member, spent by the member, and it survives the guild's death (§12), which is what protects an individual against the boss paying nothing to a dying roster. Honor Coin is war-only and never converts — that is what lets the War shop stock things the guild shop cannot without doubling anyone's total buying power. The boss and Gifting pay items, never currency, so each currency has exactly one faucet family and a designer can retune one mode without silently moving another mode's prices.

Lootborn Warriors runs precisely this split: donations pay the donor 200/300/500 guild currency by tier, the Showdown pays 1200/600 Guild Coins by result, and the War pays its own Honor Coins into its own separate shop.

Guild Gifting — taken from Lootborn Warriors. A member buys a gift pack from the real-money shop and every member of the guild receives a gift. Six pack tiers; the sender may stay anonymous. In-game screens add the system's second half: gift chests are also generated by members' achievements — daily quests, arena daily and weekly ranks, weekly event tiers, first-time dungeon floors — so the shower of chests is a reciprocity engine, not only a monetization hook. Each member has a daily claim cap (set generously — 200/day in the source), and it does not reset on leaving a guild — hopping between gifting guilds farms nothing. This does not touch the friends' 1:1 gift system, which remains the only personal gifting channel: Guild Gifting is one player's spend benefiting the whole roster — exactly the monetization shape this design already accepts on the ladder.

Guild technologies grant combat bonuses, and that decision carries one hard requirement. Because our Arena is snapshot-based PvP matched on character_power, a guild buff that changes what a character does in a fight must be inside the power value the matchmaker reads, and inside the snapshot taken of an opponent. A buff that applies in the fight but not in the number used to pair the fight is the exact failure mode — and it is the same class of bug this project has already shipped once, with displayed-versus-canonical power in the Arena. This has to be verified explicitly rather than assumed, on both sides: the attacker's live power and the defender's stored snapshot. And because joining or leaving a guild changes the buffs, a guild-status change must refresh or invalidate the player's stored defensive snapshot — otherwise it misstates their power until the next natural refresh.

The market gives no policy to copy here. Across thirteen games, no developer statement, patch note or wiki page states an explicit rule for neutralising, capping or excluding guild buffs from PvP matchmaking. The two observable precedents are opposite: one game normalises its guild war entirely (fixed level, matching gear, buffs for everyone), and two others simply fold buffed strength into the matchmaking number. We are taking the second route, which is the one our Arena already supports.

Magnitudes stay conservative, because the benchmarks that publish numbers are conservative on combat and generous on economy. A fully maxed class research tree in the closest comparable idle RPG tops out around +25–30% on core combat stats. The two real perks in Clash of Clans cap at +50% treasury storage and +25% war loot — both economic, neither combat. The only four-digit multiplier found anywhere in the corpus belongs to an individual system, not a guild one. A guild-wide combat buff meaningfully above that band would not be a bonus, it would be a second progression system, and it would make an unguilded or badly-guilded player uncompetitive in Arena rather than merely behind.

So the tech tree carries both kinds, deliberately split: economic nodes (drop rates, key regeneration, gold yield, dungeon output), which are safe and can be generous, and combat nodes (the standard stats), which are capped tight and must round-trip through character_power.

The residual risk is the one no source can settle: guild buffs make guild membership a competitive requirement in Arena, which converts a social feature into a power gate. Watch the Arena rating distribution of guilded versus unguilded players after launch — if the gap exceeds the buff magnitude, the tree is doing more than its numbers say.

The guild week — one rival, two surfaces

The two guild-vs-guild modes land on the same calendar, and read separately they collide: the Showdown runs Tuesday–Sunday with Monday for rewards, the War runs Tuesday–Saturday preparation, Sunday battle, Monday truce. Sunday is both the Showdown's heaviest scoring day and the War's battle.

The collision is resolved in the strongest direction available: a guild has one rival per week, and the two modes are two surfaces of the same rivalry. Pairing happens once, on Monday, off the seasonal clan-point ladder. The guild you race all week is the guild you fight on Sunday.

Day	Showdown	War
Monday	reward day, no tasks	truce; next week's pairing published
Tuesday–Thursday	daily tasks, 1 medal a day	preparation; the rival is known, nothing to fill in
Friday–Saturday	daily tasks, 2 medals a day	preparation; the nine defenders are picked and frozen when Saturday ends
Sunday	daily tasks, 2 medals	battle phase

Sunday's war attacks are themselves Showdown scoring actions — an attack spends an attack charge, and spend is what the Showdown pays for. So the week has one real peak instead of two events competing for the same evening: the battle is the last and heaviest day of the race, and a guild that wins the battle is usually also winning Sunday's medals. That is a feature, not double-dipping: both are measuring the same effort, and they pay in different currencies (§16).

Two consequences follow, and both are ours rather than the source's:

• One pairing pool instead of two. On a realm-bounded population this matters more than tidiness: two independent pairings would need twice the eligible-guild supply and would routinely hand a guild two mismatched opponents in the same week. If a realm ever proves deep enough to want separate matchups, splitting them is a knob, not a redesign.
• Eligibility differs even though the rival does not. The Showdown needs an active-member floor; the War wants nine defendable members. A guild that clears one and not the other still plays the one it clears — short rosters have their remaining defender slots taken by AI reinforcements (§18), which is exactly what the source does with them.

17. Guild Showdown

Guild-vs-guild ships last for reasons of supply, not effort. The model is Lootborn Warriors' Guild Showdown, taken whole — the same rule that gave the boss a single coherent source instead of a collage. The closest competitor runs a fully documented GvG format built for a vertical idle RPG, and we copy it rather than assembling one from squad-game mechanics that assume per-fight decisions our combat does not have.

The format:

• Two guilds are paired head-to-head for a week. The showdown runs Tuesday through Sunday; Monday is the reward day, with no tasks.
• A participation floor gates entry. The benchmark requires 12+ active members; ours is a config knob tuned to the roster cap.
• Showdown points are paid for spending, not for showing up. This is the source's shape read correctly: Lootborn Warriors' showdown tasks are "use N scrolls", "use N hammers" — the currency of the race is the player's own consumable stock, which is exactly why the source can leave tasks unlimited. Ours works the same way and for the same reason. Every scoring action must be a spend; an action with no resource cost cannot enter this table, or the race pays for nothing and turns into a tapping contest.

Scoring action	Points (provisional)
Arena ticket used	200
Dungeon attempt used	200
Guild boss attempt used	300
Guild war attack used (Sunday)	300
Guild donation	500
Chest opened	100
Gacha pull	400
Gold spent on upgrades	1 per 100

Tasks repeat without limit and every point feeds both the player's personal tally and the guild's daily score. Nothing caps a player's points, and nothing needs to: the cap is the player's stock and wallet, which is precisely the open competitive layer this document already chose (§13). Note what this does to the daily-capped systems — the five donations and the two banked boss attempts still contribute, they simply cannot be the whole race, and a guild that wants to win one spends beyond them. The relative weights above are the design; the absolute numbers are TECHGD's. - Each day the higher-scoring guild earns a medal, and medals are weighted — one each Tuesday–Thursday, two each Friday–Sunday, so the weekend decides and an early bad day never makes the week unwinnable. Points settle in a short pre-midnight lockout window. A drawn day pays the medal to both guilds; a drawn week goes to the higher weekly total, and if that too is equal, to the higher seed. - The week goes to the guild with more medals, and both guilds are owed a reward tier — victory and consolation, claimed on Monday (§19) — but a tier pays only if that guild's own weekly points reach an activity threshold (the source gates both tiers at 1,000,000 of the guild's own points). A guild that did not actually play is not paid for having been paired, and a walkover week cannot be idled through. The source's 1,000,000 is in the source's own point units and does not transfer: ours is a config knob, calibrated against the table above so that a guild sitting at the participation floor and playing ordinarily clears it, and a guild that showed up but did not play does not. Calibrating it is a launch-blocking number, because a threshold set too high pays nobody and one set too low makes the whole rule decorative. - Individual rankings run across the combined pool of both guilds, daily and weekly, with exclusive cosmetics at the top and cumulative personal milestones below. - Anti-hopping, copied verbatim: points earned while guildless are void and never count retroactively; each reward tier pays once per account regardless of leaving and rejoining; switching guilds mid-showdown forfeits the day and clears the player's points from the old guild's tally. Two boundaries of that rule are ours: a kick is not a switch — being kicked never touches the guild's tally, and the forfeit-and-clear applies only to a voluntary change, so a kick cannot be used to erase a scorer's contribution; and joining from guildless mid-showdown may score from that moment — the rules target hopping, not recruitment.

Three things the source does not document, so they are our design and are flagged as such: pairing — matchups are seeded by the seasonal clan-point ladder, which gives the V1 ladder its continuing job as the qualification-and-seeding metric; an odd guild count — an unpaired guild gets a rest week, not a bye win; and opponent forfeit — if the opposing guild is disbanded or retired mid-week, the surviving guild takes the remaining daily medals and the weekly win. Its reward tier is still gated by its own activity threshold, so a walkover still has to be played — and losing a week can never be improved by disbanding.

For the record, Legend of Mushroom runs its own GvG — the Family Brawl: groups of four families matched by level, three battle lanes, an evening battle window (Wednesday–Friday, 20:00–22:00 server time, win two of three lanes), and a win-streak debuff that cuts a serial winner's attack and defence (−15% at three straight wins, −20% at four, −35% at five, scaling toward −99%). We follow Lootborn Warriors' Showdown instead — by decision, and because a synchronous evening window assumes concurrent presence an async idle game cannot. But the win-streak debuff is the market's documented anti-carry device, and it is the tool to reach for if Showdown data shows a single member's power dominating the guild score.

A points-race also fits realm-bounded supply strictly better than a bracket league: it needs exactly one opponent per guild per week, it scales down to two guilds on a thin realm, and no promotion/relegation structure has to survive a shrinking pool. The earlier draft's asynchronous snapshot war — attacks on saved defensive placements, units locked to defence or offence — was a squad-game format whose central mechanic assumes per-fight roster decisions; it went the way of the boss kill-crate when the copy-one-source rule was applied.

18. Guild War

The second guild-vs-guild mode, and the second one taken whole from Lootborn Warriors — this time from its in-game rule screens rather than wiki pages. The two modes are complementary, exactly as the source runs them: the Showdown is the week-long activity race, the Guild War is the Sunday combat peak.

• Weekly cadence: Tuesday–Saturday is the Preparation phase, Sunday is the Battle phase, Monday is the Truce.
• Matching is off the seasonal clan-point ladder, against the week's single rival (see The guild week above). The source matches by its own cross-server division system; we have no divisions and our realms do not pool for content, so the ladder we already run does the job — adjacent guilds on it are paired, an unpaired odd guild gets a rest week, and it is the same pairing the Showdown uses. This is ours, and it is flagged as ours.
• The nine defenders are selected automatically — the guild's strongest nine. At the moment Preparation ends, the game ranks every eligible member by character_power and takes the top nine: the top three are the Elites, the next six the Core. Elites hold 3 Stars of Victory each and Core hold 2, so a guild puts 21 Stars on the field (values provisional, and the only numbers deciding how long a battle phase lasts). A defender loses Stars by the mode of each defeat and retreats at zero, after which they cannot be attacked again.

In the source this is the Guild Master and Vice Masters' job. We do not copy that, by decision: a weekly assignment chore is a button whose owner can be absent, and a guild losing its Sunday because nobody filled a form is the worst failure this feature can have. Ranking by power is also the only ordering an auto-combat game can defend — there is no formation to compose and no counter-pick to make, so "who defends" has exactly one correct answer, and asking a human to type it in weekly adds no decision, only a way to get it wrong.

Three rules make automatic selection safe. Eligibility is the anti-hop rule already stated — only members who were in the guild before Preparation began can be picked. Selection is deterministic and fixed at lock: ties on power break by join date, then by the lower character id, and the nine do not change once the Battle phase starts, so a guild cannot re-roll its defense mid-battle by shuffling members. A defender who leaves the guild after the lock degrades to an AI reinforcement in the same slot, keeping its Stars — the slot is never re-filled from the roster, which would be the same re-roll by another route.

What this gives up is the one tactical decision the leadership had. That is accepted: the per-attack engagement-mode choice below is where the war is actually played, and it belongs to every member rather than to two officers. - Defense builds lock at the end of Preparation. Each defender stores a defense build; a defender who stores nothing has their current build locked instead, and later upgrades do not affect the locked lineup — the snapshot rule, straight from the source. We keep the lock and drop the stored build: our characters have no separate defensive loadout to author, so what locks is simply the defender's build as it stands at the end of Preparation. One event, one snapshot — the same moment that picks the nine also freezes them. A guild with fewer than nine eligible members has the remaining slots taken by weak AI reinforcements. - Battle: everyone attacks, attacks are limited, and the attacker chooses. Every member gets a limited number of attacks (a knob; provisionally three). A fight is won by defeating the opponent's main character, or by holding more HP at time-up; defenders can attack too. Against each defender the attacker picks one of three engagement modes:

Mode	What it does to the duel	Stars a win takes
Duel	no modifier — raw power decides	1
Siege	both sides' max HP raised, damage untouched: the long fight, which the better-scaled side wins	1
Ambush	both sides' damage raised and HP cut: the short, volatile fight, where an underdog has a real chance	2

The modifier is symmetric, and that is what the source's "both sides receive identical stat adjustments" means read our way: the mode is a shared condition of the duel, not an attacker-only buff. There is no global stat normalisation in our war. Outside the mode's modifier, fights use the same power model as the Arena, so gear, levels and the guild tech buffs of §16 carry into the war exactly as they do everywhere else. Normalising the war would strand the tech tree this document just routed through character_power, and would make the one mode where guild identity matters most the single place where progression does not — a reasonable trade in a game with formations and manual control, and a bad one in ours, where power is the play.

The mode choice is the per-attack decision this design otherwise lacks, and it is a decision money does not make for you: a safe Star from a Duel against a defender you outscale, or two from an Ambush against one you do not. - Anti-hop, verbatim: members who join during Preparation or Battle spectate this round; only pre-Preparation members attack or defend; a member who does not participate in the Battle phase gets neither Vault access nor match rewards; changing guilds forfeits Vault access. - Forfeit, verbatim: a guild disbanding during Preparation leaves its opponent facing a guild composed entirely of AI reinforcements — the match still runs, and the living guild is still paid. - How the war is won. At the end of the Battle phase, the guild that has taken more Stars from the opposing defenders wins. Ties go to the guild that lost fewer of its own Stars; if that is level too, to the higher-seeded guild — the same last-resort tiebreak the Showdown uses. Routing all nine opposing defenders before time ends the match immediately. - Where the result goes. A war result does not mint clan points: the arena-only rule of §13 holds, and a bulk award would swamp a metric built out of single wins. Instead each war writes to the guild's season record — a win/loss tally shown on the guild profile and in the rankings screen, and used as the tiebreak on the clan-point ladder when two guilds finish a season level. That is the whole consequence, and it is deliberately small: the war pays in Honor Coins and Vaults, and it settles standing only where the ladder cannot. A mode that fed the ladder directly would make the ladder a war ladder, and the arena wins that the producer specification builds it from would stop mattering. - Rewards: Guild Honor Coins and the Vault. Honor Coins are the war's own currency, spent in a separate Guild War Shop — victory pays a lot, defeat a little, sweeping a defeated player a minimum. Each match grants one Vault opening (a victor's Vault is better), and an unopened Vault expires at the end of the next Battle phase.

19. Claiming — nothing is granted automatically

Every reward in this feature is claimed by the player, with an explicit action. Nothing is credited on its own. Not the boss chest, not the Showdown tier or its milestones, not the war payout or the Vault, not the season rewards, not the first-join incentive, not a guild gift. This is a rule about the whole feature, not a property of any one screen, and it holds even where auto-crediting would be technically simpler.

The reason is that the claim is the payoff moment. A guild reward that appears silently in the inventory is a number that changed while the player was not looking — which is exactly the wrong outcome for the one feature whose entire job is making other people's presence felt. The tap is where the player sees what the roster earned them, and it is also the cheapest possible reason to open the guild tab tomorrow.

Four consequences follow, and each is a requirement rather than a nicety:

• Every claimable carries an expiry, and states it on itself. A manual-claim economy without expiries silently becomes an infinite pending list. Boss chests clear at the daily server reset (§15); the Showdown tier and its personal milestones stay claimable until the next week's reward day; the war payout and the Vault expire at the end of the next Battle phase (§18); season rewards ride the existing mail retention window. Where an expiry is short, the item shows its countdown, not a static label.
• What expiry means differs by cadence: the rare and valuable fall back to mail, the daily ones are lost. A player must not lose a week's work to a missed badge, a lost push or a holiday — but a mailbox that receives every daily trinket stops being a mailbox.

Claimable	On expiry
Showdown weekly tier	→ mail
Showdown personal milestones	→ mail
War payout (Honor Coins)	→ mail
Season band rewards	already mail
First-join incentive	→ mail
Guild boss chest	lost
Guild gifts	lost
War Vault	lost

The three exclusions are deliberate. The boss chest clears at the daily server reset because that reset is the boss's only daily beat, and it is where the source puts it. Gifts already carry a generous daily claim cap (200 in the source) — routing that volume into mail would destroy the mailbox to protect trinkets. The Vault is not items but a single opening with randomness in it; a mailed "open me" is a worse object than a clean expiry, and it dies with its Battle phase exactly as the source has it.

• Membership is evaluated at the moment of expiry, not at the moment of claim. This is the rule that keeps the mail fallback from becoming a hole in §12: a guild-sourced reward is mailed only if its owner was still a member when it expired. Otherwise the fallback would let a player join, wait for the guild to earn something, leave, and collect it from mail anyway. Mail retention is then the real, final expiry — after that it is genuinely gone.

• The mail fallback does not soften the badge requirement. It is a safety net against our failure, not a substitute for surfacing a claim. The risk it introduces is organisational: if nothing is ever lost, nobody notices that the badges are wrong. The three-level badge rule below stays a requirement, and "the mail will catch it" is not an acceptable answer to a missing one.

• Unclaimed rewards must be findable without hunting. A badge on the guild entry point in the HUD, a badge on the specific tab, and a pending-claims block on the guild Overview — three levels, so a player who opens the game once a day never has to remember which of six surfaces owes them something. A reward that expires while a badge was never shown is a bug, not a player's mistake.
• Membership is checked at claim time too, and the personal/collective split of §12 decides the outcome. Guild-sourced rewards — the boss chest, the Showdown tier, the guild band of the season reward — require the claimant to still be a member; leaving or being kicked with one pending forfeits it, and it is not mailed either (the expiry-time check above). Personal rewards — the player's own season points band, personal Showdown milestones, war Honor Coins already earned — follow the player and stay claimable regardless of what happens to the guild.
• Claiming is server-authoritative and idempotent. A double tap, a reconnect mid-claim, or a retried request pays exactly once. Bulk Claim All exists where the count can be large (guild gifts), but a bulk button is still a player action — there is no configuration in which the game claims on the player's behalf.

One thing that is deliberately not a second tap: the donation's own personal reward. The player pressed Donate, the result popup is the receipt, and the reward is part of that action's outcome rather than a pending item. Same for guild experience. That is a decision, recorded here so it does not read as an oversight — if a donation should instead produce a claimable, it is a one-line change in the same machinery.

Progression / economy

The Guild adds a second progression axis that is collective rather than personal, and a hard-currency sink that competes with existing sinks.

Guild level. Guild level does four things, and together they are the reason donations have a point:

• Member cap — the roster grows as the guild levels (see the realm-bounded supply problem below).
• Rank slots — how many deputies and guards the guild may appoint (§5).
• Guild-shop stock — higher levels unlock further rows of the shop. This is Lootborn Warriors' own use of guild level, and it is the safe half of it: gating access to a sink costs a player nothing they had.
• A floor for guild-vs-guild entry — a guild founded on Saturday does not get dropped into Sunday's war. The bar is low (a knob; a normally active guild clears it within days) and exists only to stop throwaway guilds farming a week of rewards and disbanding.

What guild level deliberately does not do is grant power. The tech tree (§16) is the guild's power vector and it is capped there; a second one riding on guild level would count the same donations into combat strength twice and would make the ceiling in §16 a fiction. Lootborn Warriors gates whole features behind guild level — donations, shop, raid, war unlock as the guild climbs; we take the shop tiering and the GvG floor and leave the rest open, because a brand-new guild with nothing to do is the fastest way to kill a brand-new guild.

The curve should be shaped so that a newly created guild reaches its second and third level quickly — a guild that cannot grow past its founding size in its first days will not attract joiners — and then flattens hard, so that the top guilds on a realm are separated by months of sustained donation rather than by one whale's afternoon.

The donation cost curve is the hard-currency sink. Its shape: donation 1 free, donations 2–3 priced as a routine purchase, donations 4–5 priced as a deliberate one. The daily cap of five is what bounds the sink — this is not a currency drain that scales with wallet size, which is correct for a system whose output is shared.

Clan points are not a currency and are not spent. They are a seasonal score that resets. Their only economic role is deciding season-end rewards, which are delivered by the existing weekly-ratings mail path rather than a new delivery mechanism.

Guild currency is a parallel earn-and-spend loop whose faucet is participation and whose sink is the guild shop. Its design constraint is that it must not become an alternative route to the same power the core loop sells — the shop accelerates, it does not substitute.

What the guild consumes from the wider economy: hard currency (donations), and — through the boss — a share of the player's existing daily resource spend, re-tagged as guild contribution. Note that the second one costs the economy nothing new: it is an accounting layer over spend that already happens. That is what makes it the right primitive.

The realm-bounded supply problem

Realms are language- and timezone-segmented and target ≤3000 concurrent users. That bounds guild supply per realm, and it forces an explicit trade-off that most guild designs never have to make:

• A large member cap yields few guilds per realm, thins the guild-vs-guild pairing pool, and increases dead seats per guild.
• A small member cap yields many more guilds, makes brackets viable, makes each member's contribution visibly material, and makes a guild fillable from scratch — at the cost of a smaller social surface and thinner absolute reward pools.

This document recommends the smaller cap, and recommends making it a guild-level reward rather than a constant. Guild count is what showdown pairing consumes; roster size is what dead seats waste.

The market splits into two camps. Flat caps: 50 in Clash of Clans and in the squad-RPG benchmark, 100 in one 4X title, never raised by anything. Cap-as-progression: AFK Arena grows 30 → 70 at +5 per guild level; Idle Heroes 15 → 30 across thirty guild levels; Mythic Heroes 40 → 55 across seven; one title expands 50 → 100 through alliance research; Legend of Mushroom raised its own 90 → 110 by patch; Lootborn Warriors (in-game) caps at 50 at its maximum guild level 23, and its guild level also gates entire features — donation, shop, raid and war unlock as the guild levels. The progression camp uses roster space as something leadership earns, which means new guilds start deliberately small — and a small new guild is a guild whose first joiners matter.

Two things argue against copying any of the large numbers. First, every large cap in the corpus belongs to a game with genuine large-group content — fifty-versus-fifty wars, sixty players per brawl lane, thirty-fortress sieges. Lootborn has none of that, and a cap far above what the content requires reproduces a documented pathology: in the WoW study, the 90th percentile guild had 35 members while raids demanded 40, so most guilds structurally could not field their own format.

Second, the observed distribution is much smaller than any designed cap: median 9, mean 16.8, 90th percentile 35 — and the study's advancement model found guild size negatively signed, meaning smaller guilds progressed faster. A cap in the 20–35 band matches both that distribution and our realm supply, and leaves the cap-as-progression pattern available.

And a caution that applies to any cap we pick: the same study found monthly churn near 25%, flat across every size band. A larger roster does not buy stability — it buys more people to lose.

Two further consequences worth planning for:

• Realm age matters more than realm size. A freshly-opened realm has no guild supply at all; a mature realm has an entrenched top guild and a long tail of husks. Cold start at realm launch and husk recycling on mature realms are two different problems, and the first one is a design problem, not an ops problem — it is specified below.
• Keep guilds realm-scoped in V1. Realms already segment by language and timezone — which is exactly the matching that guild recruitment needs and that no source documents how to do. Breaking realm boundaries to fix guild supply re-introduces a matching problem we currently get for free. If supply proves insufficient, lower the member cap before considering cross-realm pools.

Cold start on a new realm

Everything ships in one release, which means five systems arrive at once on a realm that has zero guilds on day one. What each of them needs in order to function is different, and the design has to say plainly in what order they switch on — otherwise the first weeks of every new realm show players a set of dark tabs with no explanation.

• Guild, chat, donations, boss, shop and Gifting need exactly one guild. The first guild created on a realm can use all of them within the hour. This is the strongest argument for the always-on, collectively paid boss: it is the only guild content that works at a population of one guild, and it is what carries the feature through the opening weeks.
• The Showdown and the War need pairs, so they carry a quorum. Each mode runs on a realm only once at least four eligible guilds exist there — two would be enough to pair, four is enough that the pairing is not the same matchup every week. Below the quorum the modes are visible but dark, stating the condition and the current count ("Opens at 4 guilds — 2 so far"). A dark mode with a stated condition recruits; a hidden one just looks broken, and a mode that pairs a guild against the same opponent forever teaches players to ignore it.
• The participation floor is a per-realm knob, not a constant. A realm in its first month runs a lower floor and ops raises it as population fills. This is the single lever deciding whether early guilds get to play at all, so it must be tunable without a release.

What this design will not do is seed empty guilds to clear the quorum. A pre-created guild with no members is a husk on day one, and §12 exists precisely because husks are what poison a guild list. The quorum is allowed to take a week to clear; a fake list is not allowed at all.

UX

Entry point and gating

The Guild is a top-level destination, gated by chapter level like every other feature. The unlock is set two stages after the Arena — a provisional value by explicit decision, to be revisited against live progression data rather than argued further on paper.

Two consequences of that placement are worth keeping in view. Every player who reaches the guild already has the Arena, so the clan-point board is never an empty screen — the leaderboard tab shows both boards from day one, and clan points mean something the moment a player joins. And the unlock sits past the earliest chapters, so the guild's job tilts toward anchoring the players who have already survived the first days rather than rescuing the ones who have not.

Evidence on unlock timing is weak and contested; the only concrete benchmark is a game prompting a join after a mid-early milestone paired with a free reward. The surviving principle: pair the unlock with the first-join incentive.

Before the player is in a guild, the entry point leads to the No-Guild screen. After, it leads to the Guild screen.

Screen 1 — No-Guild

Tabs: Rating · Search · Invites, using the existing category tab strip.

• Rating — the realm's guilds sorted by seasonal rating, plus a prominent "Create guild" action showing its hard-currency price. Each guild row: emblem (left, in the position the avatar-badge occupies elsewhere), name, guild level, season rating, members current / max, required level, and a trailing action — Join (green) for auto-join guilds, Apply for application guilds, a disabled Applied state where the player already has one open, and a disabled action with the reason ("Full", "Lv 20+") where the guild is not joinable. This is the existing player-row anatomy with the emblem substituted for the avatar, so it reads as familiar on first sight.
• Search — a single field accepting an exact name or guild tag, with an explicit empty state that says the search is exact. Results use the same row.
• Invites — incoming invites, each showing the guild row plus who sent it, with Accept / Decline. A badge on the tab carries the count.

Screen 2 — Guild

A header carrying guild identity: emblem, name, level, the experience bar toward the next level, and member count. Below it, tabs:

Overview — the shared-state screen and the default landing tab. Contains the donation widget (see below), the guild's current standing on the seasonal ladder, and the most recent event-log entries. This tab is what a player who opens the guild once a day sees; it must contain the free daily action and nothing that requires reading.

Members — the roster. Rows sorted by rank, then by last-online. Each row: avatar, nickname, rank, level, last-online (using the existing relative-time convention), and — past the inactivity threshold — an inactive marker. Tapping a row opens that player's Profile Card, which is the game's universal behaviour for any avatar.

Rows carry a context menu whose entries are derived from the §5 matrix and from the viewer's rank relative to the row's: kick appears only for targets strictly below the viewer, mute in chat for deputy and above, change rank for the leader only. A member with no applicable powers sees no menu at all rather than a menu of disabled items.

Donate — the donation flow. Shows today's state as used / 5, the price of the next donation (with the first shown explicitly as free), the guild experience each donation grants, and the personal reward. Below, the recent donation history of all members — this is the social proof that makes donating feel observed rather than anonymous.

Leaderboard — two sub-tabs: by player level, and by clan points, both descending, both with the viewer's own row pinned using the existing sticky-self-row convention. The clan-point board carries the season timer.

Log — the chronological event log.

Settings — visible to deputy and above, with the controls themselves gated by the §5 matrix. The deputy sees the auto-join toggle, minimum level, and description editing. The leader additionally sees emblem change, rename, transfer leadership, and disband — the last two behind a two-step confirmation, since both are irreversible. Uses the existing settings-form popup pattern (label + control rows) rather than a bespoke layout.

Applications — guard and above; hidden entirely for other members so the tab strip does not carry a dead entry. Rows are the rich player-row variant (with loadout preview and last-online, as in party search), with Accept / Decline and bulk Accept All / Decline All.

Screen 3 — Create Guild

A single form: name (with live uniqueness validation and the moderation result), description, emblem picker (a grid picker, matching how skills and other inventories are chosen), and a confirm button carrying the hard-currency price. Confirmation is explicit — this spends hard currency.

Screen 4 — Guild Rankings (seasonal ladder)

The realm's guilds ranked by season clan points, shipped alongside the existing seasonal player leaderboards and also reachable from the guild screen's season-standing block. Top three guilds get the podium treatment (emblems elevated); below, guild rows — emblem, name + tag, level, members current / max, season points right-aligned, and the guild's season war record (W–L) as the visible tiebreak; the viewer's own guild pinned with the sticky-self-row convention. Guilds carrying a previous season's top-three badge render it on the emblem frame. The banner carries the season timer. Tapping a row opens that guild's public view. Guildless players see the ladder too — it is the recruitment shop window.

Chat

The guild channel appears in the existing chat as a channel tab, following the existing notification rules. No new chat surface is built.

States

• Loading — skeleton rows, never a blank list.
• Guild full — Join/Apply renders disabled with the reason, rather than failing after the tap.
• Level requirement not met — same: the row shows the requirement and the action is disabled.
• Applied — the action shows the applied state and offers to withdraw.
• Leader inactive, succession pending — the roster shows the leader's inactivity plainly. A guild silently failing to admit anyone is the worst version of this state.
• Last member leaving — confirmation warns that the guild will be disbanded.
• Kicked / disbanded while away — a returning player is told what happened and routed to the No-Guild screen, not dropped into an empty guild view.
• Donation cap reached — the donate action shows the reset timer.
• Season ended — the clan-point board shows the final standing and the new season's timer.
• Unclaimed reward pending — badge on the guild entry point, badge on the owning tab, and a pending-claims block on Overview (§19). Every claimable shows its expiry; short ones show a countdown.
• Claim refused — expired, or membership lost since it was earned: the item says which, in place of the button. Never a silent disappearance.
• Expired into mail — where a claim is mail-backed, the surface that owed it says so once ("last week's tier is in your mail"), so the player is not left comparing an empty screen against a memory.
• Guild-vs-guild below the realm quorum — the Showdown and War destinations render but are dark, stating the condition and the live count ("Opens at 4 guilds on this realm — 2 so far"). Never hidden: a stated condition recruits, an absent tab teaches nothing.
• Guild eligible but unpaired (rest week) — an explicit rest-week state, distinct from "pairing not published yet", with the day the next pairing lands.
• Guild ineligible for a mode — the reason names the failed condition and the current value: below the participation floor (n / floor active), below the GvG guild level, or fewer than nine eligible members — the last of which is a note rather than a block, since AI reinforcements take the remaining slots.
• War phase — every war surface carries the phase and its countdown. Before the lock the defender list is a projection ("who would defend if the phase ended now") and says so; after the lock it is the frozen lineup. The difference must be stated, not implied by a timer.

Notifications

Restraint matters more here than coverage — this is the feature most able to generate obligation. Notify on: an application accepted, an invite received, a guild level-up, and a rank change. Do not notify on every donation, every join, or every chat message; the chat's own unread badge covers the last of these.

Localization and accessibility

All static strings localised. Guild name and description are user content and are not localised. Numbers use locale-aware formatting. Rank names, level labels, and currency names use existing i18n keys. Emblems must remain distinguishable to colour-blind players — the set needs shape variety, not just colour variety.

Visual identity

Emblems are the guild's face and the feature's main expression surface. They render at four sizes: tiny next to a chat message, small in a player row, medium in the guild header, large in the create/select picker. Author at the largest size and verify legibility at the smallest — an emblem that becomes a smudge next to a chat name has failed at the size it renders most often.

The set needs enough silhouette variety that two guilds are never confused at tiny size. Colour alone is insufficient.

The guild header is the one place the guild gets a canvas: emblem large, name prominent, level and experience bar beneath. Guild level should read visually — a frame or banner treatment that changes at level milestones — so that walking into a high-level guild feels different from walking into a new one, without reading a number.

Level-up is a shared moment and should be glorified for everyone online, not silently written to the log. It is one of very few moments in the game that belong to a group rather than a player.

Emblem next to the name everywhere the player renders must stay subordinate to the player's own identity — it sits beside the avatar, it does not compete with it.

VFX stay restrained: a donation confirmation, an experience-bar fill, and the level-up moment. Nothing ambient, nothing looping — the guild screens are visited briefly and often.

Scope

Everything below ships together — the increment sequencing of earlier drafts was dropped by decision. One release contains the producer specification, the additions this document makes to it, the guild boss, the guild economy and the Guild Showdown.

In — the producer specification:

• Guild entity: emblem, name (unique per realm), description, leader, level, experience, member count and cap, member list with ranks and last-online, required player level, join type.
• Membership states, discovery (recommended list + exact search), auto-join, applications, invites.
• Guild creation for hard currency.
• Four ranks; leader-assigned. Leader succession on leave or 7-day inactivity.
• Member management: kick, rank change, application handling, invites, voluntary leave.
• Guild settings: auto-join toggle, minimum level.
• Event log: joins, kicks, departures.
• Donations: 5/day, first free, escalating hard-currency cost, flat experience, personal reward, overflow experience carry.
• Intra-guild leaderboards by player level and by clan points.
• Clan points from arena wins; seasonal guild leaderboard; season reset.
• Guild emblem and name rendered alongside the player everywhere.

Added by this document, and load-bearing:

• Guild chat — the Clan channel the chat system already specifies. Without it the feature is bookkeeping.
• A real permission matrix on the ranks — guard as the recruitment rung, deputy as the operations rung, with rate-limited kicks, level-scaled rank slots, and no acting on an equal or higher rank. This removes the leader as a single point of failure for recruitment.
• A globally unique guild tag rendered beside the realm-scoped name, plus the merge collision policy — required, since realm merges are planned.
• A join incentive on first guild join.
• Two separate cooldowns — a global 60-minute one after a voluntary leave, and a longer same-guild-only one after being kicked.
• A precise personal/collective split: personal guild currency and personal reward-track progress follow the player and survive the guild's death; guild level, experience, technologies and the guild's season score stay with the guild.
• A permanently retired guild tag on retirement — names may be reused, tags never are.
• The guild lifecycle — Active → Dormant → Retired, with inactive markers on the roster, a leader bulk-kick tool, dormant guilds hidden from recommendations, and retirement defined down to what happens to memberships, pending invites, the season score, the name and the tag.
• Split rules for leaving versus being kicked, so that a kick cannot be used to lock a player out of the feature.

In — the shared-content blocks (§15–§18):

• Guild Boss — the endless Legend of Mushroom boss: damage pooled across the guild, level thresholds granting an equal chest to every member, attempts one per 8 hours banking to two, unclaimed chests clearing at the daily server reset.
• Guild economy — guild currency, the guild shop, guild technologies with combat buffs inside character_power, and Guild Gifting (a paid gift pack every guild member receives).
• Guild Showdown — paired weekly matchups Tuesday–Sunday with weighted daily medals, points paid strictly for resource spend, a per-guild activity threshold gating both reward tiers, and the verbatim anti-hopping ruleset, seeded by the seasonal clan-point ladder.
• Guild War — the Sunday combat peak: Tuesday–Saturday preparation with nine automatically selected defenders — the guild's strongest nine by character_power (3 Elite × 3 Stars, 6 Core × 2) — frozen at the end of Preparation, a Sunday battle of limited attacks and three symmetric engagement modes, victory by Stars taken, Honor Coins with a separate war shop, and the source's own forfeit and anti-hop rules.
• The guild week — one rival per week for both modes, paired Monday off the clan-point ladder, with the war battle doubling as Sunday's Showdown scoring.
• The cold-start rules — a four-guild quorum on both GvG modes with a visible, stated open condition, and a per-realm participation floor.
• Two currencies, two shops, no conversion — Guild Coin from donations, dailies and the Showdown into the guild shop; Honor Coin from the War into the war shop; boss and Gifting paying items only.
• A single claim mechanism — every reward the feature produces is a pending claim the player collects by hand, with an expiry, a membership check at claim time, badges at three levels, and idempotent server-side claiming. Nothing in this feature is auto-credited. Weekly-or-rarer claims fall back to mail on expiry (still claimed by hand there); the boss chest, gifts and the Vault are lost.

Explicitly out:

• Guild-scoped quests or a guild daily-quest track.
• Player-uploaded emblems.
• Cross-realm guilds.
• Guild-vs-guild chat, alliance-of-guilds, or any second grouping tier.
• Automatic kicking of inactive members.
• Contribution for helping other members (§11) — it needs a member-visible wait to help with, and our loop has none. First thing to add if F2P members turn out to have no contribution lane.
• Seeded or placeholder guilds on a new realm — the quorum waits instead.

Cuts that are decisions, not omissions

• No 1:1 guild gifting. Friends own personal gifting; Guild Gifting is a whole-roster broadcast, not a personal channel.
• No guild-pair power bonus. Bond and party own that axis; a third stacking source makes power unreadable.
• No guild-exclusive required content. Anything in the guild shop or boss reward accelerates progression; nothing gates it. Exclusivity that becomes necessity is the direct route to obligation and churn.
• No per-guild custom emblems until there is a moderation owner.

TЗ / tech spec

Not implementation — what must exist for product and platform to build it.

Config shape

A new guild section in GameConfig holding only tunables, organised so a designer can balance it without touching content:

• Entity limits — name min/max length, description max length, rename cooldown, guild-tag length and alphabet, emblem catalogue reference.
• Creation — creation price (currency + amount), minimum player level or chapter to create.
• Membership — base member cap, and the cap-per-guild-level table; two cooldowns — a global one after a voluntary leave (default 60 minutes), and a same-guild-only one after being kicked (default a day) — separate knobs; they are not the same policy and are not expected to hold similar values; rank-slot counts per guild level (how many deputies and guards a guild of a given level may have); kick rate limit for ranks below the leader.
• Levels — a guild-level table of { level, required_experience, member_cap }. Flat rows, tunable independently, in the same shape as character_levels.
• Donations — daily donation cap, the per-donation price ladder within a day (first entry free), experience granted per donation, and the donor reward bundle reference.
• Inactivity — member inactive-marker threshold, leader-succession window, guild-dormancy threshold, guild-retirement threshold, and the post-retirement audit-retention window. Five separate knobs; they are deliberately not the same number.
• Clan points — points per qualifying win, which fight types qualify, season length, the season-reward mail templates per band, and the cosmetic season-badge references for the top bands (badges are content, their assignment is config).
• Guild boss — the level table { level, hp_pool, chest_tier }, attempt regeneration interval and bank depth, and the chest-expiry anchor (the daily server reset). No cycle length exists: the ladder does not reset.
• Showdown — the scoring table { action, points } (spend actions only), the per-guild weekly activity threshold, medal weights per weekday, the settlement lockout window, the participation floor per realm-age band, and the reward bundles per tier.
• Guild War — attacks per member per battle phase, Stars per Elite and per Core defender, the three engagement modes as { id, hp_modifier, damage_modifier, stars_on_win }, phase boundaries by weekday, AI reinforcement strength, Vault contents by result, and Honor Coin payouts by result.
• Guild-vs-guild availability — the eligible-guild quorum per realm (default four) and the minimum guild level for GvG entry.
• Discovery — recommended-list size, the activity window defining an "active" guild.
• Join incentive — first-join reward bundle reference.

A separate guild_emblems content collection: { id, asset ref, i18n name }. Content, not balance — it lives alongside skins.

Gating goes in game_config.gatings alongside every other feature unlock, keyed by chapter level; the initial value sits two stages after the Arena gate — provisional by decision, expected to move. The corresponding feature_thresholds entry in the connection auth path must be extended too — otherwise the guild will not appear in cohort-adoption analytics, which for this feature is the whole point.

Backend (conceptual)

New persistent entities:

• Guild — identity (emblem, name, description, tag), level and experience, settings (join type, minimum level), creation time, and the leader reference. Name uniqueness is enforced per realm database; the tag is globally unique by construction — a realm component plus a value the realm allocates locally — so no cross-realm name or tag registry is required and a realm merge cannot produce an ambiguous guild reference.
• Guild membership — the character↔guild link with rank, join time and chat-mute state. A character has at most one. It does not carry clan points — the guild total and the player's personal points live in the season score counters below, so destroying a membership never touches a score.
• Season score counters — the guild's season clan-point total and the player's personal season points: two plain counters, both reset at season rollover. No per-(guild, player) contribution ledger is required. Alongside them the guild's season record — a win/loss tally written by each war result, used as the ladder tiebreak and shown on the profile.
• Guild boss progress — the guild's current level and pooled damage on it, each member's attempt balance and regeneration timestamp, attempts used today per member, and unclaimed chest grants with their expiry. Permanent; nothing here is reset by a schedule.
• Weekly guild pairing — the week's rival for a guild, written once at Monday rollover and read by both the Showdown and the War. One record per guild per week; the two modes never pair independently.
• Showdown scoring — per player per day within a week: points earned, and the guild-daily and guild-weekly aggregates, plus the daily medal ledger. Points are written by the spend actions of the scoring table, so the write path is an accounting hook on existing spends rather than a new gameplay surface.
• War round — the pairing, phase, the nine selected defenders with their locked build snapshots, remaining Stars per defender, attacks remaining per member, Stars taken by each side, the result, and Vault grants with their expiry.
• Guild application and guild invite — pending records with an expiry, and a uniqueness constraint preventing duplicates from the same player to the same guild.
• Guild event log — append-only, chronological, with a retention window.
• Donation record — per player per day (not per membership), enough to render the donation history and enforce the daily cap across guild changes.

New projections, following the existing pattern where a composed read payload is assembled server-side:

• GuildSummary — emblem, name, level, members current/max, required level, join type, and the requesting player's application status. The row shape for every list.
• GuildDetails — all guild fields plus the member list.
• GuildMemberEntry — avatar, nickname, rank, level, last-online, season clan points.

Read paths are request/response pairs (paginated where they are lists), matching how the arena leaderboard and referral list already work: recommended guilds, exact search, guild details, member list, applications, event log, donation history, the two intra-guild leaderboards, the seasonal guild ladder, and today's donation status.

Mutations are client sync events, validated server-side, matching how every other state change already flows: create guild, rename, change description, change emblem, change settings, apply, withdraw application, accept/decline application, invite, accept/decline invite, join automatically, leave, kick, change rank, mute/unmute a member in guild chat, transfer leadership, disband the guild, donate, and claim a reward (one mutation for every claimable, keyed by its id — boss chest, Showdown tier, Showdown milestone, war payout, Vault, season band, gift, first-join incentive).

Behaviour that must exist server-side:

• Claiming is one mechanism, not six. Every reward this feature produces is written as a pending claim record — { owner, source, payload, expires_at, state, mail_on_expiry } — and the claim mutation is the only path that turns one into items. It is idempotent (a retried or double-tapped claim pays once), it re-checks membership for guild-sourced sources at claim time, and it refuses expired records rather than silently paying late. A scheduled sweep resolves what was not claimed, and it is the single place the fallback lives: for a source marked as mail-backed it re-checks membership at that moment and posts the payload to the existing mail path; for the rest it drops the record. Both outcomes write an analytics event, because "expired unclaimed" and "fell back to mail" answer different questions about whether the badges work. Building this once is what makes §19 a rule instead of six near-identical implementations that drift.

• Pending-claim counts ride the player payload so the HUD badge, the tab badges and the Overview block do not each need their own request.

• Every join path runs the same validation — not in a guild, guild not full, level requirement met, and no applicable cooldown active — the global cooldown after a voluntary leave, or the same-guild cooldown after a kick, which blocks only the guild that removed them. Validation runs at accept time, not only at request time. Guild creation checks the global cooldown too; memberships dissolved by disband or retirement set no cooldown at all.

• Accepting any join resolves the player's other pending applications and invites.
• Leader succession runs as a scheduled check, not only on the leader's next login — an absent leader is precisely the case where nothing else will trigger it. It must be idempotent and must never leave a populated guild leaderless.
• Last member leaving retires the guild immediately — an empty guild skips the Dormant stage and goes straight to the Retired path, since there is nobody left who could revive it.
• Donation is atomic: debit, guild experience credit, level-up evaluation with overflow carry, donor reward grant, history write.
• Clan-point award hangs off the existing arena match-end, guarded by the configured qualifying-fight-type list, the both-players-guilded check — read from live state at match end, never from the stored snapshot — and a same-guild exclusion. On a qualifying win, the winner's guild season total and the winner's personal season points each increment by one, atomically. There is no daily cap and no origin check on the ticket spent — bought tickets count, by decision.
• Season-end guild reward eligibility is membership at season close, banded by the guild's final rank. Delivered through the existing weekly-cron + mail path as an unclaimed item — the mail carries the reward, the player claims it (§19).
• Weekly pairing runs once at Monday rollover on the same cron: it reads the clan-point ladder, filters to guilds that clear the GvG level floor and the realm's participation floor, pairs adjacent survivors, and writes one rival record per guild. An odd guild out gets an explicit rest-week record rather than no record — "no rival" and "not paired yet" must be distinguishable in the UI. If the realm is below the eligible-guild quorum, the job writes nothing and both modes report their open condition with the current count.
• Showdown points are an accounting hook on existing spends, not a new action: each spend listed in the scoring table increments the player's daily points and the guild's daily and weekly aggregates in the same transaction that consumes the resource. A spend by a guildless player, or outside a paired week, writes nothing. Daily settlement runs at the lockout boundary and awards the medal.
• War phase transitions are scheduled, idempotent, and each one has a hard side effect: preparation end selects the nine defenders and snapshots their builds in one transaction — rank eligible members by character_power, take the top nine, freeze each one's build, fill any remaining slot with an AI reinforcement. The ordering must be deterministic (power, then join date, then character id) so a replay of the job produces the same lineup; battle end settles Stars, writes the result to both guilds' season records, grants Honor Coins and Vault openings, and expires the previous round's unopened Vaults. Locked snapshots are immutable for the round — later gear changes must not reach them.
• Boss chest expiry runs at the daily server reset and clears unclaimed grants. Attempt regeneration is timestamp-derived rather than ticked, and banks at the configured maximum. Neither job touches guild boss level or pooled damage — there is no reset path for those at all.
• Permission checks are server-side and derive from the §5 matrix, which is the single source of truth. Kicking and muting require the actor's rank to be strictly above the target's; rank assignment is leader-only regardless of rank distance. The kick rate limit is enforced per actor, and rank-slot counts are validated against the guild's level on every promotion.
• Realm merge must rename colliding guilds deterministically (older guild keeps the name), grant the renamed guild a cooldown-free rename, and mail both sides. Merges are scheduled at season boundaries so clan points never need reconciling mid-season.
• Season rollover reuses the existing weekly-cron + mail delivery path — the same machinery the weekly ratings rewards already use — rather than a new scheduler. For offline players the mail waits, unclaimed, until the retention window ends — nothing is credited while they are away.
• Name and description invoke the existing moderation pipeline on write, with the rename cooldown enforced server-side. A support-side force-rename exists for content that slips the write-time filter — it renames the guild, grants a cooldown-free rename, and writes to the event log.
• Account deletion anonymises the deleted player's entries in guild event logs and donation history (nickname replaced with a placeholder); aggregate guild records — experience, level, season totals — are untouched.
• Guild identity in the player payload — the general player-info response carries guild membership status, guild id and tag, rank, the player's season clan points, today's donation state, and the guild's emblem and name, since emblem and name render next to the player on nearly every screen and must not require a second round-trip.
• Analytics events on every meaningful action — guild created, joined (by path: auto / application / invite), left, kicked, donated (with slot index), chat posted, application sent / accepted / declined, leader succession fired, guild retired. Plus the shared-content ones the balance work will need: boss attempt used, boss level cleared, claim granted / expired-lost / expired-to-mail (by source — the three together are the health check on the badge rules), showdown points scored (by action type), daily medal settled, weekly tier paid or withheld for missing the activity threshold, war defenders selected (with the roster size, so a run of AI-filled slots is visible), war attack made (by engagement mode), war result. The withheld-tier event is the one that tells us whether the threshold is calibrated.
• Guild lifecycle transitions (Active → Dormant → Retired) are server-driven on a scheduled check, idempotent, and each writes an event log entry and an analytics event. Retirement dissolves memberships, drops pending applications and invites, removes the guild's season score from the ladder, releases the name but permanently retires the tag (tags are never reissued — they are the stable key for analytics, support and audit), and soft-deletes the entity for an audit window.

UI / Unity / art

• No-Guild screen with three tabs (Rating / Search / Invites), built on the existing player-row anatomy with the emblem in the avatar position.
• Guild screen: header (emblem, name, level, experience bar, member count) plus the tab set — Overview, Members, Donate, Leaderboard, Log, Settings, Applications — with role-conditional tab visibility.
• Create-Guild form with live name validation, moderation feedback, and an emblem grid picker.
• Member row with rank, last-online, inactive marker, and a leader/deputy context menu.
• Donation widget: used / 5, next price, granted experience, donor reward, and the shared donation history list.
• Two intra-guild leaderboards with a pinned self-row, and the seasonal guild ladder.
• Guild chat channel added to the existing chat channel strip; no new chat UI.
• The guild emblem + name chip, mounted on every existing surface that renders a player: profile card, chat message, leaderboard row, arena opponent row, party, friends list.
• All the states listed in ## UX, including the ones that only appear when something has gone wrong.

Art deliveries: the emblem catalogue authored at large size with verified legibility at chat-message size and shape variety sufficient for colour-blind distinction; guild-level frame or banner treatments at milestone levels; the level-up celebration; the guild header background.