Setting up a WL wallet based approach with Candy Machine V2 - solana

I have been using the spl-token whitelist based approach via the the CLI with Candy Machine V2 up to this point. Sending WL users a token that is registered as the WL token in the Candy Machine config. This route has been ok but I would like to switch to a wallet based approach where wallet addresses are detected automatically without the need to send out tokens. I have been looking online for some documentation / notes on how this can be done but haven't been able to find much (might just be looking for the wrong thing). Is this possible to set up with Candy Machine V2? If possible, does anyone know of some good resources I can check out that could help me get this done? I would need the ability to set up multiple whitelists.
Any help is appreciated!

You can do wallet based whitelisting with candy machine v2 together with gumdrop.
You would have to use claim-integration candy and distribution-method wallets. This will allow the given wallet to claim the wl token and since you are using claim integration candy will directly build the mint transaction, too. Therefore the user will only have to confirm one tx and would only see the wl token if the second transaction fails.
This is closest to what you can get to wallet based whitelisting with cm v2.
Keep in mind though that by default you have to give every user a personal claim link which contains a merkle proof that allows them to claim. Either use a discord bot where they can pull their claim link or modify the frontend to include the proofs and automatically fill it there.

Its not possible to set up a Wallet-based whitelist using the deployed CandyMachineV2 Program. The only way of having this feature is grabbing the CMv2 program and update it to allow Wallet Whitelist instead of SPL-Token whitelist, then deploy your new CMv2 and use that new program ID in ur mint page and ur CLI to create and update the CandyMachine

Related

How can I set the limit of NFTs that can be minted per wallet?

I need to update the limit of how many NFTs can be minted on 1 wallet
Using the current Candy Machine v2 Program you cant set (for public mint) a limit of NFTs per wallet.
How can this be solved? You can use whitelist Settings to make sure how many NFTs can be minted per wallet. Why? Because with whitelist settings any person who has the SPL token can mint while she/he hold the whitelist Token.
So to have a limit per wallet you have to set whitelist settings with "mode" : { "burnEveryTime": true } and to distribute the whitelist tokens you can use gumdrop
Other way (more complex) is grabbing the CandyMachinev2 rust program and adapt it to ensure a limit per wallet using an PDA per wallet. Then deploy ur new CMv2 program to solana network and use the new program id in ur CLI and mint page
You can directly use gumdrop for this.
Go through Metaplex docs for gumdrop. Gumdrop can be also used to mint NFTs and it has a feature distribution list of selected users and you can define amount of NFTs distributed per user.
It can be one for each or random for each user.
Gumdrop Docs
Whitelist Mint using gumdrop

SOLANA: How to display my candy machine NFT's on metaplex's storefront?

I minted 30 tokens with candy machine's cli, following the metaplex's github boilerplate project
Uploaded, verified, minted and signed all the NFT's. I can see them on my phantom wallet and it created a cache file on the main directory with the candy machine ID. Now I want to know is theirs a way to call my candy machine on the metaplex storefront so I can sell the minted nfts on there.
I think I did it once but now i can't replicate it. I might have been dreaming ...
Any good tutorials on trying to do what I want?
Thank you.
Soo it works again!!
I think i know why it wasn't working in the first place.
An account address can create many candy machines and when initializing Metaplex's storefront it tries to retrieve all those candy machine instances.
That's why it takes one attribute on the .env file , it gets all the CM's from that one address
After checking Metaplex discord and various forums it seems as Solana's network is the problem. in short the network is slow and unable to function at scale. As of now (March 30, 2022)
My solution is to only use one address per candy machine instance and maybe that'll help the load

Can't login account because lost code google authenticator [duplicate]

My mac brokedown.Thus, I can't use the touchID to verify myself anymore on heroku. Thus, the only other option is to use 1-time password generator which I don't even have it setup & you need to login (and verify) to be able to setup. What shall I do? How can I gain access to my heroku account?
Heroku recommends having a back-up in place:
We recommend registering another verification method to ensure that you can log in to Heroku on other devices where a built-in authenticator is not present.
and:
Recovery codes provide an important backup if your usual MFA verification method is not available. For example, if you normally use Salesforce Authenticator but forget your mobile phone one day, you can still log in using a recovery code. Generate a list of ten single-use recovery codes that you can keep in a safe place until you need them.
This is always a good idea when using MFA with any service.
If you do not have another authentication method registered and you don't have recovery codes, you'll have to ask for help. How you do that depends on whether you're a member of an enterprise account:
Registering multiple MFA verification methods is strongly recommended.
If you’re a member of a Heroku Enterprise Account and need help with recovering access when your MFA verification method isn’t available:
Your Enterprise Account admin can generate a temporary verification code that allows you to log in to your account (starting August 2021)
You can contact support for help.
If you're not a member of a Heroku Enterprise Account:
e-mail account-lockout#heroku.com for help.
We may request additional information to recover access to ensure that an attacker is not attempting to access your account.

What is the difference between minting NFT's on Solana and Ethereum?

I am a little confused about the workflow of NFT's on the Solana blockchain. I come from Ethereum and everything there is very clear. There is a smart contract that is executed on the blockchain which requires a specific amount of Ether to accept and you send the transaction out to the mempool to be picked up by a miner.
On Solana from what I've gathered is, the NFT creator creates a token using SPL that gives them an ID. Then someone else can create an account under one of their wallets to accept that specific type of token that was created. Then that person can use that account to mint the NFT using the ID we got earlier. Is that all correct?
If someone could please clear up the some of the things below it would be greatly appreciated.
Where does Candy Machine come into play here?
What's the difference between the Mint Authority and the Update Authority?
Does a collection need to run the spl create-token command for every single token?
The Candy Machine by Metaplex (https://github.com/metaplex-foundation/metaplex) is the standard smart contract (actually known as programs in Solana) being used at the moment for minting NFTs in the Solana ecosystem.
It abstracts away from all the details you have described so people can simply clone and deploy the repo more or less rather than write your own contracts as in Eth.
An NFT in Solana is an SPL token with a metadata struct set to the Metaplex standard (i.e. a URI on-chain pointing to more metadata off-chain). This is the current agreed-upon standard for NFTs on Solana.
You are also right in saying Solana SPL tokens require an account to be created to "receive" NFTs or mint them as well. A new account will be created for each NFT. This is handled by the Candy Machine as well as the SPL token program built into Solana itself, so normally you don't have to deal with this unless writing your own contracts possibly. Check Solana docs / Anchor framework docs for more info on programming on Solana.

How to programmatically access only one specific google drive without a service account

I am writing a server side python script with Pydrive which needs to store a file in a specific gdrive. Pydrive and this post suggest to use a service account.
However this would mean that with the credentials of this service account all gdrives are accessible and I would rather avoid that.
Ideal only one specific gdrive or all gdrives where one specific user has access to should be accessible.
Is it possible to give programmatically access to only one specific gdrive?
[Edit]
As mentioned in the comments I am apparently not looking for a OAuth flow.
I am looking for a server-to-server communication for accessing one specific google drive using the principle of least privilege access. Doing this with a service account + domain wide delegate and google drive r/w scope would mean that with this service account all google drives can be accessed which is not what I want.
Unfortunately there is a domain wide policy in place which forbids to share google drives to "other" domains. This means I can not use a service account without domain wide delegation and just share the drive with it.
I don't understand what you mean by "programmatically", when you already tag the question as oAuth - asking for oAuth2 flow, which is interactive. When there is nobody, who would press the buttons, this probably isn't the authentication flow you're looking for. Just share a directory with a service-account; no domain-wide delegation is required (with that enabled, there would be no need to share it).
One could even abstract the whole Drive API access credentials away by using a simple Cloud Function, which has to task to update one file; triggered through HTTP, utilizing the Drive API.
Possible approach - dummy account
You could designate a new account that will be your "service account". In reality it won't be an actual service account, it will just be a dummy account that you can call something like "gdrivebot#yourdomain.com". Then you can share only what is absolutely necessary with it. I think this would be the only way to get that level of fine-grained control that you are looking for. This would require your admin to designate a new account just for this purpose though.

Resources