Multi-Issuers: How can I ensure my tokens share the same qualification module? (2/2)

By default, when deploying a new token, a KYC claim named "Default KYC Claim" with a unique Claim Topic ID is pre-selected. Each unique Claim Topic ID creates a new Identity Registry Storage. In practice, this means that a unique Topic ID and its associated Identity Registry Storage inherently do not support reusing the Qualification module, as the qualification criteria differ at the token level by design.

However, if you have an existing token (e.g., T0) with an active qualification module that you’d like your new token (T1) to use — and both tokens share the same qualification criteria — you must update T1’s eligibility criteria before deployment to reuse the claim from T0.

Finally, before proceeding with deployment, ensure that T1 has only one claim associated with it: the shared claim from T0. The default "KYC Claim" on T1 must be deleted, leaving only the T0 claim in use for T1.

Reusing claims ensures consistency in identity eligibility rules across tokens, which is especially helpful when applying the same KYC requirements across multiple tokens.

Important: please make sure to update the claim configuration before deploying the token if you want it to reuse the same qualification module. Once deployed, the claim CANNOT be edited. If the same claim isn't applied, you will need to deploy a new token.

We understand that, despite our best efforts, the definition above might initially feel abstract or difficult to grasp. To make it easier to understand, we’ve provided a detailed, visual explanation of the process for reusing claims in the interactive video below.

1. Begin by selecting the token (T0) whose qualification module you want the new token (T1) to share. In this case, we want the token being deployed to use the same claim as token ASA (T0).

2. Continue by selecting 'Token'.

3. Next, choose Settings from the options.

4. To view the claim applied to ASA, click on 'Identity eligibility'.

5. Here, you'll see the name and ID of the applied claim—this corresponds to the name you assigned to your shared claim during the deployment of the first token.

6. Here, you'll find the Topic ID along with a list of tokens that share this claim, eligibility criteria, and qualification module.

7. Now that we've identified the claim for the next token, we can proceed with token creation by clicking the 'Plus' button.

8. Next, initiate the creation of an ERC3643 token.

9. Enter the desired name for the token.

10. Set the token symbol.

11. Set the decimal places for your token.

12. Afterwards, select the network.

13. Next, select the instrument type. Our token, Onsen, represents Equity.

14. Now, select the base currency of your token.

15. Next, upload the token logo by either dragging and dropping the image or selecting it to upload.

16. Then, click 'Save and continue'.

17. Next, head to "Identity Eligibility" to adjust the claim configuration. Warning: Be sure NOT to deploy the token before editing the claim configuration if you wish this token to reuse the same qualification module. The claim CANNOT be edited once deployed. If you fail to apply the same claim, you will need to deploy an entirely new token.

18. You can observe that the Default KYC claim is pre-set by default.

19. Click on 'Add an existing claim' to select the claim used by your other tokens.

20. All your existing claims will be listed here. We will select the 'SuperShared Claim' from the list. Your list will look different and will display the names of your own claims, which you edited/saved during the deployment of your first token.

21. Confirm your selection by clicking on 'Save'.

22. Click on the 'X' icon to remove the default KYC claim.

23. Confirm the removal of the claim by clicking here.

24. Now, deploy your token by clicking 'Deploy token'.

25. Finalize by clicking on 'Yes, deploy'.

26. Once your token is deployed, you can verify that the correct shared claim has been applied by navigating to 'Token' > 'Settings'.

27. Click on 'Identity eligibility'.

28. You can confirm that the same shared claim has been applied. This ensures that your tokens will now share the same qualification module.