Update authority incorrect for NFTs minted through gumdrop

[MarkSackerberg]

Describe the bug If minting an NFT from candy machine with gumdrop the update authority is not correct. It is set to the gumdrop PDA instead of the normal candy machine update authority (the creating wallet)

To Reproduce Steps to reproduce the behavior:

1. Create gumdrop with candy machine
2. Mint one token through gumdrop
3. Look at the "UpdateAuthority". It is the Gumdrop PDA, since it is the authority of the candy machine.

Expected behavior The wallet that creates the gumdrop should be the update authority of Mints created through gumdrop

Screenshots Token with correct update authority (minted before gumdrop creation) https://solscan.io/token/B85BVqVRubWgWjX9uV2iHKGPVzCFb6b93EmEKFrZeEsh?cluster=devnet

Token with incorrect update authority (minted through gumdrop) https://solscan.io/token/CToHHqHcWXGeFe7KMWyKuAtfWrbwuGurp17PHL8ufjRq?cluster=devnet

Additional context One possible solution could be to transfer the updateAuthority to the correct wallet when minting similar to

[MarkSackerberg]

Just seen that this is a duplicate to #1116 But with a bit more information therefore keeping this open

[jclmnop]

Is it still the case after you close the gumdrop?

[Ben-DG]

Is it still the case after you close the gumdrop?

Yes

[MarkSackerberg]

Is it still the case after you close the gumdrop?

as @Ben-DG already wrote: Yes. You can see it in my example here. Gumdrop has been closed, but the update authority of the NFT minted through Gumdrop is still wrong: https://solscan.io/token/CToHHqHcWXGeFe7KMWyKuAtfWrbwuGurp17PHL8ufjRq?cluster=devnet

[jaune]

Same here. Any workaround?

[marcelc63]

I can confirm this behavior.

Adding to this:

1. When Gumdrop is active, all NFT minted will have gumdrop PDA as its Update Authority. This applies to both minted through gumdrop and those via candy machine.
2. After closing Gumdrop, new NFTs minted via candy machine will have their original Update Authority again.

Therefore, all NFTs minted when gumdrop is active will have different Update Authority.

[akserikawa]

So, to understand the issue at hand, this would only be problematic if you ever wanted to update those NFTs minted through Gumdrop, right?

[jclmnop]

So, to understand the issue at hand, this would only be problematic if you ever wanted to update those NFTs minted through Gumdrop, right?

Correct.

[lwus]

@MarkSackerberg Fixed in https://github.com/lwus/metaplex/commit/8f5fae50b090c7dccd8871194ccd55217d8204cd and deployed to devnet. recover_update_authority was added to the CLI for old gumdrops. I did a couple smoke tests but will let it sit for a couple days otherwise.

My recommendation for CM gumdrops in the future though will be to utilize CMv2's whitelist token where the workflow becomes:

1. Create a CMv2 with whitelist token W (which allows presale mints)
2. Create a gumdrop for distribution to community members for some amount of token W
3. Recipients can go mint with W

In this case the retain_update_authority in the CM config should work as designed (without interference from gumdrop becoming the CM authority)

[MarkSackerberg]

Thank you! Let me check and test it, but it looks good on first view!

[MarkSackerberg]

@lwus tested it in devnet as far as possible. It's now possible to recover the authority by using the base. Awesome!

Don't have access to old gumdrops in devnet though, so could not try to use recover_update_authority.

Regarding CMv2: I think this approach is too complicated for the users since it includes two steps. Even with a completely reworked UI where the candy mint would be triggered directly after the gumdrop it would be confusing for the user that two TX have to be approved. I really really hope that you will be able to allow us gumdrop with direct CMv2 🙏

Thank you for your awesome work and sorry for the delay.

[lwus]

Thanks for verifying! I tested a couple recover_update_authority's before IIRC. This has been deployed to mainnet now.

For CMv2: I think that we could probably just have the UI do a signAllTransactions for the gumdrop claim transaction + CM mint transaction. Integrating directly is a bit more difficult given all the additional features that CMv2 has. In addition, decoupling is especially useful here since the list of directly interoperable programs is hardcoded in v2 right now. (https://github.com/metaplex-foundation/metaplex/blob/master/rust/nft-candy-machine-v2/src/lib.rs#L375)

[znazgo]

Hey using the 'gumdrop/cm-tokens' branch to try and retain the update authority after using gumdrop to run a pre-sale.

Forked the repo and am running the correct branch on my system.

It recognizes retain_update_authority However when I run it I get this error

const recoverIx = await anchorProgram.instruction.recoverUpdateAuthority( ^ TypeError: anchorProgram.instruction.recoverUpdateAuthority is not a function

line 441 of gumpdrop-cli.ts on the most recent commit of the gumdrop/cm-tokens branch

[znazgo]

Hey just reaching out again. Any advice for the issue I was having above?

[lwus]

I upgraded the anchor IDL a few days ago (I think I saw your question on Discord). Have you tried recently?

[znazgo]

Tried a good amount today. Seems I am getting closer, however now I cannot get passed a Timeout Error.

Timeout Error caught { InstructionError: [ 0, { Custom: 167 } ] } Error: Transaction failed: Custom program error: 0xa7

I think I'm using the right wallet, either way I tried all of the wallets on my computer to be sure - same error on all of them.

[levicook]

Timeout Error caught { InstructionError: [ 0, { Custom: 167 } ] }

Running into the same error myself and investigating. My current theory is that it's happening because I've:

• closed the gumdrop already
• withdrew the candy machine config too

but tbd.

[levicook]

Leaving this as an FYI to future readers: Code 167 is AccountNotProgramOwned -- The given account is not owned by the executing program. I suspect, but haven't confirmed, that the gumdrop program is looking for accounts that no longer exist in my scenario.

[danconger]

@levicook if I'm running into the same error, does that mean S.O.L. (shit outta luck, no pun intended) in terms of being able to change the update authority for all those NFTs minted through the gumdrop?

[github-actions[bot]]

This Issue has received no activity for 30 days. We will close it in 2 days, please reopen if you are still experiencing this issue.