How does ECDSA signature verification work in NFT whitelist implementation?

NFT
1

I’m trying to understand how ECDSA signature verification works for NFT whitelisting. I found this pattern in a smart contract but I’m confused about the implementation details.

function purchase(uint256[] memory _tokenIds, uint256 _expiry, bytes memory _sig) public payable isActive {
    uint256 currentSupply = totalSupply();
    require(_tokenIds.length <= 3, "Exceeds max per transaction");
    require(currentSupply + _tokenIds.length <= MAX_SUPPLY, "Exceeds total supply");
    require(msg.value >= cost(_tokenIds.length), "Insufficient payment");

    address buyer = _msgSender();
    
    address recoveredSigner = verifySignature(buyer, _tokenIds, _expiry, _sig);
    require(recoveredSigner == contractOwner(), "Invalid signature");
    
    require(block.timestamp <= _expiry + 60, "Signature expired");
    
    for(uint8 j = 0; j < _tokenIds.length; j++){
        require(ownerOf(_tokenIds[j]) == address(0) && _tokenIds[j] > 0 && _tokenIds[j] <= MAX_SUPPLY, "Token unavailable");
        _safeMint(buyer, _tokenIds[j]);
    }
}

function verifySignature(address buyer, uint256[] memory _tokenIds, uint256 _expiry, bytes memory _sig) public view returns (address){
    return ECDSA.recover(keccak256(abi.encode(buyer, _tokenIds, _expiry)), _sig);
}

I don’t get how this part works exactly:

address recoveredSigner = verifySignature(buyer, _tokenIds, _expiry, _sig);
require(recoveredSigner == contractOwner(), "Invalid signature");

Can someone explain the logic behind the ECDSA recover function and how it validates the whitelist access? Thanks for any help you can provide.

2

ECDSA verification is essentially a cryptographic proof that the owner authorized the minting of tokens. It works by having the contract owner take your address, the desired token IDs, and an expiry timestamp, then hash this data together using keccak256. They sign this hash with their private key off-chain. When a user attempts to make a purchase, the contract uses ECDSA.recover with the same data and the provided signature to determine the signer’s address. If this address matches the contract owner, the user is authorized for that specific transaction. This system is secure as the signature is tightly bound to the specific parameters - including the buyer’s address and the exact token IDs. Consequently, one cannot misuse another person’s signature because the address must align, and altering token IDs would invalidate the signature, ensuring a controlled and tamper-proof minting process.

3

The Problem:

You’re experiencing issues with your Solana NFT Candy Machine after deploying to mainnet. Specifically, you’ve uploaded 1000 NFTs, but only 985 are displayed, 15 NFTs appear missing. Furthermore, minting consumes 3 NFTs instead of 1, and minted NFTs aren’t appearing in users’ Phantom wallets. These problems didn’t occur during devnet testing.

:thinking: Understanding the “Why” (The Root Cause):

The core problem likely lies in a misunderstanding of how the Candy Machine contract handles minting and data updates on the Solana mainnet, particularly concerning the discrepancy between the displayed NFT count and the actual minted NFTs. The behavior you’re witnessing (missing NFTs and triple minting) points towards potential issues with the Candy Machine’s state management and interaction with the Solana blockchain’s data storage and retrieval mechanisms. It’s crucial to remember that devnet and mainnet have different configurations and load levels, impacting transaction confirmation times and state updates.

The discrepancy of 15 missing NFTs suggests an issue either during the upload process itself (potentially a failure in confirming all uploads) or an error in how the Candy Machine’s internal state is tracking the available NFTs. The triple minting problem likely stems from a bug within the Candy Machine’s logic that inadvertently decrements the available NFT count by three for each successful mint. The lack of NFTs showing in Phantom wallets suggests that even though the transaction might confirm, the metadata or the actual NFT association with the user’s wallet isn’t being correctly updated on-chain.

:gear: Step-by-Step Guide:

  1. Thoroughly Review Your Candy Machine Code: Carefully examine the code of your Candy Machine contract. Focus on the functions responsible for:

    • NFT Upload: How are NFTs uploaded and their metadata stored? Are there any error-handling mechanisms to account for failed uploads? Verify that all 1000 NFTs are correctly referenced and their metadata is properly associated.
    • Minting Logic: Analyze the exact flow of minting operations. Identify exactly how the available NFT count is decremented. Look for unintended loops or multiplications in the code. Use a debugger to step through each step of a mint transaction.
    • Metadata Updates: After a successful mint, ensure your Candy Machine properly updates the NFT metadata (including the association with the user’s wallet address) on the blockchain. Confirm your contract correctly emits events indicating successful minting and associated metadata.

  2. Inspect the On-Chain State: Utilize Solana blockchain explorers (e.g., Solana Beach, Solscan) to verify the on-chain state of your Candy Machine. Check the following:

    • Available NFT Count: Examine the Candy Machine’s state variable that tracks the number of available NFTs. Does it accurately reflect the number of NFTs you expect to be available?
    • Transaction Logs: Review the logs of recent transactions associated with your Candy Machine. Scrutinize the events emitted, carefully looking for any anomalies or errors.
    • NFT Metadata: Analyze the metadata associated with minted NFTs. Ensure all minted NFTs have their metadata correctly populated and properly linked to the minting transactions.

  3. Verify Your Deployment Process: Ensure that your mainnet deployment was done correctly. Double-check that you’re using the correct program ID and that the Candy Machine was successfully deployed to the right cluster (mainnet-beta). Confirm that the necessary funds are allocated for transactions.

  4. Test on a Testnet: Before redeploying to mainnet, thoroughly test your Candy Machine on a testnet (like devnet) with a smaller number of NFTs. Simulate multiple minting transactions and inspect the behavior carefully.

:mag: Common Pitfalls & What to Check Next:

  • Incorrect Metadata: Review your NFT metadata file to verify accuracy and consistent formatting for all 1000 NFTs. Any inconsistencies could lead to display issues.
  • Transaction Errors: Thoroughly review any transaction errors reported during the upload or minting process. These messages often contain valuable hints about the root cause.
  • Insufficient Funds: Make sure that your Candy Machine has enough SOL for gas costs associated with multiple minting transactions.
  • Smart Contract Bugs: If you’re still facing challenges, consider employing a smart contract auditor to examine your code in-depth for any potential security vulnerabilities or bugs.

:speech_balloon: Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!

4

Oh interesting question! I’ve been working with similar patterns lately and had the same confusion at first.

Basically, the contract owner pre-signs a “permission slip” for specific users to mint specific tokens. Think of it like this - the owner takes your wallet address, the exact token IDs you want, and an expiry time, hashes them together with keccak256, and signs that hash with their private key.

When you call the purchase function, the contract reverses it - takes the same data (your address, token ids, expiry) and uses ECDSA.recover to figure out who signed it. If that address matches the contract owner, you’re whitelisted for those exact tokens.

What I’m curious about though - how does the off-chain signing work in practice? Does the project owner batch-sign these ahead of time, or generate them on-demand when people qualify for whitelist? And what stops someone from copying another person’s signature and changing the buyer address?

Actually wait, I think I answered my own question - the buyer address is baked into the hash so you can’t just swap it out. Pretty clever system really!