How to Create an NFT Contract (ERC-721) from Scratch?

Understanding ERC-721 Standard Specifications

1. ERC-721 defines a set of mandatory functions and events that every compliant contract must implement, including ownerOf, safeTransferFrom, and approve.

2. The standard enforces unique token identifiers—each NFT must have a distinct uint256 ID mapped to exactly one owner at any given time.

3. Metadata support is optional but widely adopted; the tokenURI function returns a URI pointing to JSON containing name, description, and image links.

4. Transfer events must emit Transfer with from, to, and tokenId parameters to ensure wallet and explorer compatibility.

5. Support for enumeration is not required by base ERC-721 but many implementations add totalSupply and tokenByIndex for marketplace indexing.

Setting Up Development Environment

1. Install Node.js and npm to manage dependencies like Hardhat or Foundry for local compilation and testing.

2. Initialize a new project with npm init -y and install OpenZeppelin Contracts via npm install @openzeppelin/contracts.

3. Configure Hardhat config file to connect to Sepolia or local Anvil network for deployment simulation.

4. Create a Solidity file named MyNFT.sol in the contracts directory and import OpenZeppelin’s ERC721 and Ownable modules.

5. Define constructor arguments such as name and symbol, then call the parent ERC721 constructor with those values.

Writing Core Contract Logic

1. Add a _baseTokenURI state variable to store the root path for metadata, updated only by the contract owner.

2. Override the tokenURI function to concatenate _baseTokenURI with the tokenId string, ensuring IPFS or HTTP endpoints resolve correctly.

3. Implement a mint function that uses _safeMint to assign new tokens exclusively to msg.sender and increment internal counters.

4. Introduce onlyOwner modifiers on sensitive functions like setBaseURI to prevent unauthorized metadata manipulation.

5. Include a supportsInterface override to return true for 0x80ac58cd (ERC-721) and 0x5b5e139f (ERC-721 Metadata) interface IDs.

Compiling and Deploying on Testnet

1. Run npx hardhat compile to generate ABI and bytecode; verify no syntax or inheritance errors appear.

2. Write a deployment script that calls the contract constructor with “CryptoPanda” and “CPANDA” as arguments.

3. Use npx hardhat run scripts/deploy.js --network sepolia to broadcast the transaction after funding the deployer address.

4. Verify the contract on Etherscan Sepolia using the same compiler version and optimization settings used during compilation.

5. Interact with the deployed contract using Etherscan’s “Write as Proxy” or MetaMask-connected dApp interfaces to trigger minting and transfers.

Frequently Asked Questions

Q: Can I change the tokenURI after minting?A: Yes—if your contract allows it through an owner-only setter function, but changing it retroactively affects all previously minted tokens unless you store per-token URIs.

Q: What happens if two tokens share the same ID?A: The contract will revert during minting due to duplicate mapping checks enforced by OpenZeppelin’s _owners mapping validation.

Q: Is gas cost higher for ERC-721 than ERC-20?A: Yes—ERC-721 operations require individual storage writes per token ID, resulting in significantly higher gas consumption for minting and transferring.

Q: Do I need to implement royalties in the contract?A: No—royalties are not part of ERC-721 specification. Platforms like OpenSea read royalty information from the royaltyInfo function if implemented via ERC-2981.