NFT Collection Development
Many think launching an NFT collection is just copying OpenZeppelin ERC-721 with a mint() function. But real problems start with metadata synchronization, storage choice, and secure deployment. Centralized tokenURI storage is a direct path to rug pulls: the server owner can replace images after sale. We've seen dozens of such incidents. That's why each of our collections uses decentralized schemas: IPFS or Arweave, and contracts are audited. We deliver turnkey NFT collections: from concept to verification on OpenSea.
How to Choose a Smart Contract Standard: ERC-721, ERC-1155, or ERC-721A?
ERC-721 — one token, one owner. Good for PFP collections and unique art. ERC-1155 — one contract, multiple token types, supports fungible and semi-fungible. Right choice for game items where identical items can belong to thousands of players.
For a standard PFP collection (10,000 unique tokens) — ERC-721A (Azuki) instead of standard ERC-721. ERC-721A optimizes batch mint: minting 10 tokens in one transaction costs almost the same gas as minting one in standard ERC-721. That's 50–80% gas savings for users when minting multiple tokens.
How to Protect Your Collection from Rug Pull?
Use decentralized metadata storage (IPFS/Arweave), avoid a centralized server in tokenURI, use battle-tested OpenZeppelin libraries, and pass an audit with Slither and Mythril. The contract should be immutable after reveal so that baseURI cannot be changed.
Which Minting Mechanics Fit Your Collection?
Whitelist / allowlist — addresses from a list mint before the public. Implementation via Merkle Tree (not mapping): the tree root is stored in the contract (32 bytes), and the user provides a Merkle proof during mint. Gas savings on deployment and storage are massive compared to mapping(address => bool) for thousands of addresses.
Signature-based allowlist — an alternative to Merkle Tree. The backend signs permission for a specific address via ECDSA (EIP-712), and the user provides the signature during mint. More convenient for dynamic allowlists (addresses can be added without updating the Merkle root), but requires backend infrastructure.
Dutch Auction — price starts high and decreases every N minutes until floor price. Allows the market to find equilibrium price, reduces gas wars at launch. More complex in implementation: requires correct on-chain price calculation without off-chain data.
Where to Store Metadata and Images: IPFS, Arweave, or On-chain?
tokenURI should return JSON with fields name, description, image, attributes. The critical question is where this JSON and the images are stored.
IPFS + Pinata/NFT.Storage — decentralized storage, content-addressed links (ipfs://Qm...). If pinning stops, the file is theoretically unavailable, but can be restored by any IPFS node that has a copy. Standard for most collections. More on the technology — IPFS on Wikipedia.
Arweave — permanent storage, one-time payment for eternal storage. More reliable than IPFS in terms of persistence. Used for valuable collections and PFP.
On-chain SVG — images are generated directly in the contract as SVG strings. Fully decentralized, impossible to modify. Expensive in gas for deployment (if trait data is stored on-chain), but ideal for simple geometric art projects.
| Criteria | IPFS | Arweave | On-chain SVG |
|---|---|---|---|
| Storage cost | Free if pinned, but needs pinning service | One-time fee for eternity | Included in deployment gas |
| Reliability | Depends on pins | Guaranteed by network | Absolute |
| Data size | Virtually unlimited | Up to ~100 KB | Limited by gas |
| Immutability | Immutable (if properly implemented) | Immutable | Immutable |
Reveal mechanic: During deployment, all tokenURI point to a placeholder. After mint, reveal — the contract updates baseURI to the final IPFS path. Randomness for trait generation is obtained from Chainlink VRF (verifiably random) or from blockhash (manipulable but cheap for non-high-value collections). Chainlink VRF provides provable randomness.
Stack and Process
Contract — Solidity 0.8.x, ERC-721A or OpenZeppelin ERC-721. Tests in Foundry: coverage >90%, gas test for batch mint, Merkle proof verification test. OpenZeppelin libraries are industry standard (OpenZeppelin Contracts).
Metadata is generated via script before deployment: take trait layers, generate combinatorics, check rarity distribution, upload to IPFS via Pinata API. Final IPFS CID is fixed before deployment.
| Stage | Content |
|---|---|
| Contract | ERC-721A + whitelist + public mint + withdraw |
| Metadata | JSON generation, upload to IPFS, CID in contract |
| Tests | Foundry unit + fuzz, gas report |
| Deployment | Sepolia testnet → Ethereum mainnet via Gnosis Safe |
| Verification | Etherscan + OpenSea collection verify |
Common launch mistakes: centralized tokenURI, lack of reentrancy tests on withdraw, incorrect random reveal, ignoring gas optimization, not verifying the contract. We check all these points during our audit.
What's Included
- Smart contract with chosen minting mechanics (whitelist, auction, public)
- Metadata generation and upload to IPFS/Arweave
- Full unit + fuzz tests (Foundry) with coverage >90%
- Mainnet deployment and verification on Etherscan/OpenSea
- Interaction documentation (hardhat/ethers.js)
- 30-day post-launch support
We'll assess your project in 1 day. Contact us for a consultation. Get a consultation for your project — we'll help you choose the optimal solution.
Our Experience and Guarantees
We have launched 50+ NFT collections on Ethereum, Polygon, and BNB Chain. Team with 6+ years of Web3 development experience. We guarantee correct contract operation and security — all contracts undergo internal audit using Slither and Mythril. We provide documentation and instructions for further management.