Update delegate

[joefitter]

There is currently no way with Nifty to create assets under a program-owned (or delegated) group, such as a candy machine or conversion app, without the program retaining authority after mint/conversion.

Not sure if this is a feature request or a bug, but this functionality is available in token metadata, and Metaplex Core (in the form of an update delegate)

The authority of the group must match the authority of the new asset, and it's not ideal to set the authority of everything to the program - else you'd need to update all assets post mint/conversion

I had assumed the handover instruction would achieve this, but as the new authority also needs to be a signer, this isn't possible at the time of minting/converting, as this is performed by the user, not the authority.

One solution would be to remove the signer constraint for the new authority on the handover function, this way the mint/convert could end with a handover to the project authority.

An arguably better solution would be to have an update delegate, so the program is able to mint assets into a group, but without having full authority over the group, so the project authority would still be able to make changes to things like royalties and metadata whilst the conversion is still live. A conversion would likely be ongoing as the likelihood of all holders converting are slim-to-none.

[joefitter]

It seems like the functionality is covered to a certain extent with "Managed" assets, however it looks like there is no way to update the status to a regular non-fungible after the asset is created

[febo]

Hi @joefitter, thanks for the detailed description. The rationale to include both authorities as a signer on the handover instruction is to prevent setting the authority to a wrong pubkey (e.g., a pubkey that you don't "control") – if that is done, then you "lost" the asset.

The plan was to have a program that manages switching authorities in a "safe" way by having it as a 2-step process: the current authority delegates it to a program, then the new authority can claim it later. Both authorities need to be signers, but you don't need both on the same instruction. The program is ready here (pending writing some tests): https://github.com/nifty-oss/handshake

But even that only partially solves the use-case that you presented. A program could initiate the handover of the authority after setting an asset to a group using the Handshake program, but the "new" authority would need to accept the change of authority before becoming the authority. So there is an extra step there and 2 more accounts needed to use the Handshake program.

The delegate is probably a simpler and more direct solution to it.

[joefitter]

I agree with the rationale, and this functionality can even be handled in a UI with an async wait while the user switches wallets. I do something similar in another app with delegating freeze auth to another wallet for a kind of 2fa locking.

I think the 2 places that would make the most sense for the delegate would either be a new "group" delegate role on the asset, although this would only apply to assets with a grouping extension, so perhaps wouldn't make sense to include in the ALL_ROLES_MASK; or an optional delegate pubkey field on the grouping extension.

Let me know if you have any other thoughts, I'll put together a PR

[joefitter]

WIP PR that addresses this issue here #52

I'm struggling to get the interface client to generate as the IDL generation fails

[febo]

WIP PR that addresses this issue here #52

I'm struggling to get the interface client to generate as the IDL generation fails

Yeah, that is a bit clunky at the moment. I can do it once we get the changes to the program done. The PR looks very good, left a few minor comments.

[febo]

PR merged - thank you!