Guild

• Name: Guild
• URL: https://docs.guild.xyz/guild
• Category: community-admission middleware / token-gated membership infrastructure / cross-platform governance-control layer
• Summary: Guild is best understood not as a generic community-growth app or Discord bot, but as reusable membership middleware that turns onchain holdings, social-account state, attestations, and custom API checks into continuously synced roles and rewards across community platforms. Its most useful analytical contribution is the split between requirement definition, role logic, reward routing, and platform/account linkage. That makes Guild a valuable comparison point for Snapshot strategy stacks, Census3-style electorate construction, Hats-style role systems, and any governance flow where the real control surface is who defines eligibility and how that eligibility propagates into access, perks, and downstream influence.
• What it does:
  • Lets operators create a guild with one or more roles, where each role has requirements and attached rewards
  • Evaluates requirements across onchain activity, token/NFT ownership, social accounts, Guild-native activity like points, time-based conditions, and external checks such as EAS attestations or custom API calls
  • Combines requirements with configurable logic including AND, OR, X-out-of-Y thresholds, and exclusion rules like “Should not satisfy”
  • Automatically grants and removes role-linked rewards such as Discord roles, Telegram access, points, NFTs, and other gated benefits as eligibility changes
  • Exposes an SDK/API for creating, updating, joining, checking access to, and administering guilds, roles, requirements, rewards, and membership data
• Key claims:
  • The official docs define Guild around three building blocks — Requirements, Roles, and Rewards — which is analytically important because it makes clear that the product’s real primitive is not chat moderation or quests alone, but a policy engine that maps eligibility signals into persistent group structure and benefits.
  • The requirement system is broader than simple token gating. The docs describe onchain activity, social proof, Guild activity, and time-based checks, while separate requirement pages document Ethereum Attestation Service verification and Custom API Call support. That means Guild acts as a middleware layer for composing heterogeneous proofs of belonging.
  • The role-logic layer is the strongest reusable mechanism. Guild supports AND/OR-style combinations, explicit threshold logic like X-out-of-Y, and negative conditions via “Should not satisfy,” so access policy becomes programmable rather than hard-coded to one wallet balance or one Discord role.
  • The docs emphasize continuous syncing: members gain or lose roles automatically as they begin or stop satisfying requirements. That matters because Guild is not only an admission snapshot; it is an ongoing membership-enforcement surface.
  • Rewards show where policy decisions become operational power. Guild routes eligibility into Discord and Telegram access, points, NFTs, secrets, and other rewards, which means the platform sits directly between identity/eligibility signals and practical community privileges.
  • The SDK README makes the operator control plane explicit. It exposes guild creation and updates, admin listing, role creation, requirement creation, reward creation, member retrieval, join, and access-check flows. In practice, the key power is not merely token ownership but who controls the guild config, which external accounts or attestations count, and which integrations are wired into the reward surface.
  • Guild is a strong corpus entry because it helps separate a frequently flattened layer in crypto governance: between high-level “community” rhetoric and the lower-level middleware that actually decides who gets admitted, who receives perks, and which offchain platforms inherit those decisions.
• Whitepaper: No canonical standalone whitepaper or litepaper surfaced in this pass. The strongest primary materials reviewed were the official docs plus the public interface and SDK repositories; see ../whitepapers/guild-primary-sources-2026-05-11.md.
• Sources:
  • https://docs.guild.xyz/guild
  • https://docs.guild.xyz/guild/how-guild-works
  • https://docs.guild.xyz/guild/how-to-setup-requirements
  • https://docs.guild.xyz/guild/how-to-setup-rewards
  • https://docs.guild.xyz/guild/how-to-setup-requirements/custom-api-call
  • https://docs.guild.xyz/guild/how-to-setup-requirements/eas
  • https://raw.githubusercontent.com/guildxyz/guild.xyz/main/README.md
  • https://raw.githubusercontent.com/guildxyz/guild-sdk/main/README.md

Internal linkages

• Closest tokenized-role analogue: hats-protocol.

• Closest electorate-construction peer: census3.

• Best downstream community-control sibling: common.

• Last reviewed: 2026-05-25 UTC