For anyone that went over the following tutorial or has a good understanding of "Lazy Minting" I am hoping you may be able to answer a few questions. This was the tutorial i am referring to...
I understand the overall idea behind "lazy minting" is that the artist/creator does not have to mint the token. Instead it can be held off chain and the user can mint it when he wants to purchase it. Great concept. But I just want to verify that the "Minter role" in the contract is still the artist/creator. He is authorizing with his signature in advance that his token be minted by the user right? So when the user calls the redeem function, the mintor/artists signature is already pre-loaded so to speak to allow the nft he created to be transferred to the user/buyer? Or do i have something mixed up here?
You are correct. The artist/create must set up and Externally Owned Account (EOA) to have the minter role. Then they must use the EOA to sign a hashed version of all data to be passed into the mint function (any parameters not included in the hash cannot be enforced by the smart contract).
The 'catch' with lazy minting is that the creator must have some mechanism to deliver the input parameters + the signature to the recipient so that they can submit the transaction to the blockchain. This often means you have to run some traditional Web 2 infrastructure, or get fancy with integrating decentralized storage into your dApp.
Thanks for the reply. Doesn't the smart contract handle the delivery the input parameters + the signature to the recipient when he calls the redeem function? And the rest of the smart contract should include some sort of mapping or array to hold the users nft token balances and make the transfers? As long as the Dapp connects via MetaMask or some other wallet than the "decentralized storage" you speak of can all of it can be coded into the smart contract?
Unfortunately, the smart contract on the blockchain cannot relay the signed transaction from the creator EOA to the recipient for you, since that would effectively require a change in the state of the blockchain and therefor be a costly transaction that you are trying to avoid.
Lazy minting (and Merkle dropping) is a two-step process that requires an off-chain component to deliver your un-minted assets (i.e. signatures + function inputs) to the recipients, then the recipients must submit the data to the blockchain themselves. Platforms like OpenSea enable this by running traditional backend webservers that deliver this info into the user's browser upon an API request from their webapp.
I see. Surprised the tutorial didn’t mention this caveat to the infrastructure (or maybe it did but I missed it), but either way thanks again for the clarification. This was very helpful!!
If anyone here stumbles upon this thread and has any links/articles to share explaining the specifics surrounding the backend and frontend infrastructure for platforms that use merkledrops and lazy minting (like Open Sea) please do share with this lazy guy.