Adding member via NFT

[c4sp3r-sol]

In the Metaplex Docs, its notes that the NFT method is another way to add members to the wallet, is this currently wokring/being worked on?

"With this model membership is tied to an NFT mint address instead of static public address. Each NFT mint address can still have a different quantity of shares as in the Wallet model. The greatest benefit of this model is it effectively enables the simple transfer of rights to future distributions to any wallet owner that holds the given NFT."

[Swertin]

Looks like the code for this is pretty similar to the current method, just implementing a few inputs for selecting and using the selected membership model here, and adding a check for the distribution method/ix.

const nftMintPublicKey = "nftMintPublicKey";

const init = await fanoutSdk.initializeFanout({
    totalShares: 100,
    name: `Test${Date.now()}`,
    membershipModel: MembershipModel.NFT,
});

const {membershipAccount} = await fanoutSdk.addMemberNft({
    fanout: init.fanout,
    fanoutNativeAccount: init.nativeAccount,
    membershipKey: nftMintPublicKey,
    shares: 10
});

// Add members until sum of shares = totalShares
...

One challenge is that the assumption would be you're intending to setup a fanout for an entire nft collection, being potentially 10,000 nfts (ignoring compression support). So with the current operational model of this UI, it would need to get upgraded to split the initialization flow and adding members flow, because we definitely can't fit it all into 1 transaction.

Honestly, I feel like the best solution would be to split the initialization from adding members on create.tsx and moving member configuration to the initialized fanout page. Knowing total shares is necessary at the initialization step, so that's unchanged. The only place that a wallet cares if all members have been added (sum of member shares = total shares) is when a distribution event is attempted.

This way, we can batch adding members with simpler logic than having to account for the initialize fanout ix, which solves issue #4. It also provides for a better UX when it comes to membership management, being that they could add or remove members in a place that they've already done it before (after initializing and redirecting to their initialized page).

This should also have some way to import csv or a csv formatted membership list (or json, but json is more finnicky when creating for non-developers), and some display for "total shares | sum of current membership shares" in order to help the user understand if they're missing some members if distributions fail.

Overall, the larger challenge I see will definitely be token based, which should also be considered as a feature addition but probably on a separate issue.

I do see there being some potentially wasted time for handling bulk nft adds (1000+) if collection mints are ever supported for hydra, but I do think this supporting work would improve UX for wallet adds as well and should be worthwhile to implement.

Open to any other suggestions for how to implement before getting to work.

[jpbogle]

Agreed with @Swertin that the main use-case is probably NFT collections which is a large number of transactions

this is an example of handling large number (thousands) of transactions in a UI, and as @Swertin mentioned one way to do it would allows the user to pass in a csv of members for example
https://github.com/cardinal-labs/cardinal-staking-ui/blob/main/components/admin/TransactionExecutor.tsx

That then begs the question, where is the user going to get their CSV of members if they are not a dev. We have an index of all NFTs but doing that in the UI also would introduce a dependency on off-chain infra which we do not currently want.

Curious @c4sp3r-sol if you have a main use-case you had in mind for token based membership

[gchatz22]

Agreed with @jpbogle on the TransactionExecutor example he linked above. We've had dealt with similar issues in our UIs where for example stake pool owners want to set different stake multipliers for each mint in the collection through the admin UI portal.

[c4sp3r-sol]

@jpbogle the main use case I had in mind was the ability to track holders based on NFT ID so distribution of coins could be streamlined to holders without updating any wallet parameters.

Given the constraints on transaction limit, I see how this could cause issue with collection sizes being too large. In the past I have manually performed fanouts through coin98 wallet where I would build out a CSV to copy and past as distribution which is tedious to perform.

I have not looked far into the repo and do not know the specific constraints, but find that importing a CSV containing all nft address and shares would work for the initialization of the wallet; with each NFT holding the same share value.

[Swertin]

Imo, the most common use case is as @c4sp3r-sol mentions, which is equal shares where one nft equals one share out of total nft collection size shares (along with token allocation distribution for ICO/IDO/investors). That being said, by importing as a CSV, the user isn't limited in that they can assign more shares to specific mint addresses if they want to. Batch data entry on excel is a much lower barrier to entry than any other current solutions, and it would be very simple to get a collection hashlist from Metaboss or other external tools, paste into excel, and paste a 1 in each row next to the corresponding mint address.

Obviously it would be great to build a one stop shop for users to go from collection address to functioning fanout. That being said, that gets built by starting with just the functionality to either import an externally created CSV (which would also work for wallet membership models) after the fanout is initialized or go row by row through modifying and extending the current interface