# Welcome to Bocto! ## Your All-in-One Web3 Community Bot! Discover the power of NFT statistics, role verification, and marketplace insights right inside your **Discord** server. From **Ethereum** to **Solana**, **OpenSea** to **MagicEden** – **Bocto** brings the Web3 universe to your community in real time. ## Communities trust Bocto to: * Provide **automated NFT updates**. * Offer **secure token-gated roles**. * Protect your server with **smart moderation**. * Connect with **major marketplaces** like **OpenSea**, and **MagicEden**. # Creating/Deleting User Profile ## Creating User Account To start creating your Bocto user account, click the Login button on the top-right of the Bocto main page.

The Discord authorization pop-up will appear.

When Bocto is authorized, the Login button will change to display your Discord PFP with a small chevron icon; click on it.

In the appeared menu, click on Account:

Congratulations! Your Bocto user account has been created!

Now check the Account Overview page. ## Deleting User Account If you decided to delete your Bocto User Account, move to the very bottom of the Profile tab on the Account page to the **Danger Zone** section and click on the `Delete My Account` button.

Then, confirm the action in the pop-up window that appears. All your data will be deleted.

All your data will be deleted, and you will be logged out and redirected to the main page.

# User Profile Overview ## Account Tab. This tab consists of several main blocks: * Personal details management section (displays on the user's public profile page). * Social accounts management section (also displays on the user's public profile page). * Danger Zone, where you can [delete your Bocto user account](/user-profile/creating-deleting-user-profile#deleting-user-account).

## Wallets Tab. This tab contains the list of all your added wallets, as well as tools to add and remove wallets.

## Roles Tab. In this tab, you can see a list of all roles assigned to you via Bocto, if any, on the servers where Bocto is used.

Click on the `Roles` button in front of the desired server to see the exact roles that were assigned to you by Bocto on that server.

## Premium Tab. This tab is intended for server owners and, in the future, will contain information and tools for managing Bocto premium ties and subscriptions. This tab is currently unavailable. ## Billing Tab. This tab is also intended for server owners only and, in the future, will contain the billing history. This tab is currently unavailable. # Adding/Removing Wallets ## Adding Wallets. Before you will be able to get the holder's roles on the servers with **Bocto** verification, you need to add your wallets to the **Bocto** database. For this, visit the **Wallets** tab on the user's account page.

### Direct Connection Method. This method of adding a wallet requires its direct connection to the **Bocto** website and a read-only transaction signature to prove that you really control this wallet. When it's done, we remember it and disconnect your wallet from our website. It's a simple and versatile workflow that is used by other token-gated bots as a best practice. {% hint style="warning" %} However, as long as we're getting temporary full access to your wallet, this requires your trust. {% endhint %} The main advantage of this connection method, besides its simplicity, is that it works with all supported EVM blockchains. That is, if the server owner has their collection on the blockchain other than **Ethereum**, **Polygon**, or **Solana**, you will not have any other option to get verified. To use this verification method, follow this guide: {% content-ref url="/pages/f6GjNxg5j8Sl163Y588p" %} [Direct Connection Method](/user-profile/adding-removing-wallets/direct-connection-method) {% endcontent-ref %} ### Indirect Verification Methods. These methods of adding a wallet don't require directly connecting the wallet to the **Bocto** website or signing the transaction. The main disadvantage of this type of wallet ownership verification is that it only works with **Ethereum**, **Polygon**, and **Solana**. To use this verification method, follow this guide: {% content-ref url="/pages/FI1xODAE6VaWJWXWpIFA" %} [Indirect Verification Methods](/user-profile/adding-removing-wallets/indirect-verification-methods) {% endcontent-ref %} ## Removing Wallets. To remove (disconnect) your wallets, use the trash bin buttons in front of the chosen wallet in the wallets list:

If you don't see these buttons because of a narrow screen, just press and hold the cursor or a finger (on a mobile device) on any place in the **Connected Wallets** section and drag it to the right:

# Direct Connection Method ## Adding the EVM chain wallet via MetaMask. ### Establishing a connection. Before you start, ensure that you are logged in to your **MetaMask** and that the right wallet address and chain for connection are selected. Then, click the `Connect Wallet` button.

The **Connect Wallet** extension pop-up window will appear. Choose the wallet extension (for desktop) or a wallet app (on mobile) you want to use to connect with. For the EVM chains, we recommend using **MetaMask**. {% hint style="danger" %} You can also try other extensions/apps from the list, but we can't guarantee a successful experience in this case! {% endhint %}

At the next step, choose **EVM Networks.**

At this step, **MetaMask** will offer you to confirm that you really want to connect your wallet to the **Bocto** website. Click `Connect` to confirm.

Great! **Bocto** has just detected your wallet! But hasn't bound it to our database yet! ### Connection management. The connection is established successfully; however, take a closer look at the marked section below and double-check the Chain and Address values. If everything is correct, click the `Bind Wallet` button to finalize the wallet addition process.

If, for example, you've noticed that the chain is wrong, click the `Change Network` button, and the pop-up window with the list of EVM chains will appear. In this example, let's choose **Polygon**.

Now we see **Polygon** as the value for the Chain:

If you've noticed that the wallet is wrong, you have to click the `Decline Binding` button, choose the actual address in your **MetaMask**, and restart the process from the beginning. If everything is correct, click the `Bind Wallet` button to finalize the wallet addition process. You will see your newly added address in the **Connected Wallets** section:

{% hint style="success" %} Now you are good to go to the server where you want to receive the holder roles and initiate the [user verification process](/user-profile/user-verification-process). {% endhint %} ## Adding Solana wallet via Phantom. ### Establishing a connection. Before you start, ensure that you are logged in to your **Phantom** and that the right wallet address for connection is selected. Then, click the `Connect Wallet` button.

The **Connect Wallet** extension pop-up window will appear. Choose the wallet extension (for desktop) or a wallet app (on mobile) you want to use to connect with. For **Solana**, we recommend using **Phantom**. {% hint style="danger" %} You can also try other extensions/apps from the list, but we can't guarantee a successful experience in this case! {% endhint %}

{% hint style="danger" %} **Be advised!** In some browsers, for example, **Brave**, it might happen that **Phantom** doesn't support **Solana**! Look at the blockchains icons near **MetaMask** and **Phantom**. If you are facing this exact case, try a different browser. {% endhint %}

If this is not your case, then, at the next step, choose **Solana****.**

At this step, **Phantom** will offer you to confirm that you really want to connect your wallet to the **Bocto** website. Click `Connect` to confirm.

If you've noticed that the wallet (or even the network, because of the browser bug mentioned earlier) is wrong, you have to click the `Decline Binding` button, choose the actual address in your **Phantom** (and use a different browser if needed), and restart the process from the beginning. If everything is correct, click the `Bind Wallet` button to finalize the wallet addition process. You will see your newly added address in the **Connected Wallets** section:

{% hint style="success" %} Now you are good to go to the server where you want to receive the holder roles and initiate the [user verification process](/user-profile/user-verification-process). {% endhint %} # Indirect Verification Methods ## Self-Transaction Method. **Self-transaction** is just a regular transaction when you send crypto like you always do, but with a slight specificity: instead of someone else's wallet, you send crypto to the same wallet from which you send it (to itself). It is the same as you, for example, want to send money from your credit card to the same credit card. In a fiat world, it sounds like nonsense, but in crypto, it is possible and even reasonable, because we can track the blockchain, find this transaction, and thus, ensure that you really control the wallet. At the same time, you do not need to connect your wallet directly to the **Bocto** website and sign any transactions on it. Sadly, this method only works with **Ethereum**, **Polygon**, or **Solana**. In the example below, we will use **MetaMask**; however, you can use any other EVM-compatible wallet extension/app (for **EVM** blockchains) or **Phantom**, or any other Solana-compatible wallets for the **Solana** blockchain. ### Initiating Verification on the Bocto's Side. Before you start, ensure that you are logged in to your **MetaMask** (or other EVM-compatible wallet extension/app) and that the right wallet address is selected. Then, click the `Add Wallet` button.

The Add Wallet pop-up window will appear. In the **Chain** dropdown, choose the blockchain where the NFTs, the ownership of which you want to verify, are being hosted. In our case, it will be **Polygon**:

In the **Verification Type**, choose **Self Transaction**:

At the next step, the **Wallet Address** field will appear. Paste your wallet into this field, wait for a few seconds until **Bocto** checks if the address format is valid, and when the `Add Wallet` button becomes active, click on it:

The Add Wallet pop-up window will be closed automatically, and the Wallet Verification in Process section with the details of the operation will appear. Double-check if the blockchain and address were set correctly. If you've noticed that you had been mistaken when filling out the form, cancel the operation by clicking on the `Decline Binding` button. If everything is correct, copy the number from the special field by clicking on the **Copy** icon:

### Providing the Self-Transaction via Crypto Wallet. Now, open your wallet (in our case, it will be **MetaMask**) and ensure that the desired wallet is active. Then, click on the appropriate coin (as we are connecting a wallet on **Polygon** in this example, it will be, of course, **POL**):

Now click on the **Send** button:

On the next step, do not fill the **To** address field, but scroll down and find the same address as above in the list instead:

Now check again that the addresses in the **From** and **To** fields are the same, paste the number you copied a few steps ago, and click **Continue**.

Confirm the operation:

Now wait until the transaction changes status from Pending to Confirmed:

### Finalizing Verification on the Bocto's Side. When it's done, go back to the Wallets tab on your **Bocto** profile page, and click the `Initiate Check` button:

If your self-transaction was correct and didn't mess anything up, your **Polygon** wallet will appear in the list:

{% hint style="success" %} Now you are good to go to the server where you want to receive the holder roles and initiate the [user verification process](/user-profile/user-verification-process). {% endhint %} ## Marketplace-Bio Method. The essence of this verification method is that you add a special signature to your user bio on the desired marketplace, and, as long as this is only possible if you are authorized on that marketplace with your wallet, we can ensure that you control this wallet. In the example below, we will connect the **Ethereum** wallet and use the account on **OpenSea** for this purpose because it is currently the only marketplace whose API provides an endpoint with the user's bio. However, in the future, we are going to add some new marketplaces. ### Initiating Verification on the Bocto's Side. Before you start, ensure that you are logged in to your **MetaMask** (or other EVM-compatible wallet extension/app) and that the right wallet address is selected. Then, click the `Add Wallet` button.

In the **Verification Type**, choose **Marketplace**:

At the next step, the **Marketplace** and the **Wallet Address** fields will appear. In the **Marketplace** dropdown, choose **OpenSea**:

In the **Wallet Address** field, paste your wallet, wait for a few seconds until **Bocto** checks if the address format is valid, and when the `Add Wallet` button becomes active, click on it:

The Add Wallet pop-up window will be closed automatically, and the Wallet Verification in Process section with the details of the operation will appear. If, for some reason, you've changed your mind, cancel the operation by clicking on the `Decline Binding` button. If everything is OK, copy the text from the special field by clicking on the **Copy** icon:

### Adding the String to the OpenSea Bio. Now, being logged in to the **OpenSea** account via the wallet with the NFTs whose holder you want to verify, click on the user avatar:

You will be redirected to your **OpenSea** profile. Here, click on the **Pencil** icon to start editing your personal information:

In the **Bio** field, paste the text you copied a few steps ago, and click **Save**.

### Finalizing Verification on the Bocto's Side. When it's done, go back to the Wallets tab on your **Bocto** profile page, and click the `Initiate Check` button:

If your self-transaction was correct and didn't mess anything up, your **Ethereum** wallet will appear in the list:

{% hint style="success" %} Now you are good to go to the server where you want to receive the holder roles and initiate the [user verification process](/user-profile/user-verification-process). {% endhint %} # User Verification Process ## Verification Pipeline. ### Step 1 - Initiating Verification. To claim the roles on the server with **Bocto**, look for the corresponding channel that contains this widget and click the `Start Verification` button.

### Step 2 - Creating Bocto User Profile (Optional). If you don't have a **Bocto** user profile yet, this message will appear:

To create the profile and add wallets, click the `Click here to log in` button to visit the **Bocto** website and follow this guide: {% content-ref url="/pages/cgD0Sey6R4Xj06pwkxpO" %} [Creating/Deleting User Profile](/user-profile/creating-deleting-user-profile) {% endcontent-ref %} Then come back and click the `Start Verification` button again. ### Step 3 - Adding User Wallets (Optional). This time, **Bocto** will ask you to add wallets if you didn't do it right after creating your profile:

To add wallets, click the `Add Wallet from Dashboard` button to visit the **Bocto** website one more time and follow this guide: {% content-ref url="/pages/CBwJtCLYSkRrlYQHKCAb" %} [Adding/Removing Wallets](/user-profile/adding-removing-wallets) {% endcontent-ref %} Then come back, scroll up to the very first embed, and click the `Start Verification` button again. ### Step 4 - Assigning Roles. Now you will see this picture - **Bocto** is running a scan across all your added wallets:

And when it finishes, you will see the embed with the scan summary, where: * **New Roles Added** - **Bocto** roles added during the current verification session. * **Roles Removed** - **Bocto** roles removed during the current verification session. * **Current Roles** - All **Bocto** roles you currently have as a result of all verification sessions.

## Verification Frequency. For manual user-initiated verification (the one that was described above), there are no frequency limits, just a 1-minute cooldown. This means that if, during the day, you buy several NFTs of the projects that use **Bocto** verification on their servers, you can initiate the verification process again and again on every new (or even the same) server to renew your holder status. **Bocto** also uses automatic and manual server owner-initiated verification, the frequency of which depends on the selected premium plan. You can see the details [here](/plugins/verify-roles/introduction#capabilities-comparison). That means that if getting roles is not urgent for you, **Bocto** will automatically monitor your holder's status in the background, checking your wallets at regular intervals. And yes, that means you don't even need to initiate verification yourself - eventually, **Bocto** will assign (or remove) the appropriate roles on all associated servers anyway. # Core Features | Feature | Description | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [**Verify Roles**](/plugins/verify-roles) | Assign roles based on NFT ownership or token balance | | [**NFT Tracker**](/plugins/nft-tracker) | Track your NFT collection mints, listings, and sales | | [**NFT Stats**](/plugins/nft-stats) | Create channels that automatically update with real-time NFT stats (floor, volume, sales) | | [**Guard**](/plugins/guard) | Protect your community from suspicious links, embeds, and users with transparent profile pictures | | [**Mini Games**](/plugins/mini-games) | Entertain your community with simple activities like daily GM word streaks and reward the automatically choosen winners | | [**Utilities**](/plugins/utilities) | Use simple and handly tools to track your user activity and get their addresses for rewards easily if they were verified via [Verify Roles](/plugins/verify-roles). | | **Task Manager** *(Coming Soon)* | Simple, team-focused task lists managed inside Discord | # Chains & Marketplaces ## Supported Chains and Token Types. ### Supported EVM Chains. The so-called **EVM** chains are a big family of blockchains, compatible with the [Ethereum Virtual Machine](https://ethereum.org/developers/docs/evm/). They can have **L2** (Layer 2) and even **L3** (Layer 3) subchains of a Layer 1 blockchain, like **Ethereum** itself, and use some different mechanisms, but their standards and core approach are very similar. This is why we position them separately in this documentation. Below is a list of the **EVM** chains we currently support:

L1 EVM Chains	L2 EVM Chains	L3 EVM Chains
Ethereum `stable`	Arbitrum `beta`	ApeChain `beta`
		Xai `beta`
	Base `testing`	Degen Chain `beta`
	Blast `beta`
	Linea `beta`
	Mantle `beta`
	Mode `beta`
	Optimism `beta`
	Zora `beta`
Polygon `stable`
Abstract `beta`
Aurora `beta`
Avalanche `beta`
Berachain `beta`
BNB Smart Chain `beta`
Celo `beta`
Cronos `beta`
Fantom `beta`
Gnosis `beta`
Moonbeam `beta`
Moonriver `beta`
Ronin `beta`
Sei `beta`

### Other Supported Chains. Here is a list of other (non-EVM) **Layer 1** blockchains we currently support:

L1 Chains	L2 Chains	L3 Chains
Solana `stable`

{% hint style="warning" %} **Legend.** The `stable` status means this blockchain integration has been tested numerous times with all applicable plugins by the community and us, and works stably. The `testing` status means this blockchain integration is currently showing good results in our internal testing, but hasn't been tested by the community yet. The `beta` status means we haven't tested this blockchain integration yet, so the declared plugin features might not work with it as they should. {% endhint %} ### Supported Token Types. In this guide, we will use the **Collectibles NFT collection type** and the **Editions NFT collection type** terms because, unlike classic ERC-721 (**Collectibles**, aka **1 of 1** or **One of its type NFTs**) and ERC-1155 (**NFT Editions**) **EVM** contract standards, **Solana** (and other blockchains) has the same conceptual NFT contract types, however the standard names they use are always different. For the same reason, we will use the **Coin** term to describe the custom token contract type independently of the chain. The table below lists contract types and their corresponding standards as they are named on the blockchains we currently support.

Chains and Standards	Collectibles	Editions	Custom Tokens (Coins)
EVM chains	ERC-721	ERC-1155	ERC-20
Solana	Metaplex NFT	Metaplex FT	SPL Token

## Supported Marketplaces.

Plugin	Feature	Marketplace
Verify Roles	OpenSea-Based Roles	`OpenSea`
Verify Roles	Specific Collectibles NFT Traits-Based Roles	`OpenSea` `MagicEden`
NFT Tracker	Discord Listigs and Sales	`OpenSea` `MagicEden`
NFT Stats	Sidebar Widget	`OpenSea` `MagicEden` `LooksRare`
NFT Stats	Sidebar Widget	`OpenSea`

# User Dashboard Manage everything through the Bocto Dashboard: * Connected Wallets (Ethereum, Solana, Polygon) * Server Overview * Plugin Settings * Collection Management > 🎮 Example Connected Wallets\ > Polygon: `0xF9e8...87b`\ > Solana: `Bsam2z...JBKd` # Use Cases * **NFT Projects**: Automate floor updates, verify holders for gated channels * **DAOs**: Role verification based on token holdings * **Communities**: Moderate with built-in Guard and link protection # Support & Community Need help or want to vibe with other Octo frens?\ Join our community: * [Discord Server](https://t.co/cQCLjqiJRD) * [Twitter](https://x.com/BoctoWeb3) # Legal & Info * [Documentation](https://docs.bocto.octopeeps.com) * [Privacy Policy](https://bocto.octopeeps.com/en/contents/privacy-policy) * [Terms & Conditions](https://bocto.octopeeps.com/en/contents/terms-and-conditions) # Setup on Server ## Initialization process. ### **Step 1.** To start the setup process, click **Add to Discord** or **Login with Discord**/**Login** (Desktop/Mobile app version) button. You will anyway be redirected to the **Discord** Login pop-up window.

### **Step 2.** If you used the **Login with Discord**/**Login** button, you will see your **Discord** avatar icon (and your **Discord** name on the desktop version). Click it to expand the main user menu and select **Dashboard** - you will be redirected to the **Dashboard** page with the list of the servers (guilds) you manage as a server owner or an admin.

### **Step 3.** On the **Dashboard**, click the **Setup on Server** button on the desired server card to launch the bot initialization process.

In the appeared **Discord** pop-up window, you will see that the server you want to install **Bocto** to is already chosen from the list. Just press **Continue**.

In case you've clicked **Add to Discord** button on **Step 1**, **Step 2****,** and **Step 3** will be skipped, and, after being logged in to **Discord**, you will then see the next page in the same **Discord** pop-up window, where you need to choose the server you want to install **Bocto** to manually. Select one and press **Continue**.

### **Step 4.** Grant all the permissions required and click **Authorize**. **Note:** Don't uncheck any boxes if you don't want to encounter problems with some of the bot's features in the future! A comprehensive list of plugins and permissions they use is provided at the end of this page in the [**Permissions usage**](#permissions-usage) section.

### **Step 5.** After that, the initialization process will start immediately, and you will see its progress in real-time. Usually it takes no longer than 10 seconds.

When the initialization process is finished, you will be automatically redirected to the **Settings** page. Here you will see the **#hub** and the **#alerts** channel that were automatically created and set up for you during the initialization. Also, after the initial setup, there will always be the main **red** (critical) alert, which says the **Bocto** position in the roles hierarchy on your server is not high enough to manage users.

In the **Bocto**** ****#hub** channel, you will see the info embedded message with a link to the **Dashboard**. Also, all news and updates about new plugins and features will be posted here.

In the **Bocto**** ****#alerts** channel, you will see the same critical alert warning you about insufficient **Bocto** position in the roles hierarchy. All other alerts about insufficient permissions, if any, will be posted here.

### **Step 6.** Move to the **Roles** managing section in **Discord** and lift the bot in the roles list closer to the top. The best but not obligatory position is in the top 3. The main demand is that **Bocto** should be higher than any role he is going to manage (for example, assigning roles via the **Verify Roles** or **Guard** plugin). When done, save changes.

In the **#alerts** channel, you will see that the issue is resolved. We are now good to go!

### **Step 7.** Go back to the **Settings** page in the **Dashboard**, refresh the page (**F5** on your keyboard), and you will see the **green** message. Now you can move to the plugins list by pressing the **All Plugins** button. **Note:** The **All Plugins** button will not be clickable until you have a **red** alert!

## UI alerts indication. If you enter the **Bocto**** Dashboard** and see an **amber** dot on a server card, it means there are issues with **Bocto** permissions on this server.

On the server management page, you will also see this alert on the **Global Settings** button as an **amber** label with a counter that reflects the number of notifications.

On the mobile version, to find the button (and the alert label), you need to expand the sidebar first by clicking on a hamburger icon, which will, by the way, be provided with the same **amber** alert dot.

Here's what a list of different alerts might look like if **Bocto** has multiple permission issues on your server.

## Permissions usage. Below is a comprehensive list of permissions that **Bocto** currently requests, with explanations of which plugins use each permission. * Manage Roles (Verify Roles, Guard) * Manage Channels * Ban Members * View Channels * Send Messages * Send Messages in Threads * Create Public Threads * Create Private Threads * Manage Messages * Manage Threads * Embed Links * Attach Files * Read Message History * Add Reactions * Pin Messages * Connect # Verify Roles {% content-ref url="/pages/AGpDiWG00CGgqWkjlx66" %} [Introduction](/plugins/verify-roles/introduction) {% endcontent-ref %} {% content-ref url="/pages/Y2dpDzGAgNOz5SATeg1P" %} [Verification Rules](/plugins/verify-roles/verification-rules) {% endcontent-ref %} {% content-ref url="/pages/UPTCtJiavFhhnikhwHrN" %} [Verification Channel Setup](/plugins/verify-roles/verification-channel-setup) {% endcontent-ref %} # Introduction ## Overview. **Verify Roles** is a plugin that provides your **Discord** server with the **Token Gate** functionality, allowing you to create various verification rules and flexibly assign specific roles to your holders. {% hint style="warning" %} For a better understanding of the terms below, read the [Supported Token Types](/basics/chains-marketplaces#supported-token-types-chains) section before. {% endhint %} ## Verification Rule Types. ### Collectibles Contract-Based Roles. Use this rule to assign a specific role to your **Discord** users, regardless of the quantity of NFTs from a particular **Collectibles or Editions NFT collection type** they own. Works for [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains) and **Solana**. ### Collectibles OpenSea-Based Roles. Use this rule to assign a specific role to your **Discord** users, regardless of the quantity of NFTs from a specific **Collectibles type NFT collection** they own. Almost the same as the **Contract-Based Roles** rule, but it works via **OpenSea** [Collection Slug](/appendix/getting-collection-slug-symbol), which makes this rule type work with the collections based on any chain supported by **OpenSea**. ### Collectibles Quantity-Based Roles. Use this rule to assign a specific role to your **Discord** users based on a certain number of NFTs from a particular **Collectibles NFT collection type** they own. Works for [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains) and **Solana**. ### Specific Collectibles Traits-Based Roles. Use this rule to assign a specific role to your **Discord** users based on a specific trait of an NFT from a particular **Collectibles NFT collection type** they own. Works for **OpenSea** and **Magic Eden** (curently only **Solana**). ### Specific Collectibles Token Id(s) Based Roles Use this rule to assign a specific role to your **Discord** users based on the specific token ID(s) from a particular **Collectibles NFT collection type** they own. Works for [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains) and **Solana**. ### Specific Editions Token Id(s) Based Roles. Use this rule to assign a specific role to your **Discord** users, regardless of the quantity of NFTs from a particular **Editions NFT collection type** they own. Guaranteed to work with the [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains). Didn't test on **Solana**. ### Custom Token (Coin) Based Roles. Use this rule to assign a specific role to your **Discord** users based on a certain balance of a specified **Coin** they hold. Works with the [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains) and **Solana**. ### Collectibles Combo Roles. Use this rule to assign a specific role to your **Discord** users, depending on whether they hold at least one NFT from at least one of several NFT collections of a **Collectibles NFT collection type** or from all of them. Works with the [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains) and **Solana**. ### Editions Quantity-Based Roles. Use this rule to assign a specific role to your **Discord** users based on a certain number of a particular token ID from the **Editions NFT collection type** they own. This feature is in development. ## Capabilities Comparison.

Feature/Tier	Free	Plus	Premium
Rules limit per server	20	60	100
Users limit per server	No limits	No limits	No limits
Supported blockchains	All supported EVM chains and Solana.	All supported EVM chains and Solana.	All supported EVM chains and Solana.
Supported contract types	Collectibles and Editions, Coins	Collectibles and Editions, Coins	Collectibles and Editions, Coins
Automatic verification data update frequency	1 time every 3 days	1 time every 2 days	Ddaily
Manual bulk verification data update frequency	1 time per month	2 times per month	3 times per month

## Before Setup. To proceed with the collection setup, you need to enable the plugin. To do this, click on the switcher located on the left side of the top bar panel.

{% hint style="info" %} Once you've done, proceed to create the [verification rules](/plugins/verify-roles/verification-rules). {% endhint %} # Verification Rules ## Verification Rules Activation. To start creating the verification rules, you first need to activate them. For this, go to the **Select a Plugin** page and click on the `≡ Features` button on the **Verify Roles** card.

Now, activate the desired rule types by clicking on the switcher on the corresponding card, and confirm activation - one rule type at a time.

Now click the `≡ Configure` button on the desired rule type card to visit the page with the list of this type of rule.

## Verification Rules Setup. To add your first rule, click on the `+ Add New Rule` button to call the rule creation form.

## Verification Rules List. For the detailed instructions on how to set up every particular rule type, visit the corresponding page: {% content-ref url="/pages/rmg8z3hsjrpG57gpMYc8" %} [Collectibles Contract-Based Roles](/plugins/verify-roles/verification-rules/collectibles-contract-based-roles) {% endcontent-ref %} {% content-ref url="/pages/Vudi0jJxdpL94gkW0biU" %} [Collectibles Quantity-Based Roles](/plugins/verify-roles/verification-rules/collectibles-quantity-based-roles) {% endcontent-ref %} {% content-ref url="/pages/wPfhgXDKXmmMIoYL06l1" %} [Specific Collectibleы Token Id(s) Based Roles](/plugins/verify-roles/verification-rules/specific-collectibley-token-id-s-based-roles) {% endcontent-ref %} {% content-ref url="/pages/sWvQrfHOAi23QOJWANsd" %} [Specific Editions Token Id(s) Based Roles](/plugins/verify-roles/verification-rules/specific-editions-token-id-s-based-roles) {% endcontent-ref %} {% content-ref url="/pages/BxAmhqQRjDJmGvkZlClB" %} [Specific Collectibles Traits-Based Roles](/plugins/verify-roles/verification-rules/specific-collectibles-traits-based-roles) {% endcontent-ref %} {% content-ref url="/pages/yCRLwr51eXMQJvwi2aqU" %} [Collectibles OpenSea-Based Roles](/plugins/verify-roles/verification-rules/collectibles-opensea-based-roles) {% endcontent-ref %} {% content-ref url="/pages/15OsxfT04sfP1GmCDEXx" %} [Custom Token (Coin) Based Roles](/plugins/verify-roles/verification-rules/custom-token-coin-based-roles) {% endcontent-ref %} {% content-ref url="/pages/2k2Ma3MxkPtW3uZ7d88K" %} [Collectibles Combo Roles](/plugins/verify-roles/verification-rules/collectibles-combo-roles) {% endcontent-ref %} {% hint style="success" %} Once you've done setting up the rules, it's time to [set up the verification channel](/plugins/verify-roles/verification-channel-setup). {% endhint %} ## Rule Card Buttons Explanation. When done, you will see the rule card. Depending on the rule type, the cards could look different, but they all have a common button panel located in the top-right corner of the card. * To **edit** the rule, use the **Pencil** button. It will call the same form you filled out when creating the rule. * To **delete** a rule, use the **Trash bin** button. * The rules with the contract address also have a **Copy** button, located to the right of the contract address in the **Contract** string. Use this button to copy the contract address.

## Rule Limits Display Explanation. After adding at least one rule, a statistic widget will appear on this rule type page, where: * **Current rules** - the quantity of the rules of this type (number of cards on this page). * **Total** - total rules of all types created (number of all cards on all pages). * **Limit** - the maximum quantity of rules of all types you can create on your active tier.

## Rule Type Cards Badges Explanation. After adding at least one rule of any type, when moving back to the list of rule types, you will see the badge in the top-left corner of the corresponding rule type card, which represents the number of created rules of this type.

## Verification Logs Explanation. After the first verification session takes place, the **Verification Logs** table will appear below the rule types cards section with the following data: * **Time** - the date and time the verification session took place. * **Username** - the Discord username of the user checked during the verification session. * **Wallets** - the list of the wallets that were checked during the verification session. * **Roles Added** - the list of the roles that were added during the verification session. * **Roles Removed** - the list of the roles that were removed during the verification session. * **Assets** - the NFTs or the Coins that were found in the Wallets during the verification session. * **Action** - the type of the verification session. It can be Auto (scheduled session) or Manual (session initiated by user).

# Collectibles Contract-Based Roles This is the simplest rule type with the minimum amount of settings, which is perfect if you want to assign a specific role to your **Discord** users, regardless of the number of NFTs from a particular **Collectibles or Editions NFT collection type** they own. Works for [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains) and **Solana**. ## Explanation of the Fields. * In the **Rule Name** field, enter your desired rule name. * In the **Blockchain** dropdown, select the blockchain where your collection contract is deployed. * In the **Contract** field, enter the [collection contract address](/appendix/getting-collection-contract-address). * In the **Role** dropdown, select the prepared **@Role** you wish to assign to the holders. {% hint style="danger" %} Be especially careful when setting the **Contract** field for **Solana** collections! Check this [link](/appendix/getting-collection-contract-address) before starting! {% endhint %} {% hint style="danger" %} If you set up the **Editions** collection type instead of the **Collectibles** type, no error will occur, but the rule won't work! {% endhint %} ## Setting Up the Rule.

# Collectibles OpenSea-Based Roles This rule type allows you to assign a specific role to your **Discord** users, regardless of the number of NFTs from a specific **Collectibles type NFT collection** they own. Almost identical to the [**Collectibles Contract-Based Roles**](/plugins/verify-roles/verification-rules/collectibles-contract-based-roles) rule, but it operates via an **OpenSea** [collection slug](/appendix/getting-collection-slug-symbol), which makes this rule type work with the collections based on any chain supported by **OpenSea**. ## Explanation of the Fields. * In the **Rule Name** field, enter your desired rule name. * In the **Blockchain** dropdown, select the blockchain where your collection contract is deployed. * In the **Collection Slug** field, enter the [collection slug](/appendix/getting-collection-slug-symbol). * In the **Role** dropdown, select the prepared **@Role** you wish to assign to the holders. {% hint style="danger" %} If you set up the **Editions** collection type instead of the **Collectibles** type, no error will occur, but the rule won't work! {% endhint %} ## Setting Up the Rule.

# Collectibles Quantity-Based Roles This rule type allows you to assign a specific role to your **Discord** users based on a certain number of NFTs from a particular **Collectibles NFT collection type** they own. Works for [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains) and **Solana**. ## Explanation of the Fields. * In the **Rule Name** field, enter your desired rule name. * In the **Blockchain** dropdown, select the blockchain where your collection contract is deployed. * In the **Contract** field, enter the [collection contract address](/appendix/getting-collection-contract-address). * In the **Minimum Balance** field, enter the minimum number of NFTs a user should hold to get the role. * In the **Maximum Balance** field, enter the minimum number of NFTs a user should hold to get the role. * In the **Role** dropdown, select the prepared **@Role** you wish to assign to the holders. {% hint style="danger" %} Be especially careful when setting the **Contract** field for **Solana** collections! Check this [link](/appendix/getting-collection-contract-address) before starting! {% endhint %} {% hint style="danger" %} If you set up the **Editions** collection type instead of the **Collectibles** type, no error will occur, but the rule won't work! {% endhint %} ## Setting Up Minimum and Maximum Limited Grades.

## Setting Up Minimum Only Limited Grades. As far as the **Maximum Balance** field is optional, you can use it to keep the upper restriction blank for the latest grade:

{% hint style="info" %} **Note:** To prevent rule conflicts when creating holder grades, make sure that each time you set the current **Minimum Balance**, it is exactly +1 higher than the previous range's **Maximum Balance**. {% endhint %} # Specific Collectibles Traits-Based Roles This rule type allows you to assign a specific role to your **Discord** users based on a specific NFT trait from a particular **Collectibles NFT collection type** they own. Works for collections launched on [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains) and listed on **OpenSea**, and for **Solana** collections listed on **Magic Eden**. ## Explanation of the Fields. * In the **Rule Name** field, enter your desired rule name. * In the **Marketplace** dropdown, select the marketplace where your collection is listed. * In the **Collection Slug** or **Collection Symbol** field (appears only after choosing the **Marketplace**), enter the [collection slug/symbol](/appendix/getting-collection-slug-symbol). * In the **Trait** dropdown, select the desired NFT trait (will appear only if the Collection Slug is correct). * In the **Role** dropdown, select the prepared **@Role** you wish to assign to the holders. {% hint style="danger" %} If you set up the **Editions** collection type instead of the **Collectibles** type, no error will occur, but the rule won't work! {% endhint %} ## Setting Up the Rule.

# Specific Collectibleы Token Id(s) Based Roles This rule type allows you to assign a specific role to your **Discord** users based on a specific token ID(s) from a particular **Collectibles NFT collection type** they own. Works for [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains) and **Solana**. ## Explanation of the Fields. * In the **Rule Name** field, enter your desired rule name. * In the **Blockchain** dropdown, select the blockchain where your collection contract is deployed. * In the **Contract** field, enter the [collection contract address](/appendix/getting-collection-contract-address). * In the **Token ID(s)** field, enter the ID (or IDs) of NFT(s) a user should hold to get the role. * In the **Role** dropdown, select the prepared **@Role** you wish to assign to the holders. {% hint style="danger" %} Be especially careful when setting the **Contract** field for **Solana** collections! Check this [link](/appendix/getting-collection-contract-address) before starting! {% endhint %} {% hint style="danger" %} If you set up the **Editions** collection type instead of the **Collectibles** type, no error will occur, but the rule won't work! {% endhint %} ## Setting Up Just One ID. In case you want to assign users a **@Role** depending on whether they have only one NFT with the specific ID, it's just as easy:

## Setting Up Multiple IDs. In case you want to assign users a **@Role** based on whether they possess one of the NFTs with specific IDs, you can list them separated by commas without spaces:

## Setting Up a Range of IDs. If you want to assign users a **@Role** based on whether they possess NFTs with specific IDs within a certain range, you can enter the first and last IDs:

## Mixing Up Multiple IDs and ID Ranges. You can also mix and flexibly combine the last two variants like this: {% columns %} {% column %} {% hint style="success" %} 329,333,345-350 {% endhint %} {% hint style="success" %} 329,333,345-350,356,359 {% endhint %} {% endcolumn %} {% column %} {% hint style="success" %} 329-333,345-350 {% endhint %} {% hint style="success" %} 333,345-350,355,360-369 {% endhint %} {% endcolumn %} {% endcolumns %} This allows you to use only one rule at a time to set IDs and ID ranges separately, rather than using several rules simultaneously. {% hint style="warning" %} If you set more than one ID, the rule will be assigned if the holder has any NFT from the list, not all of them! {% endhint %} # Specific Editions Token Id(s) Based Roles This rule type allows you to assign a specific role to your **Discord** users based on a specific token ID(s) from a particular **Editions NFT collection type** they own. Guaranteed to work with the [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains). Didn't test on **Solana**. ## Explanation of the Fields. * In the **Rule Name** field, enter your desired rule name. * In the **Blockchain** dropdown, select the blockchain where your collection contract is deployed. * In the **Contract** field, enter the valid 1/1 type [collection contract address](/appendix/getting-collection-contract-address) (ERC-1155 for **EVM** chains). * In the **Token ID(s)** field, enter the ID (or IDs) of NFT(s) a user should hold to get the role. * In the **Role** dropdown, select the prepared **@Role** you wish to assign to the holders. {% hint style="danger" %} Be especially careful when setting the **Contract** field for **Solana** collections! Check this [link](/appendix/getting-collection-contract-address) before starting! {% endhint %} {% hint style="danger" %} If you set up the **Collectibles** collection type instead of the **Editions** type, no error will occur, but the rule won't work! {% endhint %} ## Setting Up Just One ID. In case you want to assign users a **@Role** depending on whether they have only one NFT with the specific ID, it's just as easy:

## Setting Up Multiple IDs. In case you want to assign users a **@Role** based on whether they possess one of the NFTs with specific IDs, you can list them separated by commas without spaces:

## Setting Up a Range of IDs. If you want to assign users a **@Role** based on whether they possess NFTs with specific IDs within a certain range, you can enter the first and last IDs:

## Mixing Up Multiple IDs and ID Ranges. You can also mix and flexibly combine the last two variants like this: {% columns %} {% column %} {% hint style="success" %} 10,12,14-35 {% endhint %} {% hint style="success" %} 10,12,14-35,56,59 {% endhint %} {% endcolumn %} {% column %} {% hint style="success" %} 14-35,56-59 {% endhint %} {% hint style="success" %} 10,12,14-35,45,56-59 {% endhint %} {% endcolumn %} {% endcolumns %} This allows you to use only one rule at a time to set IDs and ID ranges separately, rather than using several rules simultaneously. {% hint style="warning" %} If you set more than one ID, the rule will be assigned if the holder has any NFT from the list, not all of them! {% endhint %} # Custom Token (Coin) Based Roles This rule type allows you to assign a specific role to your **Discord** users based on a specific amount of a particular **Coin** they own. Works for [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains) and **Solana**. ## Explanation of the Fields. * In the **Rule Name** field, enter your desired rule name. * In the **Blockchain** dropdown, select the blockchain where your token (**Coin**) contract is deployed. * In the **Contract** field, enter the token (**Coin**) contract address. * In the **Required Balance** field, enter the **Coin** balance that the user should hold to get the role. * In the **Role** dropdown, select the prepared **@Role** you wish to assign to the holders. ## Setting Up the Rule.

# Collectibles Combo Roles This rule type allows you to assign a specific role to your **Discord** users, depending on whether they hold at least one NFT from at least one of several NFT collections of a **Collectibles NFT collection type** or from all of them. Works with the [supported **EVM** chains](/basics/chains-marketplaces#supported-evm-chains) and **Solana**. ## Explanation of the Fields. * In the **Rule Name** field, enter your desired rule name. * In the **Blockchain** dropdown, select the blockchain where your collection contract is deployed. * In the **Contract Addresses** fields, enter up to 5 [collection contract addresses](/appendix/getting-collection-contract-address). * In the **Role** dropdown, select the prepared **@Role** you wish to assign to the holders. * Enable the **Require All** checkbox if you want to assign this **@Role** only if the user has at least one NFT from every added collection, not just one of them. {% hint style="danger" %} Be especially careful when setting the **Contract** field for **Solana** collections! Check this [link](/appendix/getting-collection-contract-address) before starting! {% endhint %} {% hint style="danger" %} If you set up the **Editions** collection type instead of the **Collectibles** type, no error will occur, but the rule won't work! {% endhint %} ## Setting Up the Rule.

# Verification Channel Setup When the [verification rules](/plugins/verify-roles/verification-rules) are ready, you can invite your users to initiate the verification process. But first, you need to prepare and set up the verification channel. To provide your **Discord** server with the token-gated functionality, **Bocto** initially creates an embedded message with a special widget. This widget can be set up using two methods - via the **Bocto** Dashboard and via the **Discord** command.

## Setting up the Channel and Permissions. Whatever of the two mentioned methods you choose, first you need to prepare the **#nft-verify** (or name it as you wish) public channel with the [correct channel permissions](/appendix/setting-up-channels-permissions) where you want to set up the verification widget, then come here to continue. ## Setting up the Verification Widget via Dashboard. After activating the plugin in the **Bocto** Dashboard and creating the **#nft-verify** channel in your **Discord**, come back to the **Select a Plugin** page and click on the `⚙` button to enter the basic plugin settings.

Now choose the prepared channel - it will take a while to check if **Bocto** has access to this channel. If everything is OK, press the **`Save`** button on the top bar.

If you see this error: **Bocto is missing the following permissions for this channel to operate properly: ViewChannel**, that means your **#nft-verify** channel is actually private!

To fix it, check again and set up the [correct channel permissions](/appendix/setting-up-channels-permissions), then come back and reload the **Verify Roles Settings** page. If everything is OK, press the `Save` button on the top bar. After saving the channel in the **Bocto** Dashboard, the embed widget will immediately appear in this channel.

## Set up the Verification Widget via Discord. Alternatively, you can use the special **Discord** command to set up the verification widget. If you prefer this method, call the `/set-verification-channel` command in any channel and in the appeared dropdown, choose the channel for the verification you've prepared. Here is the same rule - this channel must have the [correct channel permissions](/appendix/setting-up-channels-permissions) set up.

If everything is okay with the permissions, the embed widget will immediately appear in this channel.

But if you see this message instead, that means your **#nft-verify** channel is actually private.

To fix it, check again and set up the [correct channel permissions](/appendix/setting-up-channels-permissions), then come back and relaunch the command. When everything is done, visit the **Verify Roles Settings** page in **Dashboard** to ensure the channel was set automatically. If you kept this page open, refresh it to see the actual state. It should look like this:

{% hint style="success" %} Once you've done, invite your users to this channel to start the [user verification process](/user-profile/user-verification-process). {% endhint %} # NFT Tracker {% content-ref url="/pages/qURgd3igwo8QLCrGNIW8" %} [Introduction](/plugins/nft-tracker/introduction) {% endcontent-ref %} {% content-ref url="/pages/JaAs47zY5ykg7Zhu1Qv3" %} [Discord Tracker Rules](/plugins/nft-tracker/discord-tracker-rules) {% endcontent-ref %} # Introduction ## Overview. **NFT Tracker** is a plugin that provides your socials with the information about mints, listings, and sales of the NFTs from your collections. In combination with the [**NFT Stats**](/plugins/nft-stats) plugin, it is a great way to demonstrate your NFT collection dynamics to the community. Currently works only for **Discord**. ## Discord NFT Multi Tracker. The **Discord NFT Multi Tracker** is the **NFT Tracker** feature that allows you to track and post your NFT collection **Mint**, **Listing**, and **Sale** events in your **Discord** server. ## Capabilities Comparison.

Feature/Tier	Free	Plus	Premium
Collections limit per server	6	12	24
Supported contract types (Mints)	1/1 only	1/1 and Editions	1/1 and Editions
Supported blockchains (Mints)	Ethereum, Polygon, Solana	Ethereum, Polygon, Solana	Ethereum, Polygon, Solana
Supported marketplaces (Sales and Listings)	OpenSea, Magic Eden	OpenSea, Magic Eden	OpenSea, Magic Eden
Update frequency (Mints)	15 min	2 min	Interactive
Update frequency (Sales and Listings)	Interactive	Interactive	Interactive

## Before Setup. To proceed with the collection setup, you need to enable the plugin. To do this, click on the switcher located on the left side of the top bar panel.

# Discord Tracker Rules ## Preparing Channels and Setting Up the Permissions. Before starting to create tracking rules, first you need to prepare **#mints**, **#listings**, and **#sales** channels, or you can create a single **#events-tracker** channel for all event types - it's up to you. You can also name these channels as you wish. The only requirement here is that they must have the [correct channel permissions](/appendix/setting-up-channels-permissions) set up. ## Discord Tracker Rules Activation. To start creating the verification rules, you first need to activate them. For this, go to the **Select a Plugin** page and click on the `≡ Features` button on the **NFT Tracker** card.

Now, activate the **Discord NFT Multi Tracker** feature by clicking on the switcher on the corresponding card, and confirm activation.

Now click the `≡ Configure` button on this card to visit the page with the list of tracking rules.

## Discord Tracker Rules Setup. To add your first rule, click on the `+ Add New Rule` button to call the rule creation form.

Then choose the desired event type from the Event Type dropdown:

For the detailed instructions on how to set up every particular event type, visit the corresponding page: {% content-ref url="/pages/sG84c14oOAKcZ2T0SAbW" %} [Mint Event Type](/plugins/nft-tracker/discord-tracker-rules/mint-event-type) {% endcontent-ref %} {% content-ref url="/pages/SOwfeGMo1DT8Fg1cP2cz" %} [Sale and Listing Event Types](/plugins/nft-tracker/discord-tracker-rules/sale-and-listing-event-types) {% endcontent-ref %} ## Rule Card Buttons Explanation. When done, you will see the rule card. Depending on the rule type, the cards could look different, but they all have a common button panel located in the top-right corner of the card. * To **edit** the rule, use the **Pencil** button. It will call the same form you filled out when creating the rule. * To **delete** a rule, use the **Trash bin** button. * The rules with the contract address also have a **Copy** button, located to the right of the contract address in the **Contract** string. Use this button to copy the contract address.

# Mint Event Type This rule type allows tracking both **1/1 NFT collection type** and **Edition collection type**** ****Mint** events. The **1/1 NFT collection type** tracking guaranteed works for supported **EVM** chains and **Solana**. The **Edition collection type** tracking guaranteed works for supported **EVM** chains, but didn't test on **Solana**. ## Explanation of the Fields. * In the **Rule Name** field, enter your desired rule name. * In the **Blockchain** dropdown, select the blockchain where your collection contract is deployed. * In the **Contract** field, enter the **1/1 collection type** or **Edition collection type** [collection contract address](/appendix/getting-collection-contract-address). * In the **Info Channel** dropdown, select the prepared **#events-tracker** channel you wish to send the embeds. {% hint style="danger" %} Be especially careful when setting the **Contract** field for **Solana** collections! Check this [link](/appendix/getting-collection-contract-address) before starting! {% endhint %} ## Setting Up the Rule.

Depending on [your tier](/plugins/nft-tracker/introduction#capabilities-comparison), to see the first embeds in your prepared **#events-tracker** channel, you will have to wait up to 15 minutes after the rule is created. ## Examples of the embeds. The **1/1 NFT collection type** **Mint** embed will look like this:

The **Edition collection type** **Mint** embed will look like this. The additional **Amount** field reflects how many editions of the NFT with this ID were minted during the transaction.

# Sale and Listing Event Types This rule type allows tracking both **1/1 NFT collection type** and **Edition collection type**** ****Listing** and **Sale** events. The **1/1 NFT collection type** tracking guaranteed works for collections launched on supported **EVM** chains and listed on **OpenSea**, and for **Solana** collections listed on **Magic Eden**. The **Edition collection type** tracking guaranteed works for collections launched on supported **EVM** chains and listed on **OpenSea**, but didn't test on **Solana** collections listed on **Magic Eden**. ## Explanation of the Fields. * In the **Rule Name** field, enter your desired rule name. * In the **Marketplace** dropdown, select the marketplace where your collection is listed. * In the **Collection Slug** or **Collection Symbol** field (appears only after choosing the **Marketplace**), enter the [collection slug/symbol](/appendix/getting-collection-slug-symbol). * In the **Info Channel** dropdown, select the prepared **#events-tracker** channel you wish to send the embeds. {% hint style="danger" %} Be especially careful when setting the **Contract** field for **Solana** collections! Check this [link](/appendix/getting-collection-contract-address) before starting! {% endhint %} ## Setting Up the Rule. Both **Listing** and sale events have the same rule creation form, so let's take the listing event type as the example.

The first embeds will appear in your prepared **#events-tracker** channel immediately after the listing or sale happens. ## Examples of the embeds. The **Listing** embed will look like this:

The **Sale** embed will look like this:

{% hint style="info" %} **Note:** An alternative display of prices in dollars is only available for collections listed on **OpenSea**. {% endhint %} # NFT Stats {% content-ref url="/pages/Wy8oND8zbOhUBMzJlEzX" %} [Introduction](/plugins/nft-stats/introduction) {% endcontent-ref %} {% content-ref url="/pages/TKjBdrWdCUjHnh5n27Ot" %} [Getting Collection Slug/Symbol](/appendix/getting-collection-slug-symbol) {% endcontent-ref %} {% content-ref url="/pages/csZRUFz6HNkV2czwJwcp" %} [Adding New Collection with Rarible](/plugins/nft-stats/adding-new-collection-with-rarible) {% endcontent-ref %} {% content-ref url="/pages/MRxg0iDfECn2qL4tugeS" %} [Updating Collection Data](/plugins/nft-stats/updating-collection-data) {% endcontent-ref %} {% content-ref url="/pages/OvTPBerqcSyyX8QeKSX1" %} [Removing Collections](/plugins/nft-stats/removing-collections) {% endcontent-ref %} {% content-ref url="/pages/Dc1Po8tgdih2SrUmLnkj" %} [Rich Stats Widget](/plugins/nft-stats/rich-stats-widget) {% endcontent-ref %} # Introduction ## Overview. **NFT Stats** is a plugin that provides your **Discord** server with various types of statistics for your NFT Collection in two different ways. ## Sidebar Stats. The **NFT Stats** plugin allows you to create categories with sets of voice channels in your **Discord** server's sidebar. This type of statistics shows not only your collection data from the chosen marketplace, but also includes your custom data, such as mint price and total collection supply. It is perfect for the minting events when you want to show your community members all the actual information about your NFT collection, like minting progress, floor and mint price, unique holders quantity, and secondary market activity. ## Rich Stats. The **NFT Stats** plugin can also create an embedded message with a widget that contains only marketplace default data (no custom info about mint price or total collection supply), but represented in extended form, including 1-day, 7-day, and 30-day summaries, which can be updated manually by any user at any time by pressing the **Refresh Stats** button.

## Capabilities Comparison.

Feature/Tier	Free	Plus	Premium
Collections limit per server	2	4	8
Supported marketplaces	OpenSea, Magic Eden, LooksRare	OpenSea, Magic Eden, LooksRare	OpenSea, Magic Eden, LooksRare
Supported blockchains	Ethereum, Polygon, Solana	Ethereum, Polygon, Solana	Ethereum, Polygon, Solana
Supported contract types	Only Collectibles	Collectibles and Editions	Collectibles and Editions
Auto-update frequency	24h	12h	4h
Manual update frequency	1 min	1 min	1 min
Rich Stats Widget	Available	Available	Available

## Before Setup. To proceed with the collection setup, you need to enable the plugin. To do this, click on the switcher located on the left side of the top bar panel.

## Available Commands. `/set-collection-stats` Set up Collection Stats Channels. \ `/remove-collection-stats` Remove Stats Channels & stop updates. \ `/refresh-collection-stats` Refresh Collection Stats Channels. \ `/safe-remove-all-stats` Remove all NFT previously created stats channels & stop updates safely. \ `/get-rich-collection-stats` Get Rich Collection Stats. \ `/refresh-metadata` Refresh Collection Metadata. Use `/help` command to see this list in Discord.

# Adding New Collection with Rarible ## Adding Collection via Dashboard. #### **Action 0.** Prepare the [Collection Slug](/appendix/getting-collection-slug-symbol) for the desired marketplace, then come back here. #### **Action 1.** Click on the **+ Add Collection** button and in the appeared form select the desired marketplace from the **Marketplace** drop-down menu. Some unnecessary fields can disappear depending on your choice. #### **Action 2.** In the **Collection Slug** field, paste the Collection Slug you've prepared on **Action 0**. For **Rarible** collections, the real collection slug is not required, and for **LooksRare** collections, it doesn't even exist. However, we need something to use as the name of your collection on the collection card and in the Discord stats category title. So you can type the name you want for both, or for **Rarible**, also use the real collection slug. #### **Action 3.** Fill the **Collection Supply** and **Mint Price** fields with the desired numbers. You can change these values at any time if needed. #### **Action 4.** Select the correct currency in the **Mint Token** field and the network in the **Blockchain** field.

{% hint style="danger" %} **Important!** Be attentive - don't mess up the currency and the blockchain! If, for the **Polygon** collection, you set, for example, ETH as the **Mint Token** or Ethereum as the **Blockchain**, it won't work! {% endhint %} #### **Action 5.** On **Rarible**, some extra fields need to be filled. The first one is the **Contract** address of your collection, and the second one is the **Display Currency** - set it to the same as the **Mint Token**. On **LooksRare**, there is only one extra field that needs to be filled - the **Contract** address of your collection, which can be easily obtained on this marketplace in the same way as the [collection slug](/appendix/getting-collection-slug-symbol) on others.

#### **Action 6.** Click on the **Setup Collection** button, and that's it! You can now see your collection, added to the Dashboard.

{% hint style="info" %} **Note:** You can add up to 2 collections on the **Free** tier, up to 4 collections on the **Plus** tier, and up to 8 on the **Premium**. {% endhint %} ## Adding Collection via Discord Command. As an alternative to the Dashboard processing, you can also use the **Discord** command to start the setup process right in **Discord**. For this, go to the **Bocto**** ****#hub** channel (or any other - it doesn't matter) and run this command: `/set-collection-stats` The process here is absolutely identical to that in Dashboard - just select the appropriate items in drop-down menus and fill in the data in text fields.

When you fill in all the obligatory fields, access to the extra fields will be granted. Ignore these fields for **OpenSea** and **Magic Eden** collections and fill them only for the collections on **Rarible** and **LooksRare**.

Only fill the *contract* and *currency* fields for corresponding marketplaces!

### **Update Frequency.** On paid tiers, you will also get access to the **Update Frequency** setup option via **Discord** command.

## Collection Stats channels in the Discord sidebar. Regardless of which setup type you choose, once it's complete, you'll also see a collection category with voice channels in your **Discord**:

### What can you do with the category and the channels? * You can rename the category and change its position. * You can change the channel positions inside the category. ### What can't you do with the category and the channels? * You can not rename the channels as long as they will be renamed back anyway during the next scheduled update. * You can not delete the channels as long as they will be recreated anyway during the next scheduled update. # Adding New Collection ## Adding Collection via Dashboard. #### **Action 0.** Prepare the [Collection Slug](/appendix/getting-collection-slug-symbol) for the desired marketplace, then come back here. #### **Action 1.** Click on the **+ Add Collection** button and in the appeared form select the desired marketplace from the **Marketplace** drop-down menu. Some unnecessary fields can disappear depending on your choice. #### **Action 2.** In the **Collection Slug** field, paste the Collection Slug you've prepared on **Action 0**. For **LooksRare** collections, the collection slug doesn't exist. However, we need something to use as the name of your collection on the collection card and in the Discord stats category title. So you can type the name you want. #### **Action 3.** Fill the **Collection Supply** and **Mint Price** fields with the desired numbers. You can change these values at any time if needed. #### **Action 4.** Select the correct currency in the **Mint Token** field and the network in the **Blockchain** field.

{% hint style="danger" %} **Important!** Be attentive - don't mess up the currency and the blockchain! If, for the **Polygon** collection, you set, for example, ETH as the **Mint Token** or Ethereum as the **Blockchain**, it won't work! {% endhint %} #### **Action 5.** On **LooksRare**, there is one extra field that needs to be filled - the **Contract** address of your collection, which can be easily obtained on this marketplace in the same way as the [collection slug](/appendix/getting-collection-slug-symbol) on others.

#### **Action 6.** Click on the **Setup Collection** button, and that's it! You can now see your collection, added to the Dashboard.

### **Update Frequency.** On paid tiers, you will also get access to the **Update Frequency** setup option via **Discord** command.

## Collection Stats channels in the Discord sidebar. Regardless of which setup type you choose, once it's complete, you'll also see a collection category with voice channels in your **Discord**:

Some fields, like **Marketplace**, **Collection Slug**, and **Contract**, can't be changed. When done, press the **Update Collection** button and check the Stats voice channels to ensure that the info has been updated. {% hint style="info" %} **Note:** You can only edit the collection info via Dashboard (we have no special **Discord** command for this). {% endhint %} ## Refreshing Collection Statistics. Depending on your tier, the collection statistics in Stats voice channels update automatically every 24, 12, or 6 hours, but you can update them manually as well. For this: * Visit the **NFT Stats** plugin page in Dashboard, and press the **Refresh** button on the desired collection card. * Use `/refresh-collection-stats` command in **Discord** in the **Bocto**** ****#hub** channel (or any other), enter the [collection slug](/appendix/getting-collection-slug-symbol) and select the marketplace so that the bot can identify the collection whose statistics you want to update.

## Refreshing Collection Metadata. You can also trigger the refresh metadata method for your collection on the marketplace where it is listed. For this use `/refresh-metadata` command in **Discord** in the **Bocto**** ****#hub** channel (or any other), enter the [collection slug](/appendix/getting-collection-slug-symbol) and select the marketplace so that the bot can identify the collection whose metadata you want to update. Unlike `/refresh-collection-stats` the `/refresh-metadata` command has 3 extra options: * token\_id - if you only want to refresh a specific token metadata. * token\_range - if you want to refresh metadata of a specific token range. * refresh\_last\_20 - to refresh metadata for the last 20 tokens.

{% hint style="info" %} **Note:** You can only refresh your collection metadata by using this **Discord** command (we have no special option for this in Dashboard). {% endhint %} {% hint style="info" %} **Note:** This feature currently works only for collections listed on **OpenSea**! {% endhint %} # Removing Collections If, for some reason, you decided to remove one or all your collections, you can do it easily in a few clicks without the necessity of manually removing the **Stats** category and **Stats** voice channels. **Bocto** provides you with two ways to do it. ## Removing collections one by one. ### Removing via Dashboard. The easiest way is to visit the NFT Stats plugin page in Dashboard, press the **Remove** button on the collection card. It will remove the card itself, the collection's data from our database, and the collection category with all the channels inside it automatically. ### Removing via Discord command. The second way is to use `/remove-collection-stats` command in **Discord** in the **Bocto**** ****#hub** channel (or any other), enter the [collection slug](/appendix/getting-collection-slug-symbol) and select the marketplace so that the bot can identify the collection you want to remove.

## Batch safe removing. If you don't want to mess with one-by-one removal, you can use `/safe-remove-all-stats` command in **Discord** in the **Bocto**** ****#hub** channel (or any other), and Bocto will do everything safely and automatically. All the collection cards in Dashboard, the collection's data in our database, and the collection categories with all the channels inside them will be removed.

{% hint style="danger" %} **Important!** This command has no intermediate steps or options, and once it is launched, all the data about your collections **will be deleted immediately**! Proceed with caution! {% endhint %} # Rich Stats Widget In addition to categories with sets of **Stats** voice channels in **Discord** sidebar, **Bocto** can also create an embedded message with a widget that contains only marketplace default data (no custom info about mint price or total collection supply), but represented in extended form, including 1-day, 7-day, and 30-day summaries.

## Set up the Channel and Permissions. Prepare the **#rich-stats** (or name it as you wish) public channel with the [correct channel permissions](/appendix/setting-up-channels-permissions) where you want to set up the widget, then come back here to continue. ## Set up the Rich Stats Widget. When you've done with the permissions, in the created channel, run `/get-rich-collection-stats` command, enter the [collection slug](/appendix/getting-collection-slug-symbol), and select the marketplace where it is listed. Currently works for **OpenSea** only.

The **Rich Stats Widget** will appear, which can be updated manually by any user at any time by pressing the **Refresh Stats** button.

{% hint style="info" %} **Note:** This command does not create any collection cards on the **NFT Stats** plugin page in the Dashboard or any **Stats** voice channels in your **Discord**! {% endhint %} {% hint style="info" %} **Note:** This feature currently works only for collections listed on **OpenSea**! {% endhint %} # Guard {% content-ref url="/pages/NPZHuwyCZwm5RdDOxpCy" %} [Introduction](/plugins/guard/introduction) {% endcontent-ref %} {% content-ref url="/pages/1oG5GPRMuiRoXrxcIHTE" %} [Guard Features](/plugins/guard/guard-features) {% endcontent-ref %} {% content-ref url="/pages/m4cFTbxOMGP4Nyb5GQCh" %} [Guard Features Configuration](/plugins/guard/guard-features-configuration) {% endcontent-ref %} {% content-ref url="/pages/pFXz0AZTkYimPyi0EyQ2" %} [Guard Settings](/plugins/guard/guard-settings) {% endcontent-ref %} # Introduction ## Overview. **Guard** is a plugin that extends your **Discord** server with several simple, original anti-spam features in addition to the default **Discord** functionality, making your server an even safer place. ## Features List. ### Not Matching HyperLinks. This feature checks if the text of the link in the user's message corresponds to the actual inserted link and leads to the same website. ### Links in Embed Messages. This feature checks if the custom embed message contains links and blocks it if any are found. ### Users With Transparent PFPs. This feature evaluates the user's PFP and blocks the message if the ratio of the transparent and opaque pixels doesn't match the tolerance. ### Promotional Text and QR Codes in Images. This feature analyzes the images attached to the message using an AI library and blocks the message if the image text is evaluated as spam content or the image contains a QR code. ## Before Setup. To proceed with the collection setup, you need to enable the plugin. To do this, click on the switcher located on the left side of the top bar panel.

# Guard Features ## Guard Features Activation. To start using the **Guard** features, you first need to activate them. For this, go to the **Select a Plugin** page and click on the `≡ Features` button on the **Guard** card.

Now, activate the desired features (we strongly recommend enabling all of them) by clicking on the switcher on the corresponding card, and confirm activation - one feature at a time.

## Guard Features List. For the detailed explanation of how each particular feature works, visit the corresponding page: {% content-ref url="/pages/0tCMjdX3Bq8ZCTacqmjq" %} [Not Matching HyperLinks](/plugins/guard/guard-features/not-matching-hyperlinks) {% endcontent-ref %} {% content-ref url="/pages/RmOY9KRcOf6TwEwXsXmL" %} [Links in Embed Messages](/plugins/guard/guard-features/links-in-embed-messages) {% endcontent-ref %} {% content-ref url="/pages/aiTFeYDK3L4rqG6ikzeb" %} [Users With Transparent PFPs](/plugins/guard/guard-features/users-with-transparent-pfps) {% endcontent-ref %} {% content-ref url="/pages/cN29qCQnB4otQqNNx9Er" %} [Promotional Text and QR Codes in Images](/plugins/guard/guard-features/promotional-text-and-qr-codes-in-images) {% endcontent-ref %} {% hint style="success" %} Once you've activated all features, it's time to [set up the Guard Settings](/plugins/guard/guard-settings). {% endhint %} ## Guard Features Сonfiguration. All the **Guard** features, by default, have an optimal configuration, and in general, you should not change them, but if you want to, click the `≡ Configure` button on the corresponding card. Read more about the **Guard** features configuration [here](/plugins/guard/guard-features-configuration). # Not Matching HyperLinks This feature checks if the text of the link in the user's message matches the actual inserted link and directs to the same website. ## Scam Mechanics. If you might know, the links in **Discord** could be exposed like `https://website.com` or non-exposed, i.e., with a URL address (also called a link anchor) hidden behind the text link. This non-exposed type of link can be created with a special **Discord** syntax pattern like this: `[Link text](https://link-anchor.com/target-url)` Being posted in **Discord** chat, this message will look like this:

When the link text makes sense, it's okay, because users understand that they are clicking on a text with a hyperlink that can lead them anywhere, and they should be cautious. However, scammers can abuse this **Discord** feature to make the link text look like an exposed link, while hiding the actual link address using this syntax: `[octopeeps.com](https://octopeeps.io)` or `[www.octopeeps.com](https://octopeeps.io)` Let's take the first variant (without www):

And, being posted in **Discord**, it will look like this:

You see?! The link text here looks like an absolutely legit website URL, but the link anchor leads to another domain - to **.io** instead of **.com**! A more complex example of this scam message can have this syntax: `Check the official [octopeeps.com](https://octopeeps.io) website!`

Here we see the same picture with a mismatched domain name in the link text and the real URL in the link anchor. However, this time, the message looks even less suspicious because the surrounding text distracts the reader's attention. ## Explanation of the Feature. And this is where the Not Matching HyperLinks feature comes into action! It detects if the message contains a text pattern similar to a URL address syntax in the \[square brackets] in link text and checks if it matches the real target URL address, if any, in the following (parentheses), and if it doesn't, blocks the message:

Depending on your [Guard Settings](/plugins/guard/guard-settings), **Bocto** can also post a detailed alert to the **#alerts** channel it created during the [setup on the server](/getting-started/setup-on-server):

## Patterns That This Feature Blocks. Currently, the Not Matching HyperLinks feature blocks these patterns: `[https://octopeeps.com](https://octopeeps.io)` `[www.octopeeps.com](https://octopeeps.io)` `[octopeeps.com](https://octopeeps.io)` # Links in Embed Messages This feature checks if the custom embed message contains links and blocks it if any are found. ## Scam Mechanics. **Discord** offers an option to make posted links look more attractive by adding what are called Embeds. This is when a proper widget appears below the user's message if it contains a link. To enable this feature, you need to turn on the Embed Links permission in the role or channel settings. However, the Embed functionality is also widely used by bots and admins to create vibrant and attractive custom embeds, which can include links.

The truth is, the scammers can do it as well sometimes! As mentioned above, you need to have special permissions to post such embeds - either you must be a bot or have Administrator permissions on the server and access to the server's API to create webhooks and use them to post such embeds via services like **Discohook**. So technically, this case is hardly reproducible, but still, we have been facing cases on our server where regular users without obligatory permissions found a way to post custom embeds in public channels! ## Explanation of the Feature. And this is where the Links in Embed Messages feature comes into action! It detects if the custom embed message contains a link, and if it does, blocks the message. ## The Problem of the Feature Usage. This feature would serve as an ideal temporary protection if an admin or bot on your server were hacked and the attacker gained access to post custom embeds using that bot or account. However, **Discord** does not allow bots to block each other, so this feature cannot protect your server from compromised bots. And if we took a compromised admin case, here is a kind of similar situation. The previous feature's default behavior was to block admins' custom embeds containing links just as any other role. This behavior could be changed by manually configuring the bot through the Dashboard for the period when admins post their embeds. This could become quite a good temporary protection, giving the server owner time to react until the attacker kicks **Bocto**. However, for many server owners, this pipeline was complicated and unclear, so we had to exclude roles with Administrator permissions from the check, and now it is impossible to change it through feature configuration. Summarizing everything above, we can describe this feature as a "just in case" one, which might never even be triggered. ## We Don't Know If It Is a Bug or a Feature... ...but, we noticed that while **Discord** automatically deletes links, if any, from default embeds it creates (when you post a regular link to a page with a feature image and a first paragraph containing a link), it retains links in the embeds it generates within the X posts. This is why the Links in Embed Messages feature blocks these posts by default. This is how the X-autogenerated embed with a link looks when being posted by an authorized user:

This is a trusted link to the trusted X post that contains the trusted link to the space hosted by our friends. But if someone else posts the same link, the message will be blocked if the Links in Embed Messages feature configuration settings are set by default:

Currently, we noticed this behavior only for X links. So if you really want to prevent anyone but administrators from posting X links, no action is needed, but if you want to allow posting X links for certain roles in certain channels, you need to change this [feature configuration](/plugins/guard/guard-features-configuration). # Users With Transparent PFPs This feature evaluates the user's PFP and blocks the message if the ratio of the transparent and opaque pixels doesn't matchs the tolerance. ## Scam Mechanics. Before we start, just look at this message by **Mr. Diamond**, who is the server admin:

Did you notice anything that looks suspicious to you in this message? Probably not. And this is a problem! Because there are actually two messages from two different users! In **Discord,** users can set up transparent PNG images for avatars, as well as use emojis instead of letters in their display names. And this is how the user profile can look as a result:

But if we inspect the source code via the developer console in the browser, we'll see that there is indeed another one PFP here - that very transparent PNG our Mr. Smart Guy set earlier for his account!

It is still a very popular scammer's trick! People in **Discord** are, in most cases, careless and relaxed, and can easily lower their guard and mistake such a message for a message from an administrator or a member of the project team. ## Explanation of the Feature. And this is where the Users With Transparent PFPs feature comes into action! It analyzes the user avatar if its ratio of the transparent and opaque pixels matches the tolerance, and if it doesn't, it blocks the message:

Sometimes, scammers even try to set the transparent PNG image with a small, barely visible grey opaque dot to trick the weak filters. However, **Bocto** uses a 40% tolerance barrier to determine and block scam PFPs, while allowing legit PFPs with some amount of transparent pixels.

## PFP Types That This Feature Blocks. Currently, the Users With Transparent PFP feature only reacts to PFP transparency. In the future, we will also add an analysis algorithm for **Discord** themes' colors. # Promotional Text and QR Codes in Images This feature analyzes the images attached to the message using a special library and blocks the message if the image text is evaluated as spam content or if the image contains a QR code. It allows you to grant the Attach Files permission in the role or channel settings without fear that users will abuse it. ## Scam Mechanics. **Discord** algorithms have become smarter and can detect potential scam content in text more efficiently than ever. However, scammers invent new ways to bypass these algorithms. And one of such ways is to use images with text scam content. Have you ever seen messages like this? Probably, you did.

## Explanation of the Feature. And this is where the Promotional Text and QR Codes in Images feature comes into action! It detects if the attached image contains text, analyzes it, if any, if the content looks like spam, and if it does, blocks the message:

Moreover, **Bocto** can determine QR codes! For example, this message with the **Astery Jewelry** flyer and QR code on it will be blocked as well if the Promotional Text and QR Codes in Images feature is enabled:

Actually, **Astery Jewelry** is absolutely legit - it is our umbrella project that you can visit using this QR code without any concerns. We put it as an example just because we have no other one. ## Image Type That This Feature Blocks. Currently, the Promotional Text and QR Codes in Images feature recognizes and blocks images with: * Text content that can be clearly determined as scam content with money offers and contacts. * Clearly readable, strictly aligned QR codes. # Guard Features Configuration To get access to the global **Guard** features settings, press the `≡ Configure` button on the corresponding feature card on the **Guard** page:

Actually, the **Guard** features have the same configuration options and, by default, provide checks for all roles (excluding bots and users with Owner and Administrator rights) in all channels. But you can configure each feature separately so that it works only for certain roles and only in certain channels. For example, the default configuration for the Not Matching HyperLinks feature below denies posting messages with mismatching links in all channels and to all roles but Bots, Server Owners, and Administrators. But if, for some reason, you want to allow posting these kinds of links for some roles or in some channels, you can set it manually:

# Guard Settings To get access to the global **Guard** settings, press the `⚙` button on the **Select a Plugin** page:

Here, you can set what **Bocto** should do if one of the **Guard** features is triggered:

## Block messages quietly. If this option is disabled, **Bocto** will block the message considered spam and display the corresponding spam type warning message visible to everyone in the channel:

If this option is enabled, **Bocto** will block the message considered spam, but won't reveal itself by displaying a warning message. ## Send logs to admins. If this option is enabled, in addition to the warning message posted in the channel where the spam message is posted, **Bocto** will also post a detailed alert to the **#alerts** channel it created during the [setup on the server](/getting-started/setup-on-server). This option is especially handy if you have enabled the Block messages quietly option.

# Mini Games # Introduction ## Overview. **Mini Games** is a plugin that provides your **Discord** server with simple games, which can increase your community engagement. ## Word Streak. This feature enables running Discord challenges where users post a selected word, such as GM, daily, for a specific period, and winners are automatically chosen when the challenge ends. ## Capabilities Comparison.

Option/Tier	Free	Plus	Premium
Simultaneous Word Streak games available	3	6	12

## Before Setup. To proceed with the collection setup, you need to enable the plugin. To do this, click on the switcher located on the left side of the top bar panel.

# Word Streak This feature enables running Discord challenges where users post a selected word, such as GM, daily, for a specific period, and winners are automatically chosen when the challenge ends. ## Preparing Channels and Setting Up the Permissions. Before starting to create the word streaks, first, you need to prepare the public channels where you want to run the streaks and the channel where you want to post their results by setting up the [correct channel permissions](/appendix/setting-up-channels-permissions). ## Word Streak Activation. To start creating the game rules, you first need to activate them. For this, go to the **Select a Plugin** page and click on the `≡ Features` button on the **Mini Games** card.

Now, activate the **Word Streak** by clicking on the switcher on the corresponding card, and confirm activation.

Now click the `≡ Configure` button on this card to visit the page with the list of Word Streaks.

## Word Streak Setup. To add your first rule, click on the `+ Add New Game` button to call the rule creation form.

For the detailed instructions on how to fill the **Word Streak** creation form, visit the corresponding page: {% content-ref url="/pages/wUkx0aqp81fWtTU6soZw" %} [Streak Creation Form](/plugins/mini-games/word-streak/streak-creation-form) {% endcontent-ref %} ## Game Card Buttons Explanation. When done, you will see the game card with the button panel in the top-right corner. * To create a **duplicate** of the streak, use the **Copy** button. * To **edit** the rule, use the **Pencil** button (streaks with `Ended` status can't be edited). * To **delete** a rule, use the **Trash bin** button.

## Game Limits Display Explanation. After adding at least one rule, a statistic widget will appear on this rule type page, where: * **Current Games** - the number of created streaks (number of cards on this page). * **Total** - for **Mini Games** is the same as **Current Games**. * **Limit** - the maximum number of streaks you can create on your active tier.

## Verification Logs Explanation. After the first game event takes place, the **Games Logs** table will appear below the game types section with the following data: * **Game Name** - the name of the game as it was given during the [creation process](/plugins/mini-games/word-streak/streak-creation-form). * **Type** - the type of the game. * **Status** - the status of the game if it is time-framed. * **Start Date** - the date and time when the game has or is going to start. * **End Date** - the date and time when the game has or is going to end. * **Participants** - the list of all users who took part in this game. * **Prizes** - the list of prizes as they were named during the [creation process](/plugins/mini-games/word-streak/streak-creation-form).

## Available Commands. You can find all available commands with a detailed explanation on this page: {% content-ref url="/pages/jLfJH4jK1mOX4LRZfFcR" %} [Commands and Widgets](/plugins/mini-games/word-streak/commands-and-widgets) {% endcontent-ref %} # Streak Creation Form ## Explanation of the Fields. * In the **Game Name** field, enter your desired streak name. * In the **Start Date** dropdown, select the day and time you want to start the streak. * In the **End Date** dropdown, select the day and time you want to finish the streak. * In the **Target words** field, type the word or words you want **Bocto** to react to. * In the **Prizes** field, type prize names. * In the **Info Channel** dropdown, select the prepared channel with the [correct channel permissions](/appendix/setting-up-channels-permissions) where you wish **Bocto** to send announcements when the streak is created and results when the streak is ended. ## Setting Up the Streak Conditions. Required Fields.

### The End Date Setup Recommendation. Since **Word Streak** counts only one mention of the target word(s) per day per user, we recommend setting the game duration to more than 1 day (1 week or more is ideal). However, to test how it works, you can set it to even 1 minute. ### The Target Word Field Tricks.

{% hint style="success" %} More than one word (*e.g., gm, good morning*) in the **Target words** field is acceptable. Separate words with commas if you wish to add more than one target word. {% endhint %} {% hint style="success" %} Don't care about the case - Bocto will count the word typed as *gm* or *Gm* or *GM* as the same word. {% endhint %} {% hint style="success" %} Emojis are acceptable - use any regular emojis (like ☕,💜,🔥,💍or any other) as one word or separated by commas if you want to make the streak more specific or fun. {% endhint %} {% hint style="success" %} Running several word streaks simultaneously is acceptable. Even duplicates of streaks with the same target word running simultaneously are acceptable! We have no idea why you need to use it, but if you will - it works! {% endhint %} {% hint style="danger" %} You won't be able to change the target word after the word streak is created! {% endhint %} ### The Prizes Setup Recommendation. You can set up to three prizes for the game, but only the first-place prize is required. The prizes for 2nd and 3rd place are optional, and you can keep these fields blank. ## Setting Up the Streak Conditions. Optional Fields. By default, the target word(s) are triggered by all roles in all public channels (and also private channels, where **Bocto** was added manually).

However, you can configure it so that it reacts only for certain roles and/or only in certain channels.

{% hint style="warning" %} The server owner and users with Administrator permissions will be excluded from exceptions, meaning **Bocto** will always respond to their messages containing the target word(s). {% endhint %} # Game Timeline ## When the Game is Created. After the word streak is created, a light-green embedded announcement message with the streak details will be posted in the **Discord** channel you chose as the **Info Channel**.

## When the Game is Started. After the word streak started, every day a user posts a message containing the target word(s), **Bocto** will reply with a random phrase and add a point to the user's score.

{% hint style="warning" %} Only the one (the first one) mention of a target word per day counts. If several target words are added in the [streak creation form](/plugins/mini-games/word-streak/streak-creation-form), only the mention of one of them counts for this day. {% endhint %} {% hint style="info" %} If the user misses one day, the streak count will not be reset to zero and will continue the next day. {% endhint %} ## When the Game is Finished. After the word streak ends, a purple embedded message with detailed leaderboard and results will be posted in the **Discord** channel you selected as the **Info Channel**. If multiple users have the same score, one will be chosen at random.

{% hint style="warning" %} Don't ask us why some usernames rendered as IDs - we don't have a clue!😁 It is a **Discord** issue, and there is no difference for **Bocto** between them. Just don't mind. {% endhint %} {% hint style="danger" %} And don't forget to send the promised prizes! {% endhint %} # Commands and Widgets The Word Streak offers a set of Discord commands to give users various types of statistics. here is the list of all of them. ## Current Server Active Streaks List. The `/wordstreak-events` command shows the embed with a list of all active **Word Streak** events on the current server and their details.

{% hint style="info" %} This message can only be seen by the user who launched the command. {% endhint %} ## User's Current Server Active Streaks Progress. The `/wordstreak-user-streak` command shows the embed with a list of user progress in all active **Word Streak** events on the current server. Run the command. It will ask you to select a user whose progress you want to see:

If you wish to check your own progress, then choose your name. The embed with the list of active streaks on this server that the user took part in will appear:

{% hint style="info" %} This message can only be seen by the user who launched the command. {% endhint %} ## User's Cross-Server All-Time Streaks Stats. The `/wordstreak-global-user-stats` command shows the embed with all-time **Word Streak** stats across all **Bocto** servers. Run the command. It will ask you to select a user whose global stats you want to see:

If you wish to check your own stats, then choose your name. The embed with the global statistics across all streaks that have ever happened on any server and that the user has ever taken part in will appear:

{% hint style="info" %} This message can only be seen by the user who launched the command. {% endhint %} ## Top 10 Current Server Active Streaks Leaderboard. The `/wordstreak-leaderboard` command shows embeds with the Top 10 **Word Streak** leaderboard for each active streak on the current server.

{% hint style="warning" %} This message is visible to all users. {% endhint %} ## Full Current Server Active Streaks Leaderboard. The `/wordstreak-leaderboard-paged` command shows the embed with the full **Word Streak** leaderboard for a particular event with pagination. Run the command. The embed with the dropdown containing the active streaks list will appear:

Click on the desired streak. The embed with the full leaderboard, divided into pages with 10 users per page and pagination, will appear:

{% hint style="info" %} This message can only be seen by the user who launched the command. {% endhint %} ## All-Time Global Users Top. The `/wordstreak-global-users-top` command shows the embed with the all-time **Word Streak** users leaderboard across all **Bocto** servers.

{% hint style="info" %} This message can only be seen by the user who launched the command. {% endhint %} ## All-Time Global Servers Top. The `/wordstreak-global-servers-top` command shows the embed with the all-time **Word Streak** servers leaderboard (top guilds by streak activity).

{% hint style="info" %} This message can only be seen by the user who launched the command. {% endhint %} ## Important! To allow users to use these commands in the desired channel, don't forget to grant the Use Application Commands permissions to the desired roles in the channel settings!

# Utilities {% content-ref url="/pages/tTH5QAh5VmGZPoaZKjw7" %} [Introduction](/plugins/utilities/introduction) {% endcontent-ref %} {% content-ref url="/pages/zTgdbPuNzAGLQTH0BXKu" %} [User Activity Tracker](/plugins/utilities/user-activity-tracker) {% endcontent-ref %} {% content-ref url="/pages/hBgtD5kuXlZX5v1y3uTh" %} [User Wallet Storage](/plugins/utilities/user-wallet-storage) {% endcontent-ref %} # Introduction ## Overview. **Utilities** is a plugin that provides your **Discord** server with simple, handy tools that make your teammates' lives easier by automating some types of routine work. ## Utilities List. ### User Activity Tracker. This feature enables tracking users' activity (counts messages sent during a specific time interval) on demand and shows the resulting table after being stopped. ### User Wallet Storage. This feature allows quick access to user wallets across all Bocto guilds. ## Before Setup. To start using the utilities, you need to enable the plugin. To do this, click on the switcher located on the left side of the top bar panel.

# User Activity Tracker This feature enables tracking users' activity (counts messages sent during a specific time interval) on demand and shows the resulting table after being stopped. ## Use Case. This feature was originally invented to help us count users' messages during our daily live rumbles on **OctoPeeps** server, which we run in person, starting it manually. Of course, we want to encourage our users to make us a company and have some fun in the chat together. That is why we provide custom rumble rewards depending on the number of messages users have sent during the match. However, counting all the messages manually every time was always quite annoying. Now, the **User Activity Tracker** does it for us. And, since this is our only use case for this utility at the moment, in this guide, we will demonstrate how this feature works specifically on it. So, before we start the rumble, we launch the **User Activity Tracker** using `/start-activity-tracker` command. Now, every time users post messages or GIFs, Bocto counts them:

And when the rumble is over, we stop the **User Activity Tracker** using `/stop-activity-tracker` command and get the embed message with the results:

Now we can use this data to give different amounts of coins to users, thus making the reward process much fairer, rather than using the default rumble results, which do not take into account real users' engagement. ## Feature Specifics. * This feature does not count messages shorter than one character unless they are an emoji, image, or GIF. * Being started, this feature works across all your channels. That is, you can not launch more than one tracker at a time. * If you want to exclude messages in certain channels or from certain roles, or admins from the count, you can set the exceptions in the [feature configuration](https://app.gitbook.com/o/PP99adWq6pg0a9ekqlE1/s/nX757myueIMa0YXG4HJl/~/changes/69/plugins/utilities/user-activity-tracker#user-activity-tracker-configuration). * This function can only be started and stopped manually when needed using the available commands. ## User Activity Tracker Activation. To activate the **User Activity Tracker**, go to the **Select a Plugin** page and click on the `≡ Features` button on the **Utilities** card.

Now, activate the **User Activity Tracker** by clicking on the switcher on the corresponding card, and confirm activation.

## User Activity Tracker Configuration. After activation is done, you need to configure the feature. To do this, click the `≡ Configure` button on this card to visit the feature settings page.

On the settings page, there are two sections. In the SETTINGS section, you can exclude admins from the count if you don't want they to participate in the activity competition. In the PERMISSIONS section, you can exclude certain roles from the count if you don't want they to participate in the activity competition, or certain channels if you don't want to count messages in certain channels during the event.

## Available Commands. `/start-activity-tracker` Start tracking the number of messages sent by users in the current channel. \ `/stop-activity-tracker` Stop tracking users' activity in the current channel. # User Wallet Storage This feature allows quick access to user wallets across all Bocto guilds. ## Use Case. Almost every community has active users who constantly win prizes. And every time these users come to claim their reward, the manager has to ask for their wallet addresses again to ensure that nothing has changed since the last time. It makes the process longer, adding +1 step to the communication. However, as far as **Bocto** collects users' wallets across servers via [**Verify Roles**](/plugins/verify-roles), we can provide access to them to every server manager. All you need to do is use a special command, and if the user previously passed the NFT verification on one of the servers with **Bocto**, you will see the list of all wallets they added:

You can find the detailed guide on [how to use](#how-to-use) this feature at the end of this page. ## User Wallet Storage Activation. To activate the **User Wallet Storage**, go to the **Select a Plugin** page and click on the `≡ Features` button on the **Utilities** card.

Now, activate the **User Wallet Storage** by clicking on the switcher on the corresponding card, and confirm activation. That's all, now you can use the command on your server!

## Available Commands. `/get-user-wallets` Get all wallet addresses associated with a user across all Bocto guilds. {% hint style="success" %} This command can be used only by roles with Administrator permissions, so you don't have to worry about other users running it and seeing someone else's wallets. {% endhint %} ## How to Use. Run the `/get-user-wallets` command in the support ticket and select the user. You will only see the list of users who have access to this channel:

Then press Enter to confirm. If the user previously added at least one wallet to our system via any server with **Bocto**, you will see the embed with their wallet list:

If the wallet is not in our system, you will see another embed:

# Setting Up Channels Permissions This is the additional information page and you can skip it until you will be readdressed here from other sections of the documentation when needed. ## The Common Problem with the Permissions. Most **Bocto** plugins operate in public channels with the default rights granted to the bot during the [Setup process](/getting-started/setup-on-server). Although even if a channel seems to be public, from a technical point of view, it may still be private. If it's really the case, **Bocto** will not be able to post any messages in such a channel and probably will not be able to warn you about it at the time! You will see the alert only in the **#alerts** channel and on the **Bocto** Dashboard **Settings** page when the first unsuccessful posting attempt to the channel takes place. To prevent this, ensure that the channel you want **Bocto** to post something in is really public by looking at its name in the sidebar - if there is no 🔒 icon on a **#** sign, then everything is set up correctly, but if you see one, that means you've probably used an incorrect settings combination for the **@everyone** role.

### But why did it even happen? The **@everyone** role is a system role, and its permissions must be configured specially so that all bots on your server can operate in public channels normally. And here, we need to dive deeper into the **Discord** role permissions concept, which recognizes two types or levels of permissions for every role, especially for the **@everyone** role: * **Global level** (when the role permissions are applied to all channels across the server by default in the server settings). * **Local level** (when the same role permissions are set manually for every channel, thus overriding these are set on a Global level). Actually, this concept is quite simple and works as follows: You can assign global permissions to every role in the global **Discord** settings and change some of the same role permissions in every channel locally, depending on your needs. And sometimes it happened the way that you've granted the View Channels permission for **@everyone** on the global level and forgot about it. And lately, to hide public channels from the users with this role (unverified users), you directly restrict this permission locally in these channels' settings, thus turning them into technically private ones. This failure combination of the permission settings looks like this:

The View Channels permission granted for **@everyone** on the global level - never do this!

The View Channels permission revoked from **@everyone** on the local level at the same time.

{% hint style="danger" %} Just remember - every time you activate the red cross button in front of View Channel permission for the **@everyone** role in the **Channel Permissions**, it makes the channel private, and, in most cases, inaccessible for **Bocto** even if some roles besides **@everyone** have permission to post in this channel! So we need to avoid this! {% endhint %}

### What can you do with it? Just make the channel public again and reconfigure your server settings the way it works without the necessity of revoking the View Channels permission for the **@everyone** role in public channels, or, if not applicable, keep them private and continue reading to learn how to set up custom permissions for **Bocto** in private channels. ## Separate Permissions for Bocto in Private Channels. Earlier, we studied how to provide **Bocto** access to your public channels by default, not to mess with its permissions manually. But what if you want to allow **Bocto** to operate in some private channels? In this case, you need to grant **Bocto** the View Channel permissions for these channels manually. To be more precise, you need to grant this permission to the **@Bocto** role. Let's, for example, imagine you want to run the **Word Streak Game** from the **Mini Games** plugin in your **#holders-chat**, which is, of course, a private one. That means that, unlike **#public-chat**, **Bocto** does not have access to it by default. And when creating a game and choosing this channel, after a short check, you will see the alert like this:

So you need to grant **Bocto** the View Channel permissions for this channel manually. To be more precise, you need to grant this type of permission to the **@Bocto** role. To do this, go to **Discord**, open the **#holders-chat** (or corresponding) channel settings, move to the **Channel Permissions** section, and press the **Add members or roles** button.

Now find **Bocto** in the **Roles** list and set the check mark against it. Press the **Done** button.

You will now see **Bocto** in the **ROLES/MEMBERS** list in the **Advanced permissions** section. Select it, and forcibly allow the View Channel permission by clicking on a green check mark.

After this, go back to the **Bocto**** Dashboard**, close the game creation form, and open it again. This time, when you choose the **#holders-chat** channel, the alert won't appear. {% hint style="success" %} Use this trick every time you receive a message in the **Dashboard** or in the **#alerts** channel indicating that **Bocto** does not have access to post messages or perform other actions in certain channels. {% endhint %} # Getting Collection Slug/Symbol This is the additional information page and you can skip it until you will be readdressed here from other sections of the documentation when needed. Before you proceed with adding a collection to the **NFT Stats** or tracking its listings and sales with the **NFT Tracker** or setting up a Specific Traits-Based Roles rule with the **Verify Roles** plugin, you first need to prepare the Collection Slug (for the collections listed on **OpenSea**) or the Collection Symbol (for the collections listed on **Magic Eden**). Technically, this is absolutely the same thing, just named differently on these two marketplaces. So let's call it Collection Slug for shot. Well, the Collection Slug is a part of the marketplace collection URL in the browser address bar, normally located after the last slash, but not always. ## Collection Slug on OpenSea.

## Collection Symbol on Magic Eden.

## Contract Address on LooksRare. The collections listed on **LooksRare** do not have a Collection Slug, and you don't need it. However, you will need the collection Contract Address, which can be found in the same way, at the end of the collection URL.

## Collection Symbol on Magic Eden.

## Collection Slug and Contract Address on Rarible. On **Rarible**, the real Collection Slug is not needed, so you can skip this step if you are going to add a collection listed on this marketplace. But if you still want to use the original Collection Slug, you should keep in mind that on **Rarible**, it has a different location. For the collection, listed on **Rarible**, you will also need its Contract Address. You can easily find it under the collection description if you click on the **Copy** icon.

## What's next? Now, when you have your Collection Slug, you can proceed with [adding a collection](/plugins/nft-stats/adding-new-collection-with-rarible) to the **NFT Stats** or tracking a collection's listings and sales with the **NFT Tracker** or setting up a [Specific Traits-Based Roles](/plugins/verify-roles/introduction#specific-traits-based-roles) rule with the **Verify Roles** plugin. # Getting Collection Contract Address This is the additional information page and you can skip it until you will be readdressed here from other sections of the documentation when needed. Before you proceed with adding a collection to the **NFT Stats** or tracking its mint events with the **NFT Tracker** or setting up token-gated rules for it with the **Verify Roles** plugin, you first need to prepare the Contract Address (for the collections on **Ethereum**, **Polygon**, and **Solana**). ## **EVM Collections.** With the collections built on EVM blockchains like **Ethereum** or **Polygon**, things are going pretty easily. If you are reading this text, that highly likely means that you are the owner and creator of the collection and will know its **Ethereum** or **Polygon** contract address. If, for any reason, this is not true and you are being confused with getting the EVM blockchain-based collection contract address, let us know, and we will add this information to this section. ## Solana **Collections.** Well, at the same time, **Solana** collections have a particularly challenging way of obtaining the correct collection contract addresses, even for their creators! It happens due to the different types of address structures for various collections – some have traditional collection addresses, while others do not. This guide will provide the most universal method for obtaining the correct address to enter in the **Verify Rule** card **Contract** field.

**Note:** If you don’t mind doing some grunt work but read less, then move directly to the [**General concept of address extraction**](https://app.gitbook.com/o/PP99adWq6pg0a9ekqlE1/s/nX757myueIMa0YXG4HJl/~/changes/13/plugins/verify-roles/verification-rules-setup/solana-collections#general-concept-of-the-address-extraction) at the end of this guide. *** ### For collections on Magic Eden. #### **Action 1.** Open the card with any token in the desired collection and scroll it down. If you see the *On-chain Collection* address – that’s perfect – use it right away in the **Verify Rule** card **Contract** field, and we're done here! If there is no – move to the next action.

#### **Action 2.** If there is no *On-chain Collection* address in the **Details** section, then copy the *Mint* address instead and move to the next action.

#### **Action 3.** Now visit and paste the *Mint* address you've just copied from the search field. Wait a second for it to appear in the dropdown, then click on it.

#### **Action 4.** Now, copy the *UPDATE AUTHORITY* address and use it in the **Verify Rule** card **Contract** field.

#### **Just in case**** 👇** * For the collections that have *On-chain Collection* addresses, the *UPDATE AUTHORITY* address will always be different for every NFT in the collection. * For the collections that have no *On-chain Collection* addresses, the *UPDATE AUTHORITY* address will always be the same for every NFT in the collection. *** ### For collections on Tensor. #### **Action 1.** Open the card with any token in the desired collection and click on a blue link in the **Mint** string. You will be automatically redirected to the corresponding page on [https://solana.fm](https://solana.fm/)

#### **Action 2.** Here you will see the *COLLECTION ADDRESS* – use it in the **Verify Rule** card **Contract** field. In case there is no *COLLECTION ADDRESS*, use *UPDATE AUTHORITY* instead.

*** ### For collections on Mooar. #### **Action 1.** Open the card with any token in the desired collection and expand the **Details** section.

If you see the *Contract Address* string – that’s perfect – use it right away in the **Verify Rule** card **Contract** field, and we're done here! If there is no – move to the next action. #### **Action 2.** If there is no *Contract Address* string in the **Details** section, then click on the *Token ID* link – it will lead you to where you need to open the **Authority** dropdown menu and copy the *Update Authority* address. Now, use it in the **Verify Rule** card **Contract** field.

*** ### General concept of address extraction. If trying to extract the needed address, you will be facing any outstanding situation which is not described in this guide, then the general concept is: you need to somehow extract any token address from the desired collection, search it on and then get the *COLLECTION ADDRESS* or the *UPDATE AUTHORITY* address in case the *COLLECTION ADDRESS* is missed. To do this, follow the steps below: #### **Action 1.** If the NFT on the marketplace opens in a pop-up but not on the new page, expand the NFT card of the token from the desired collection via the special button (**ME** or **Tensor**).

#### **Action 2.** Copy the final segment of the URL directly from your browser's address bar. This section may vary across different marketplaces and collections, but you only need the last portion.

#### **Action 3.** Search the address on and get the *COLLECTION ADDRESS* or the *UPDATE AUTHORITY* address in case the *COLLECTION ADDRESS* is missed. *** ## What's next? Now, when you have a correct **Solana** NFT collection Contract Address, you can proceed with tracking its mint events with the **NFT Tracker** or setting up token-gated rules for it with the **Verify Roles** plugin. # Getting a Custom Coin Address # Server vs Channels Permissions This is the additional information page and you can skip it until you will be readdressed here from other sections of the documentation when needed. ## The Common Problem with the Permissions. Most **Bocto** plugins operate in public channels with the default rights granted to the bot during the [Setup process](/getting-started/setup-on-server). Although sometimes, even if a channel seems to be public, from a technical point of view, it is still private. If it's really the case, **Bocto** will not be able to post any messages in such a channel and probably will not be able to warn you about it at the time! You will only see the alert in the **#alerts** channel and on the **Bocto** Dashboard **Settings** page when the first unsuccessful posting attempt to the channel takes place. To prevent this, ensure that the channel you want **Bocto** to post something in is really public by looking at its name in the sidebar - if there is no 🔒 icon on a **#** sign, then everything is set up correctly, but if you see one, that means you've probably used an incorrect settings combination for the **@everyone** role.

### But why did it even happen? Here, we need to dive deeper into the **Discord** roles concept, which recognizes two types or levels of permissions for every role, especially for **@everyone**, which is a system role: * **Global level** (when the role permissions are applied to all channels across the server by default in the server settings). * **Local level** (when the same role permissions are set manually for every channel, thus overriding these are set on a Global level). Actually, this concept is quite simple and works as follows: You can assign global permissions to every role in the global **Discord** settings and change some of the same role permissions in every channel locally, depending on your needs. And sometimes it happened the way that you've granted the View Channels permission for **@everyone** on the global level and forgot about it. And lately, to hide public channels from the users with this role (unverified users), you directly restrict this permission locally in these channels' settings, thus turning them into technically private ones. This failure combination of the permission settings looks like this:

### What can we do with it? There are two main ways to configure permissions on your server. The first prevents public channels from becoming technically private, thereby blocking bot activity in those channels. The second involves manually reassigning permissions for each channel. The common staff for both is that you need to set all the permissions for the **@everyone** role on the global level to be turned off. This is actually the default **Discord** setting when users with the **@everyone** role only do not have any permissions, even to view channels. Let's set it up. For this, open the **Discord s**erver settings (Global settings):

Then choose **Roles**, and at the top of the main section, you will see the **Default Permissions** block. Click on it to get access to the **@everyone** role global settings.

If the Clear permissions link is active, click it - it will turn all the switches off. This means new users will not see anything when they join your server. Don't worry, we will fix it soon.

This is exactly how users with the **@everyone** role only, which is configured using the default settings for every channel, should see your server, in case you didn't change any permissions settings locally via channel settings:

But what if you want to make some channels visible to users (which means make these channels technically public), but prevent posting there or performing other actions for users with the **@everyone** role only? Here we come to our methods mentioned above. ## Method 1. Setting Up a Middle-Man Role with Basic Permissions. The main idea of this method, [after you've disabled all **@everyone** role permissions globally](https://app.gitbook.com/o/PP99adWq6pg0a9ekqlE1/s/nX757myueIMa0YXG4HJl/~/changes/48/getting-started/server-and-channels-permissions#what-can-we-do-with-it), is to automatically assign a special custom **@Verified** role with basic permissions (View Channels, Send Messages and Create Posts, Send Messages in Threads and Posts, Add Reactions, Read Message History) to those who perform certain actions, such as clicking on a reaction under a message in the only channel where the View Channels permission for the **@everyone** role was forcibly overridden to "Allowed" manually via channel settings (i.e., locally). This is how it usually looks:

As far as unlike the **@everyone** role, the **@Verified** role is a custom one, but not a system one, it allows to keep all the public channels technically really public (without a 🔒 icon on a **#** sign in the channel's name) which is in its turn allows **Bocto** (and other bots on your server) to operate in these channels without any manual interuption into these channels settings from your side, while the management of all basic permissions is now handled by the **@Verified** role at a custom level. This is the preferred method and the most common practice you can meet on many servers, or you might even be using it too. But the disadvantage of this approach is that it requires setting up a bot that provides the Reaction Roles functionality, which is sometimes a paid option. If you're okay with this, please read this guide. If not, try to find a free alternative, or proceed with [**Method 2**](https://app.gitbook.com/o/PP99adWq6pg0a9ekqlE1/s/nX757myueIMa0YXG4HJl/~/changes/48/getting-started/server-and-channels-permissions#method-2.-custom-permissions-for-roles-in-channels). If, [after disabling all **@everyone** role permissions globally](https://app.gitbook.com/o/PP99adWq6pg0a9ekqlE1/s/nX757myueIMa0YXG4HJl/~/changes/48/getting-started/server-and-channels-permissions#what-can-we-do-with-it), you've chosen this method, i.e., to autoassign a custom **@Verified** role with basic permissions, which can be gotten by clicking the reaction, you need to set up the bot that provides the Reaction Roles feature. Let us show you how to do this with an example of the most popular Discord bot, MEE6, which has this feature (that, unfortunately, has recently become available only on their Premium plan). Visit the [MEE6 website](https://mee6.xyz/), set up the MEE6 bot, and pass through all the necessary procedures. Here, we will not discuss how to do it, as it is a topic of the MEE6 setup guide. So let's imagine you've already set it up. Now move to the Reaction Roles page and click on ✅ **Verify** block to enter the Reaction Roles setup page.

Here, in the Channel section, keep the **Create one for me** option or choose the custom channel. For the new Discord users, it would be better to allow MEE6 to do all the grunt work for them - like make this channel public and visible for **@everyone**. So let's keep this option as it is.

In the Message section, just enter something like this:

Message text sample

**Rules** * Be respectful. Treat others the way you want to be treated. * No spamming. * No NSFW content. * Do not leak any personal information. * No shilling. * Keep all discussions in the relevant channels. If you are NOT a robot, tap the ✅ reaction.

In the Reactions and Roles section, keep everything as it is. The **@Verified** role will be created automatically or detected if, for some reason, you already have a role with this name on your server. In the Reactions Mode section, keep the Default option.

After that, you need to check if the **@everyone** role permissions for all the public channels on your server are set up like this:

Now, only **@Verified** users will be able to see public channels, while users with just the **@everyone** role will only see the **#access-verify** channel created by MEE6 with the embedded message we set in this bot and a ✅ reaction under it. Same time, as we didn't manually prohibit the **@everyone** role from viewing the public channels, Bocto can operate in them without any special settings. Do you remember our #rich-stats channel with the 🔒 icon on a **#** sign from the first image in this guide? Let's see how it looks now:

But, if for some reason you need to allow some Bocto functions to operate in private channels, read this article. ## Method 2. Setting Up Custom Permissions for the Roles. The main idea of this method, [after you've disabled all **@everyone** role permissions globally](https://app.gitbook.com/o/PP99adWq6pg0a9ekqlE1/s/nX757myueIMa0YXG4HJl/~/changes/48/getting-started/server-and-channels-permissions#what-can-we-do-with-it), is to override the permissions for all roles, including the **@everyone** role, on a local level in every channel. This is a very lame method because you don't have a middle-man role, like [automatically assigning by MEE6 **@Verified** role](#method-1.-assigning-a-verified-role-with-mee6), which serves as a buffer between users who, by default, have no permissions at all, and those who have all basic permissions in public channels. Of course, you can create and set up the permissions for this role manually, but it is pointless because you will have to assign it manually as well. So you won't be able to differentiate users' access flexibly anyway, and the solution here is to make your server private (for your holders only), keeping only the **#nft-verify** channel (or some info channels too) visible for **@everyone**, and assigning roles to your holders only via our **Verify Roles** plugin. For this, follow this guide. If you've chosen method 2, i.e., to override the global permissions for every role on a local level manually for every single channel, you need to directly grant to every role on your server, including the @Bocto and the **@everyone** role, the desired permissions. ### Special local permissions for the @everyone role. Let's get started with the **@everyone** role. For example, if you want to make some channels like **#about-project** or **#nft-verify** visible for **@everyone**, you need to open channel settings and forcibly allow View Channel and Read Message History for this role directly:

This is how the user with the **@everyone** role only now sees the server:

Great! Now, when we created the entry point for **@everyone** on our "Holders only" server, we could [set up verification rules](/plugins/verify-roles/introduction) to provide our holders access to other channels on the server. But first, let's double-check if the **@everyone** role permissions for all the public channels on your server are set up like this:

And, as we didn't manually prohibit the **@everyone** role from viewing the public channels, Bocto can operate in there without any special settings. Do you remember our #rich-stats channel with the 🔒 icon on a **#** sign from the first image in this guide? Let's see how it looks now:

But, if for some reason you need to allow some Bocto functions to operate in private channels, read this article. ### Special global permissions for other roles. Well, we've done half of the work - Bocto operates correctly, and the **@everyone** role's only users can see just one channel where they can get their holder roles. But what about these holder roles? Let's imagine our **@everyone** role user just passed the verification and got the **@At least 1 Kiddo NFT** role. This is how he sees the server now:

Yes! This is absolutely the same picture you've already seen above! Why? Just because, as we told, we need to reassign all the needed permissions to every role on both global and local levels. So let's do it. Let's open server settings again, move to the Roles, choose the **@At least 1 Kiddo NFT** role in the list, and proceed with the **Permissions** tab. Here, we need to turn on View Channel and the Read Message History switches.

We've just set these two permissions for this role by default globally, which means they apply to every public channel across the server until you restrict them on a local level via specified channel settings. Now our user with the **@At least 1 Kiddo NFT** role sees the server like this:

That's much better! He sees all the public channels and all the previous messages in there, but can't post in chats. But why didn't we allow Send Messages and Create Posts, Send Messages in Threads and Posts, and Add reactions permissions for this role by default as well? Because in this case, he will also be able to post in info channels like **#nft-stats** or **#nft-verify**! We could do it, of course, and then revoke these rules from this role in info channels via the channel settings, so you can use this strategy for sure if you feel it is more suitable for your case. But let us follow the contrarian strategy and add these permissions via the channel settings to the channels where we really need them. ### Special global permissions for other roles. In our case, we want to allow the **@At least 1 Kiddo NFT** role users to send messages and add reactions in the **#holders-chat** only. So let's add this role to the permissions list and set it up. In the **Channel Permissions** settings, click on this small `⊕` button in the **Advanced** **permissions** section to call the dropdown menu with the list of all server roles:

In the dropdown, select the role you want to add:

Finally, forcibly allow the desired permissions by clicking on a green check marks:

You can keep View Channel and Read Message History permissions here as they are, as long as they are already granted to this role by default globally. Now, for the **@At least 1 Kiddo NFT** role members, the server will look like this:

{% hint style="success" %} If you used **Method 1** to configure the basic permissions, you can make similar changes to the **MEE6** **@Verified** role, configuring it as needed if its standard settings do not meet your requirements. {% endhint %} ## Method 3. Setting Up Custom Permissions for the Private Channels. Earlier, we studied how to provide **Bocto** access to your public channels by default, not to mess with its permissions manually, and how to configure other roles' permissions for these channels. But what if you want to allow **Bocto** to operate in some private channels? In this case, you need to grant **Bocto** the View Channel permissions for these channels manually. To be more precise, you need to grant this permission to the **@Bocto** role. And technically, it can be considered as **Method 3**. Let's imagine that, in addition to our **#holders-chat**, we also have the **#top-holders-rumble** channel, which is private and accessible to only **@More than 5 Kiddos** role members. Let's open the channel settings and look at the **Channel Permissions** section:

Here, press the **Add members or roles** button.

Now find **Bocto** in the Roles list and set the check mark against it. Press the **Done** button.

You will now see **Bocto** in the ROLES/MEMBERS list in the **Advanced permissions** section. Select it, and forcibly allow the View Channel permission by clicking on a green check mark.

{% hint style="success" %} Use this trick every time you receive a message in the **Dashboard** or in the **#alerts** channel indicating that **Bocto** does not have access to post messages or perform other actions in certain channels. {% endhint %}