What this prompt does
This prompt scopes an ERC-721 NFT drop end to end using gas-efficient ERC-721A. You set [collection_name], [total_supply], [target_chain], and the number of [mint_phases], and it builds a contract with maxSupply, [max_per_wallet], and [max_per_tx] limits, multi-phase minting (allowlist via [allowlist_method] at [allowlist_price], then public at [public_price]), a [reveal_strategy], royalties, payment splits, and admin functions.
The structure works because launch-day disasters come from the parts that are easy to get subtly wrong. By specifying the reveal mechanism with a provenance hash and [randomness_source], royalty enforcement via [royalty_standard] at [royalty_percentage] with [marketplace_compliance], metadata in [metadata_format] stored on [metadata_storage], and proceeds split per [payment_splits] using a pull-payment pattern, the prompt forces every launch-critical decision to be concrete before deploy. The [mint_phases] count and per-phase limits like [max_per_wallet] and [max_per_tx] also shape the access control, so a team-reserve, allowlist, then public structure is encoded rather than improvised at mint time.
When to use it
- You are planning an NFT drop and need mint phases, reveal, and royalties handled together
- You want ERC-721A for cheaper batch minting
- You need a Merkle-based allowlist with separate
[allowlist_price]and[allowlist_max] - You want a fair delayed reveal backed by
[randomness_source] - You need on-chain royalty enforcement compatible with
[marketplace_compliance] - You are splitting proceeds across founder, artist, and treasury per
[payment_splits] - You need owner-controlled phase timing and per-wallet caps enforced on-chain
Example output
Expect a full ERC-721A contract: supply and per-wallet limits ([max_per_wallet], [max_per_tx]), phase logic with owner-controlled start/end timestamps, [allowlist_method] verification, a [reveal_strategy] that swaps baseURI from placeholder to revealed metadata, [royalty_standard] implementation at [royalty_percentage], a tokenURI returning [metadata_format], a contractURI, a withdraw function splitting to [payment_splits], and admin functions (setBaseURI, setMintPhase, setPrice, airdrop, pause) that emit events. A reveal and provenance section explains the fairness guarantees and how the committed hash lets anyone verify the assignment afterward. The metadata layer describes how [metadata_format] is served from [metadata_storage], including the contractURI that marketplaces read for collection-level details like name, image, and royalty info.
Pro tips
- Keep placeholders concrete to your real drop — actual
[total_supply],[allowlist_price], and[public_price]so the generated contract matches the collection - Use a Merkle tree for
[allowlist_method]rather than storing addresses on-chain; it is dramatically cheaper at scale - Commit the provenance hash before mint so the
[reveal_strategy]is verifiably fair after the fact - Verify
[randomness_source]is genuinely unpredictable; on-chain pseudo-randomness is exploitable, which is why Chainlink VRF is the default - Confirm royalty enforcement matches current
[marketplace_compliance]reality, since operator-filter behavior has shifted across marketplaces - Reserve airdrop quantities for
[airdrop_recipients]against[total_supply]deliberately, so the public mint does not exceed the cap - Use the pull-payment pattern for
[payment_splits]and test the withdraw path, because stuck funds are a common launch failure
