How to write a smart contract for NFTs? (Solidity basics)

Understanding the ERC-721 Standard

1. ERC-721 is a widely adopted Ethereum token standard designed specifically for non-fungible tokens.

2. It defines core functions such as ownerOf, transferFrom, and approve to manage unique asset ownership.

3. Every ERC-721 contract must implement the IERC721 interface and emit standardized events like Transfer and Approval.

4. Metadata support via the tokenURI function allows linking each NFT to JSON files containing name, description, and image URLs.

5. The standard enforces uniqueness by assigning a distinct uint256 tokenId to every token within the same contract.

Setting Up the Development Environment

1. Install Node.js and npm to manage dependencies and run local tools like Hardhat or Truffle.

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

3. Configure a Hardhat project with npx hardhat, selecting the sample project option to generate boilerplate files.

4. Create a Solidity file under contracts/, naming it MyNFT.sol, and import OpenZeppelin’s ERC721 implementation.

5. Set up a local test network using Hardhat Network or connect to a public testnet like Sepolia via Alchemy or Infura API keys.

Writing the Core Contract Logic

1. Declare the contract with contract MyNFT is ERC721, ERC721URIStorage to inherit essential functionality and metadata storage.

2. Define a constructor that passes name and symbol arguments to the parent ERC721 constructor and sets an owner address.

3. Implement a mint function that uses _safeMint to assign a new tokenId to a specified address and stores its URI via _setTokenURI.

4. Add access control so only the contract owner can call mint, using OpenZeppelin’s Ownable modifier.

5. Enforce minting limits by tracking total supply with a private uint256 variable and reverting if the cap is exceeded.

Testing and Deployment Considerations

1. Write test scripts in JavaScript or TypeScript using Hardhat’s built-in ethers library to simulate minting, transferring, and querying tokens.

2. Verify behavior with assertions checking ownerOf returns the correct address and tokenURI matches expected metadata paths.

3. Deploy the contract using Hardhat’s npx hardhat run scripts/deploy.js --network sepolia command after configuring network credentials.

4. Use Etherscan’s verification tool to submit source code, compiler version, and constructor arguments for public transparency.

5. Store all token URIs on decentralized infrastructure like IPFS or Arweave to ensure permanent, tamper-resistant metadata availability.

Frequently Asked Questions

Q: Can I change the tokenURI after minting?A: Yes, if your contract inherits ERC721URIStorage and you implement a function with appropriate access control to call _setTokenURI.

Q: What happens if two tokens have identical tokenIds in the same contract?A: It is impossible — ERC-721 requires each tokenId to be globally unique within the contract; duplicate assignments will revert.

Q: Do I need to write my own supportsInterface function?A: No — OpenZeppelin’s ERC721 implementation includes a compliant supportsInterface that returns true for 0x80ac58cd (ERC-721) and 0x5b5e139f (ERC-721Metadata).

Q: Is it safe to use transferFrom without checking approval status?A: The OpenZeppelin ERC721 implementation handles all approval validations internally; calling transferFrom directly is safe when used correctly.