Frequently Asked Questions
What token standard should we use for our NFT collection?
ERC-721 for unique one-of-one or 1/1-per-item collections where provenance clarity matters most (PFPs, art, credentials). ERC-1155 for semi-fungible items where multiple copies of the same token exist (game items, editions, tickets). ERC-6551 (Token Bound Accounts) when the NFT needs to own other assets — useful for game characters, identity-based tokens or composable NFT systems. The standard cannot be changed post-deployment without a new contract and lost provenance history.
How do we ensure metadata is truly permanent?
Three requirements: store metadata on IPFS or Arweave (not centralised servers), pin the content with a reliable pinning service (nft.storage, Pinata, or Arweave for permanent storage), and lock the IPFS CID into the smart contract so the tokenURI cannot be changed after reveal. On-chain fallback URIs pointing to an IPFS gateway provide redundancy. Arweave provides the strongest permanence guarantee — pay once, stored permanently by the Arweave network. IPFS requires ongoing pinning.
How do we enforce royalties on secondary sales?
EIP-2981 makes royalty information available on-chain, but enforcement is at the marketplace's discretion — most permissionless DEXs do not enforce it. Transfer hook-based enforcement intercepts every transfer and collects royalties regardless of which marketplace processes the trade. The trade-off: transfer hooks restrict trading to marketplaces that support them, limiting secondary market liquidity. Most new collections targeting creator sustainability choose enforced royalties with a curated marketplace over advisory royalties on any exchange.
What is lazy minting and when should we use it?
Lazy minting allows tokens to exist as signed off-chain vouchers until the first purchase — the token is minted to the buyer at the moment of sale, not at collection creation. Benefits: creators avoid upfront gas costs for unminted supply, failed collections don't waste gas, and minting scales to demand. Requirements: signature verification infrastructure, voucher management (tracking which vouchers have been redeemed) and careful nonce management to prevent double-spend. Use lazy minting when the collection is large and you cannot guarantee sell-through.
How do we implement a fair auction mechanism?
Auction fairness requires: minimum bid increment to prevent one-wei overbidding games, auction extension on last-minute bids (extending the auction by N minutes when a bid arrives in the final window prevents sniping), reserve price enforcement so the auction only settles above the minimum, and atomic settlement so winning bid payment and NFT transfer happen in the same transaction. English auctions (ascending price) are most common. Dutch auctions (descending price) work well for price discovery on new collections.
How do we build a reveal mechanic for a generative collection?
A standard reveal mechanic: mint all tokens with placeholder metadata pointing to a loading image, use a Chainlink VRF random seed committed at mint-close to generate the trait distribution, generate all metadata files with the VRF-seeded trait assignments, upload to IPFS, and set the baseURI in the contract to the IPFS directory CID. The VRF commitment proves the trait distribution was not manipulated after seeing which wallets minted. This prevents pre-reveal metadata sniping and provably fair trait distribution.
What is ERC-6551 and when is it useful?
ERC-6551 (Token Bound Accounts) allows any ERC-721 token to have its own Ethereum account — the NFT can hold ETH, ERC-20 tokens, other NFTs and execute transactions. Useful for: game characters that carry their own inventory, identity-based NFTs that accumulate credentials and assets, composable NFT systems where items equip to characters. ERC-6551 is a relatively new standard with growing but not universal marketplace and tooling support. Use it when the composability or ownership model genuinely requires on-chain accounts.
How do we handle gas costs for large collections?
Gas optimisation for large collections: use ERC-1155 for fungible editions instead of ERC-721. Use lazy minting to defer gas to buyers. Use ERC-721A (Azuki's optimisation) for sequential minting which packs multiple mint operations into fewer storage writes. Use batch operations for allowlist management. Deploy on L2 (Base, Arbitrum, Polygon) where minting costs $0.01-0.10 vs $5-50 on L1. If collection size is over 10,000 and gas is a concern, L2 deployment is the right architectural choice.
Do we need a smart contract audit for an NFT collection?
Yes — for any collection expecting significant trading volume or holding real economic value. A marketplace contract handling ETH is an immediate audit target. Even ERC-721 contracts with custom minting logic, allowlist mechanics or royalty hooks contain logic that should be reviewed. Internal review (Slither, Foundry fuzz testing) should precede a third-party audit. Code4rena and Sherlock offer competitive audit models for smaller collections. Trail of Bits, OpenZeppelin and Spearbit provide comprehensive audits for high-value systems.
How long does an NFT marketplace take to build?
A collection with smart contracts, metadata pipeline, reveal mechanic and a clean frontend marketplace takes 8-14 weeks from architecture to mainnet launch. A full custom marketplace with auction mechanics, offers, bundles, royalty enforcement and cross-chain support takes 16-24 weeks. Smart contract audit (4-6 weeks) typically gates the mainnet launch timeline. We deliver in milestone-based sprints with testnet deployments at each stage.
