ChaosMinter (mint 3, pick 1, burn 2)

[mchrupcala]

Now that we're publishing the minter suite, we can create a minter option that creates 2x or 3x tokens. In Solidity our minter would mint as many times as the artist sets a mintOptions param. The new TokenIDs would be temporarily stored within the minter, and the signer would then call selectAndBurn() to store one token in their wallet & minterFilter while sending the remaining tokenIDs to a burn address.

Eventually we could build a "graveyard" where a user could select a given project & view all the burnt tokens rendered in their full glory.

Issues: render delays - how do we handle a scenario where the user's waiting to see their mint options & make a selection? What if the minter closes the window before making a selection? Do we avoid sending any of temporary tokenIDs to minterfilter/core contract until the minter selects & burns?

[jakerockland]

I really like this idea a lot, so spent some time doing very initial/non-functional prototyping out what exactly this may look like and have some updated thoughts on how I think we would want to approach this MinterChaosV0 when we have the time to explore this more deeply.

There is no urgency on making progress against this minter, but its something I'm very excited about so I wanted to do some exploring and document more thoughts here for when this eventually is something we want to incorporate into the mintersuite @ryley-o.

My current thinking is summarized in bullet format here:

• For V0 make this a hard-coded "mint 3 pick 1" minter, to simplify (rather than adding complexity of making the minter itself configurable to an arbitrary "N pick M" type setup–we can revisit that in a later V1 if there is artist-demand to justify it.
• We will need to make purchase and purchaseTo obsoleted in this minter, in favor of minting methods that return a struct of a set of 3 "claimable" tokenIDs (rather than a single tokenID as returned by purchase/purchaseTo–let's tentatively call these chaosPurchase and chaosPurchaseTo for now.
• When a token is minted via chaosPurchaseTo (assuming chaosPurchase itself also calls this method), we will mint 3 tokens for the given destination address, but instead of minting them into the destination address we will mint them into the minter contract itself (e.g. using address(this)), and update two mapping records on the minter to store a) which tokens are in a bundle together and b) which addresses control which token-bundles (snippets below that attempt to clarify this a bit more).
• To improve UX of being able to support the claiming process, we should also use event-emission to index the claiming address (destination address in other minters) and its associated bundle index (note that the bundle index probably can just be the first token from the set of 3, but could also be some other derived value).
• There will be a claimToken that takes in a bundleID and the token from the bundle that is desired to be claimed–of the tokens in the bundle, the one that is "claimed" will be sent to the recorded "claimable wallet"/"destination wallet" and the other two will be sent to address(0).
• There is no need to modify any of the price calculation details, artists should price their projects as if they were at an edition size of 1/3 of the actual edition size, given that only 1/3 of mints will be claimable and the other 2/3 will be locked in the minter or burned.

    /// Details of a claimable/selectable set of mints.
    event Record3Pick1Set(
        address indexed claimingAddress,
        uint256 _tokenSetIndex, /// note, if documented explicitly as such, `_tokenId1` could be used as the "set index"
        uint256 _tokenId1,
        uint256 _tokenId2,
        uint256 _tokenId3
    );

   /// Mapping that maps a given destination address to an enumerable set of "set IDs", 
   /// groupings of 3 tokens that serve as a 3-pick-1 bundle.
   mapping(address => EnumerableSet.UintSet) private projectIdTo3Pick1SetIds;

   /// Mapping that maps a given "set ID" to the group of 3 tokens that serve as a 3-pick-1 bundle.
   mapping(uint256 => EnumerableSet.UintSet) private setIdTo3Pick1TokenIds; 

Also, just to answer here in a documented way for posterity the questions @mchrupcala asked above:

render delays - how do we handle a scenario where the user's waiting to see their mint options & make a selection? This should be a non-issue, in that it shouldn't be any different than how things currently work with Art Blocks and the variance in render delays between projects, as there is no need for there to be a defined claim window (users should be able to perform the claim-and-burn process at any time).

What if the minter closes the window before making a selection? This is a non-issue with the approach described above, as we record in the contract the 3 tokens that they have the ability to pick between, after these tokens have already been created, so nothing in the process requires client side logic being preserved in any way.

Do we avoid sending any of temporary tokenIDs to minterfilter/core contract until the minter selects & burns? Similar to answer above, this is a non-issue with the mint-into-the-minter approach, as there will be no temporary token IDs, just the actual token IDs (knowing that only 1/3 will ever be transferable and the other 2/3 will be indefinitely locked/burned).

cc @ArtBlocks/eng and @snowfro for broader visibility on the above, in case this is interesting to folks. I know this was a conversation during the offsite in Santa Fe, so wanted to share broader vis. for the thinking around how this would be possible with our current mintersuite architecture–not requiring any custom core-contract logic nor custom burning/claiming contracts (outside of the minter implementation itself)

[ryley-o]

a cool minter concept. a few thoughts based on @jakerockland comments above:

• minting 3 tokens will be gas $$$, so maybe a difficult fit for most projects... until we reach L2 😄
• I personally love the idea of minting the purchaser an NFT that acted as the "claim" token instead of relying on address, essentially giving the minter of an unclaimed set of 3 tokens have the ability to sell the option on secondary. someone else could then redeem.
  • note that even if we did not do this, people could essentially create this on their own via minting from a custom contract with simple "owner" logic, which could even be represented by an NFT.
• I expect some sets of three tokens to never be redeemed (e.g. cool set of three that go together). I think this would potentially get confusing on marketplaces (defining total supply, etc.). We could strong-hand this and require claiming before some point in time if we don't like that end state.

[mchrupcala]

• I expect some sets of three tokens to never be redeemed (e.g. cool set of three that go together). I think this would potentially get confusing on marketplaces (defining total supply, etc.). We could strong-hand this and require claiming before some point in time if we don't like that end state.

Hmm that's a really interesting snag that I didn't consider, especially with a minter's ability to add their "claim NFT" or custom contract to the secondary. If we offered this for a high-profile drop, what's stopping the community from deciding they prefer the 3-piece-set option over a single token? I'd imagine the OS thumbnail might break or favor one token over the others...but maybe a "claim window" is our only option for avoiding that.

[Jbern16]

Interesting! I'll defer to all ya'll about the contract complexity -- One call out I would make is its effect on the renderer, as we will be minting 3x amount of tokens. Also, would opensea index the "burnt ones?" Could we do something more interesting than burning? Could those all be sent to a NFTX pool? Honestly, this could make a lot of sense for a pfp-like drop (fb?)

[lyaunzbe]

Re: renderer, I would think it may make sense to only actually render (statically) tokens that have been claimed. Users would still be able to visualize the unclaimed tokens via the live view/generator to make their decision. I have some additional thoughts re claiming, but will try to drop them here later!

[jakerockland]

Re: renderer, I would think it may make sense to only actually render (statically) tokens that have been claimed. Users would still be able to visualize the unclaimed tokens via the live view/generator to make their decision.

Yeah great point, that definitely makes sense to me.

[jakerockland]

* minting 3 tokens will be gas $$$, so maybe a difficult fit for most projects... until we reach L2 😄

This is a great point. Hard to avoid without L2 || a new corecontract. That being said, still probably worth it for some projects designed for this experience and intended to include the minting mechanism more directly into the performance there.

* I personally love the idea of minting the purchaser an NFT that acted as the "claim" token instead of relying on address, essentially giving the minter of an unclaimed set of 3 tokens have the ability to sell the option on secondary. someone else could then redeem.

  * note that even if we did not do this, people could essentially create this on their own via minting from a custom contract with simple "owner" logic, which could even be represented by an NFT.

This is a very fun idea–I quite like this a lot. I would think we would want to handicap this "option" though in a sense, to make it experimentally feel like a claim option and not a pre-defined triptych (e.g. it shouldn't have art that is the set of 3 IMHO).

* I expect some sets of three tokens to never be redeemed (e.g. cool set of three that go together). I think this would potentially get confusing on marketplaces (defining total supply, etc.). We could strong-hand this and require claiming before some point in time if we don't like that end state.

To my comment on the above point, I do think we should strong-hand this in some way... something to think more on.

[jakerockland]

Hmm that's a really interesting snag that I didn't consider, especially with a minter's ability to add their "claim NFT" or custom contract to the secondary. If we offered this for a high-profile drop, what's stopping the community from deciding they prefer the 3-piece-set option over a single token? I'd imagine the OS thumbnail might break or favor one token over the others...but maybe a "claim window" is our only option for avoiding that.

Yeah this is definitely an important design consideration (e.g. is there any art for the set of the 3–I would say no for this reason; also the point on having a claim window makes more sense in this context.. definitely need to noodle on that more, but I do think that would be a good forcing function for having users actually perform the claim).

[jakerockland]

Also, would opensea index the "burnt ones?" Could we do something more interesting than burning? Could those all be sent to a NFTX pool? Honestly, this could make a lot of sense for a pfp-like drop (fb?)

IIUC how OS handles these things, they still show up as tokens, but just are owned by the burn address.

The NFTX pool is an interesting idea, but I think should be a different minter altogether if we ever went that route (a minter that mints directly into NFTX and gives you a token is an interesting thought experiment for more noodling on...), as that would change the dynamic very much from the dynamic of them being burned.

Or, to put it differently, I don't think the question here is a trade-off between burn or other non-burn dynamics, they're just multiple options that are interesting for different reasons.

[mchrupcala]

Or, to put it differently, I don't think the question here is a trade-off between burn or other non-burn dynamics, they're just multiple options that are interesting for different reasons.

Great points all around, and I think it's all worth exploring! I'd be really interested to see what Creative thinks about burning the tokens. Tbh, the burning mechanism was almost a thought-experiment for me...what does the art mean if it's selected from a group of machine-generated, destroyed artworks? Maybe the minting mechanic is almost a part of the experience of artist & minter creating a piece together.

[lyaunzbe]

@Jbern16 @jakerockland whoa, definitely a separate minter, but the concept of claiming 1 nft and then recieving 2 nftx ERC20 tokens as well, for the tokens discarded, is supeeeer interesting/fun

[jakerockland]

Oh yeah 1000%. Personally I don't think we would want to build this out until there was demand from the artist-side for this type of minting mechanic being something that would unlock certain types of projects designed for this experience.

This type of minter IMHO is something that becomes part of the art project itself (a performance art aspect to the work) so would be something that should be artist-driven in that respect.

cc @sarahrossien @madpinney @jeffgdavis for additional vis on the group brainstorming here.