Airdrop the same token to many owners
Suppose that you have already created a Kudos token, either through the MintKudos website or the API. Now as a community admin, you want to be able to programmatically distribute the same token to many end-users (this is doable because each Kudos token is an ERC-1155 token that can have many owners). This can make sense in a variety of scenarios, such as a Kudos token to signify completion of an education course.
This example can actually be achieved in two different ways - one where you're able to obtain explicit consent from the recipient in the form a signature, and another where you're unable to obtain this consent.
You would call the
[Async] POST /tokens/:tokenId/communityAdminAirdrop endpoint. This requires two sets of signatures - one from the admin and another from the recipient.For the admin consent signature, since each signature is generated per
tokenId, you could generate this signature outside of the app and then store it as an environment variable or in some kind of secrets store.For the recipient consent signature, this signature must be generated by the user on the browser, so you need to include logic in your webapp to trigger the user's wallet to sign. There are many good libraries to do this, but we recommend something like the Wagmi library or the Ethers.js library.
Bankless Academy, a web3 education platform run by the BanklessDAO, has created one token per course to commemorate the user's completion of the particular course. This means that each token will have many owners, as many students go through each course.
As an example, this is one of the tokens that they've created via the MintKudos UI. In their webapp, they call out to our
[Async] POST /tokens/:tokenId/communityAdminAirdrop endpoint (reference code) so they can airdrop the token to the user once the user has completed the course quiz. Note that they obtain the receiver consent in their webapp before the airdrop endpoint is called (reference code). Everything about this path is the same as Path #1, but you don't need to retrieve explicit recipient consent in the form of a signature. You may choose to go down this path if you find that obtaining explicit recipient consent is too disruptive to the user flow of your webapp, especially if you don't expect the recipient to ever connect their wallet or take action with it.
Please note that if you go down this path, you should be obtaining some kind of consent from the recipient within your app that you will be giving them a soulbound token which is non-transferable and bound to their wallet. They still always have the option to burn the token, but we feel that it's good practice to ask for consent anyway - in this case, it just happens that the consent is happening off-chain in your webapp.
Alchemy University, a web3 education platform run by Alchemy, has created an early access membership token for early participants of their platform.
Once you are onboarded onto their platform as an early access member, they take the user through a flow where the user finally inputs their ETH address to claim their early access Kudos token. The action to input the ETH address is considered active user consent in their flow.
In their webapp, they call out to our
[Async] POST /tokens/:tokenId/communityAdminAirdropWithoutConsentSig endpoint so they can airdrop the token to the user without cryptographic user consent (in the form of a signature).