CollabOS / Docs
Docs/Community & Discord/Community Verification Guide

Community & Discord

Community Verification Guide

Community Verification helps Discord communities verify members through wallets and on-chain ownership, then automatically manage Discord roles.

Start with one rule and one test member. Confirm the result before posting a verification panel for the whole community.

What you can use Community Verification for

  • Give NFT holders a Discord role.
  • Give trait holders a special role, such as a Gold Background role.
  • Verify the owner of a specific ERC721 token.
  • Verify ERC1155 holders by quantity or ERC20 holders by token amount.
  • Let members check eligibility from Discord and keep roles updated with revalidation.

Before you start

  1. Confirm your workspace has Community & Discord access enabled.
  2. Connect the CollabOS bot to your Discord server and sync its roles and channels. See Connect a Discord server.
  3. Give the bot Manage Roles permission. Move each target role below the bot's highest role in Discord's role settings.
  4. Ask your test member to verify an EVM wallet in CollabOS.
  5. Confirm the chain you need is available in the workspace's verification chain picker. If it is missing, ask your platform administrator to check chain availability.

Open Community & Discord and select NFT Verification to manage rules and panels. Workspace owners, admins, leads, and managers can configure verification; members manage their own wallets and delegated vault declarations.

Some checks depend on OpenSea, delegate.xyz, or the selected chain's availability. A temporary outage can prevent a check from completing even when the member owns the required assets.

Step 1 — Verify member wallets

Ask each member to open their wallet settings in CollabOS and verify the EVM wallet that holds their assets. Saving a mint wallet address alone is not enough.

Signed wallet verification is the normal method: the member connects their wallet and signs the verification message. Where OpenSea profile proof is available, the member can instead request a proof challenge, place its code in the wallet's OpenSea profile bio, and submit it for verification before it expires.

Revoked wallets stop being used in future checks. If a member changes wallets, they should verify the new wallet before checking eligibility again.

Verification proves control of a wallet. It does not automatically grant a role until a rule checks that wallet.

Step 2 — Create a verification rule

  1. Open NFT Verification and choose New Rule.
  2. Choose the rule type and supported chain.
  3. Give the rule a recognizable name, such as Collection Holders.
  4. Enter the collection or token contract address on that chain. Use the contract address, not a wallet address or OpenSea page link.
  5. Choose the token standard and enter the requirement using the examples below.
  6. Choose the Discord role, keep the rule Active, and save it.

NFT collection rule

Example: Give @Holder to anyone holding at least 1 NFT from a collection.

Choose NFT ownership, select ERC721, and use the collection ownership check. Enter the collection contract, set Minimum quantity to 1, and choose @Holder. The rule counts eligible NFTs from that collection across the member's verified wallets and any confirmed delegated vaults.

Trait rule

Example: Give @Gold Trait to anyone holding an NFT with Background = Gold.

Choose the NFT trait rule type and a supported ERC721 collection. Enter the collection contract, trait type Background, and trait value Gold. Set the minimum matching quantity to 1 and choose @Gold Trait. Use the trait names and values shown by the collection's trait provider; owning a different trait does not qualify.

Specific ERC721 token

Example: Give @1/1 Owner only to the wallet holding token ID 7.

Choose NFT ownership and ERC721, select the specific-token ownership check, enter the collection contract and token ID 7, and choose @1/1 Owner. A different token from the same collection does not meet this rule.

ERC1155 token rule

Example: Give @Badge Holder to anyone holding at least 3 of ERC1155 token ID 12.

Choose NFT ownership and ERC1155. Enter the contract address, token ID 12, and Minimum quantity 3, then choose @Badge Holder. Holding two copies, or three copies of a different token ID, does not meet this requirement.

ERC20 token rule

Example: Give @Token Holder to anyone holding at least 1,000 tokens.

Choose ERC20 token ownership and enter the token contract. Enter 1000 as the Minimum token amount and choose @Token Holder. You can leave Token decimals blank for CollabOS to read them from the contract; if you enter decimals, confirm them against the token's published details. An incorrect decimals setting changes how the amount is interpreted.

Save the rule, then test a member with a known balance before sharing it with the community.

Step 3 — Test and sync a member

  1. Find the saved rule and open its manual sync action.
  2. Enter the member's CollabOS user ID in User ID, then choose Sync user. This field is not their Discord user ID.
  3. Review the qualification result and role action. Use Verification History if you need to review the check later.

Qualified members receive the role, or keep it if they already have it. A not-qualified member may lose a role managed by verification, subject to protected-user and shared-role safeguards. A temporary unavailable check fails safely and should not remove an existing role.

If the role is not assigned, check the member's verified wallet, the contract and chain, bot Manage Roles permission, and Discord role hierarchy. The bot cannot manage roles above its own highest role. Chain or provider availability can also prevent the check from completing.

Step 4 — Add a Discord verification panel

Panels are the easiest way for members to trigger verification themselves.

  1. Find Discord Verification Panels on the verification page and create a panel.
  2. Give it a clear title and instructions, such as Check your holder roles.
  3. Save it, choose the Discord channel, and post the panel. Confirm the bot can send messages there.
  4. Ask your test member to click the verification button.
  5. Confirm the member receives a private response with their results and any role changes.

Members use the button to check current eligibility; posting a panel does not grant roles by itself. The private summary does not expose wallet proof details or delegated vault addresses. Disable the panel when you no longer want members to use it.

Step 5 — Keep roles updated with revalidation

Manual sync checks a selected member and rule. Manual revalidation rechecks tracked members and rules together when you need a broader update.

  1. Open Automatic Revalidation on the verification page.
  2. Run a manual revalidation and review the run summary and history.
  3. For an ongoing community, enable scheduled revalidation, choose the interval and available limits, and save the settings.
  4. Check the latest run after the scheduled time to confirm it completed.

Run revalidation after a mint once members have verified their wallets and checked eligibility, or after changing a rule's requirements. Schedule it for communities that need regular ownership checks. Roles are updated when checks run; an asset transfer does not immediately change a role.

Temporary provider or chain connection failures should not cause unsafe removals. Review unavailable results and try again when the service recovers.

Managing exceptions

Protected users

Use Protected Users for staff, partners, or another deliberate exception who should not lose verification roles automatically.

Add the person's Discord user ID, include a reason or note if useful, and save. You can edit or remove the entry later. Protection prevents automatic role removal; it does not fake qualification or grant a role the person has not earned. A protected member can still appear as Not qualified in history.

Blocked tokens

Use Blocked Tokens to prevent a specific NFT/token ID from counting, for example when an asset is stolen, compromised, burned, or otherwise disqualified by your community's policy.

Choose the chain, enter the collection contract and token ID, and add a reason if useful. Check all three identifiers carefully. To change them later, remove the old block and create the correct one; only the reason and note can be edited on an existing block.

Blocks apply to NFT collection, specific ERC721, ERC1155, and trait checks. They do not affect ERC20 rules. Blocking an asset does not remove a wallet or role immediately: the next sync, panel check, or revalidation applies the exclusion. Removing a block makes the asset eligible to count again; it does not grant a role by itself.

Reviewing history

Open Verification History to review recent checks. Filter by Discord user ID or rule ID, or narrow the results by trigger, outcome, or action. Use Load more to review older available entries.

For a member who expected a role, look for:

  • Qualified or Not qualified: whether the requirement was met.
  • Role granted, removed, or already present: what happened to the role.
  • Unavailable: the check could not be completed safely.
  • Protected removal skipped or Shared role preserved: why a negative result did not remove the role.

History helps explain manual sync, Discord panel checks, and manual or scheduled revalidation. It shows safe summaries, not sensitive wallet proof details, profile bios, raw provider errors, or vault addresses.

Using the /floor bot

Members can check any available OpenSea collection with:

/floor collection:<opensea-slug>

For example:

/floor collection:azuki

Use the collection's OpenSea slug, not its contract address or full page URL. The reply shows floor price, 24h volume, 24h sales, and tracked 24h floor change when available. Data comes from OpenSea.

To set a shortcut for your community:

  1. Open Floor Stats Bot on the verification page.
  2. Enable default /floor and enter the default OpenSea collection slug.
  3. Optionally add a display name or image override, then save.
  4. Run /floor in Discord to check that default collection.

/floor collection:<slug> works for any OpenSea collection and overrides the default. The default is only used when no collection is supplied; disabling it does not restrict explicit collection lookups.

The first lookup may show Tracking started for 24h change. A later lookup needs enough matching data from around a day earlier to show the change; two lookups a few minutes apart are not a 24h comparison. Missing stats may appear as a dash.

Using delegated wallets

Delegated wallets are useful when a member keeps NFTs or tokens in a vault/cold wallet but uses a verified hot wallet for community access. The vault must have delegated access to that hot wallet through delegate.xyz.

  1. The member verifies their hot wallet in CollabOS.
  2. The member creates the appropriate delegation separately on delegate.xyz.
  3. In Delegated Wallets, the member selects the chain, enters their vault/cold wallet, and chooses the verified hot wallet receiving delegation. A label is optional.
  4. The member adds the declaration and chooses Test to check delegation against active rules on that chain.
  5. The member uses a verification panel, or asks a manager to sync them. CollabOS counts the vault only when delegate.xyz confirms delegation for that rule.

A successful declaration test confirms delegation for at least one active rule; it does not guarantee the vault holds enough eligible assets or grant a role by itself. If no active rules are available on the chain, create the relevant rule before testing again.

CollabOS does not create delegate.xyz delegation. It only checks delegation, and the vault wallet does not sign inside CollabOS. The hot wallet must remain verified. Delegation extends eligibility; it does not replace normal wallet verification. Disabling or removing a declaration in CollabOS does not change delegate.xyz settings.

Wallet-wide or contract-wide delegation can support the appropriate collection, trait, and token rules. An ERC721 token-specific delegation supports the matching specific-token rule, not collection or trait checks. ERC1155 and ERC20 delegation amounts limit how much can count. Members manage their own declarations; managers do not add vaults for other users.

Common issues and fixes

Role was not granted

  1. Confirm the member has an active verified EVM wallet, rather than only a saved mint wallet.
  2. Check the rule's contract, chain, token standard, token ID or trait, and minimum requirement.
  3. Check the bot has Manage Roles permission and its role is above the target role.
  4. Check chain and provider availability.
  5. Run manual sync for the member and review the result in history.

Role was not removed

Check whether the member is protected, another active rule still supports the same role, or the result was Unavailable. A role manually assigned outside CollabOS may also be preserved. Review history before changing protections or removing a role yourself.

/floor does not work

Use a valid OpenSea slug, such as /floor collection:azuki. If you use /floor without a slug, configure and enable a default collection first. If the collection is correct but unavailable, check OpenSea availability and retry later.

Delegated wallet is not qualifying

  1. Confirm the receiving hot wallet is still verified in CollabOS.
  2. Confirm the vault delegated to that exact hot wallet on delegate.xyz.
  3. Check the declaration uses the rule's chain, and that the delegation covers its contract or token scope.
  4. Use Test on the delegated wallet and review the result.
  5. Confirm the rule supports that delegation scope and the vault holds enough eligible, unblocked assets. Token-specific ERC721 delegation does not qualify a trait rule.

If delegation is temporarily unavailable, direct wallet qualification still works. When a delegated check could change an otherwise-negative result, CollabOS reports Unavailable to preserve role safety.