I’m working on a Solidity smart contract for an NFT project and need some help with a specific feature. Right now most NFT contracts mint tokens sequentially from 1 to the total supply. But I want to create a system where certain wallet addresses can reserve and mint specific token IDs.
For example, I’d like to have a mapping like this:
mapping(address => uint256) public reservedTokens;
// Example: wallet 0x1234...5678 is reserved for token ID 15
The idea is that when someone calls the mint function, they can only mint their reserved token number. So if address 0x1234...5678 is assigned token ID 15, they can only mint that specific token and nothing else. They should be able to mint it at any time though.
Is this approach feasible? Can I modify a standard mint function to accept parameters that determine which exact token gets minted? What would be the best way to implement this reservation system?
for sure! u can tweak the mint function to check if msg.sender is the one with the reserved token. jst put a require statement to block others. it’s a cool idea for your nft project!
That’s a cool concept! How are you handling the initial reservations though? Setting them all at deployment or adding an admin function to assign tokens later?
What happens if someone never claims their reserved token? Any fallback or expiration? You could end up with permanently locked IDs if people lose wallet access or forget.
Implementation seems doable, but I’m thinking about gas costs. Checking reservations on every mint could get expensive. Maybe consider merkle proofs instead? Way more efficient for bigger collections.
What’s your collection size? The approach changes a lot depending on whether it’s a small exclusive drop or thousands of tokens.
This reservation system works great - I’ve built something similar. You’ll need to modify your mint function to check the mapping first instead of auto-incrementing IDs. Add require(reservedTokens[msg.sender] > 0, "No token reserved") then mint that specific ID. Watch out for the initial setup though. You need a way to populate that mapping - either through constructor parameters or an admin function with proper access controls. I found it cleaner to have a separate reservation phase before opening public minting. Also think about unreserved tokens. You might want a separate mapping to track which IDs are available for public minting vs reserved ones. Otherwise you’ll get conflicts when someone tries to publicly mint an ID that’s reserved but unclaimed.