✏️/configure-tokenroles update

Update an automatic token role

When dealing with token roles, you might need to adjust your settings after the initial creation. Maybe you are switching to a different role or want to introduce a max-count for your role. With /CONFIGURE-TOKENROLES UPDATE this is as easy as passing in the token role ID to update and your new settings.

This command shows its true power when using the different aggregation-type options in combination with the /CONFIGURE-TOKENROLES POLICIES ADD and /CONFIGURE-TOKENROLES METADATAFILTER ADD subcommands. Check out our parameter explanation below and visit the Tutorials section for detailed guides on various scenarios.

Via the staking-type parameter it is possible to include tokens that are not currently in the users wallet, but can through some means be identified as currently owned by them, like with staking systems that provide an API to list assets staked, for example Mutant NFT Labs .

Parameter	Details
token-role-id	The token role ID (taken from /CONFIGURE-TOKENROLES LIST) to change the settings for.
[role]	The new Discord role verified users will be assigned if they meet all requirements.
[count]	The new minimum token count required to qualify for the role.
[max-count]	The new optional maximum token count allowed to qualify for the role (owning more tokens than this number will disqualify a user for this role). Pass in 0 if you currently have a maximum token count and want to remove it.
[aggregation-type]	The aggregation type defines four powerful ways in which your token role policies (added via /CONFIGURE-TOKENROLES POLICIES ADD) and metadata filters (added via /CONFIGURE-TOKENROLES METADATAFILTER ADD) get aggregated, to allow for advanced token roles, which enable common scenarios NFT projects often want to implement. Find our examples below: Any policy of the role, each NFT must match all filters The standard setting means that every filter associated with the role will be checked against all tokens of the configured policies in the users verified wallets. Only tokens that match every filter will be counted. If the total count of accepted tokens is count or above, the role will be granted. Any policy of the role, each NFT must match at least one filter The any filter setting means that every filter associated with the role will be checked against all tokens of the configured policies in the users verified wallets. Any token that matches at least one filter will be counted. If the total count of accepted tokens is count or above, the role will be granted. Any policy of the role, each filter must be matched by one unique NFT This is the “collect them all” setting for your token roles. With this option, the user is required to have at least one token (out of all allowed policy IDs) matching each of the metadata filters. For example, if you have five different pet traits, you can add one filter for each trait, and turn on this aggregation-type. Now only users that hold all five different pets will receive the role. Each token will be counted at most once, i.e. it cannot qualify a user for multiple different filters if non-exclusive filters are used. Use Any policy of the role, all filters must be matched if one NFT is allowed to qualify for multiple different filters. When this mode is enabled, the count and max-count settings are ignored and the required token count is equal to the number of added metadata filters. At least one NFT of each defined policy is required If you have multiple policies under which you minted and you want your users to only receive a role if they have at least one token from each policy, this aggregation-type is the one to use. With it metadata filters apply with the every filter must match rule, but the user is required to have one token from every policy defined via /CONFIGURE-TOKENROLES POLICIES ADD. When this mode is enabled, the count and max-count settings are ignored and the required token count is equal to the number of added policy IDs. Any policy of the role, all filters must be matched With this option, the user is required to have at least one token (out of all allowed policy IDs) matching each of the metadata filters. For example, if you have three gold traits, you can add one filter for each trait. Then turn on this aggregation-type. Now only users that have tokens covering all required traits get the role. This could be one token that has all three gold traits, or three tokens that each have one of the three different traits. When this mode is enabled, the count and max-count settings are ignored and the role is assigned if all filters are matched, regardless of the exact owned token count.
[staking-type]	The staking type lets you define staking-related settings for your roles: No additional staking rules apply The standard setting None means that no special attempts to retrieve holder information are made beyond checking all verified stake addresses for tokens. Any tokens or NFTs in custodial staking systems, non-custodial staking systems that alter the staking part of the tokens, or smart contracts, are not checked for the purpose of role assignments. Include NFTs staking with Mutant Labs for token roles If the MutantNFT staking type is selected, any tokens held in the MutantNFT staking system are included in the overall token and NFT ownership counted for the user. The information is retrieved via the users verified stake addresses and the MutantNFT API.