How to Mint an NFT: Marketplace, Your Own ERC-721, or a Primary Drop

Most people think they “minted” an NFT when they uploaded an image and made a listing. The reality is harsher: minting is an on-chain transaction that creates a new token in a specific smart contract, and it’s irreversible once confirmed. This guide walks through the three practical paths—marketplace UI, deploying your own ERC-721, or running a primary drop—plus the parts that usually break: metadata, gas, and permissions.

TL;DR

• You’ll mint an NFT by creating a new tokenId in an NFT contract and recording ownership on-chain.
• Expect minutes for a simple mint; longer if you’re deploying a contract or setting up a drop.
• The most common mistake is confusing an off-chain listing/upload with an on-chain mint (wrong network, wrong contract, or broken metadata).

Minting an NFT is the moment a blockchain records “a new token exists” and who owns it. Everything else—uploading art, writing a description, setting royalties, even listing for sale—is separate plumbing that may or may not touch the chain. If you’re trying to mint today, the real decision is which path you’re taking: a marketplace-style flow (fast, limited control), your own ERC-721 contract (more control, more responsibility), or a primary drop setup (minting plus sale rules).

What you need before you start

You need a wallet that can sign transactions on the chain you’re minting on. For EVM chains, MetaMask and Rabby are the usual browser-wallet picks; if you’re serious about not losing your deployer key, pair it with a hardware wallet like a Ledger Nano X. If you’re minting on Solana, you’d be thinking Phantom instead, but the standards and tooling in the sources here are EVM-focused (ERC-721, SeaDrop).

You also need the chain’s native token for gas. On Ethereum mainnet that’s ETH; on other EVM-compatible networks it’s their native gas token. The annoying reality: you can have plenty of stablecoins and still be unable to mint because you’re short on gas. Keep a buffer so you can retry if a transaction fails or you need to fix something with a second transaction.

Pick the target network up front and stick to it. “Wrong network” is the #1 reason people can’t find their NFT after minting. Your wallet can happily show you the same address on multiple networks, and marketplaces can show collections on one chain while you minted on another.

Have your media and metadata ready before you hit “confirm.” At minimum you want the NFT name, description, and the media file (image/video). Most NFT systems also expect a JSON metadata file that includes fields like name, description, and attributes. Where you store that metadata matters: if you host it on a server you control and it goes down, the NFT still exists on-chain but displays as a broken image.

Finally, understand what “mint” means on-chain. For ERC-721 NFTs, ethereum.org explains that every NFT has a uint256 tokenId, and “for any ERC-721 Contract, the pair contract address, uint256 tokenId must be globally unique.” That uniqueness model is why “minting” is tied to a specific contract, not just an image you uploaded.

Step-by-step

1. Decide what you’re actually minting: a token in someone else’s contract, or in your own contract. If you mint through a marketplace UI that uses a shared contract, you’re trading control for convenience. If you deploy your own ERC-721 contract, you control supply, mint permissions, and future behavior—but you also own every mistake. This decision affects everything downstream: where tokenIds live, how you verify ownership, and how you recover if metadata is wrong.

2. Choose the mint path that matches your goal: single NFT, collection, or drop with sale rules. If you just need one NFT minted and visible on a marketplace, a platform flow is usually enough. If you’re building a collection or want predictable contract identity (your own contract address), deploy your own contract and mint from it. If you’re doing a primary sale with allowlists, token-gating, or server-signed eligibility, you’re in “primary drop” territory—minting plus sale mechanics—and a protocol like SeaDrop is designed for that.

3. Prepare metadata like it’s permanent, because it usually is. The chain transaction typically stores a pointer (a tokenURI) to metadata, not the full media file. That means your NFT’s “look” depends on the metadata staying available and unchanged. Before minting, open your metadata JSON locally and sanity-check the fields you care about (name, description, attributes) and that the image/media URL resolves. If you’re using IPFS, verify you can fetch the CID from at least one gateway before you mint.

4. If you’re deploying your own contract, deploy first—then mint your first token from that contract. OpenSea’s own tutorial is explicitly framed as “deploy a brand new NFT smart contract and mint your first NFT,” which is the cleanest mental model: contract creation is one on-chain transaction, minting is another. Deployment is where you lock in basics like name and symbol, and it’s also where you can accidentally deploy to the wrong network if your wallet/RPC is mis-set.

5. If you’re doing a primary drop on EVM chains, consider a SeaDrop-compatible contract instead of reinventing sale logic. OpenSea’s SeaDrop docs describe it as “a smart contract protocol for primary drops on EVM-compatible blockchains” supporting “public drops, Merkle Tree-based allowlists, server-signed mints, and token-gated drops.” The point is you don’t have to custom-code every sale mechanic from scratch. The tradeoff is you’re now operating a drop system, not just minting a token.

6. If you manually deploy a SeaDrop-compatible contract, follow the constructor/permission pattern exactly. The SeaDrop docs show a Foundry deployment example: forge create --rpc-url $RPC_URL --private-key $PRIV_KEY --constructor-args "ExampleToken" "ExTkn" [0x00005EA00Ac477B1030CE78506496e8C2dE24bf5]. That allowedSeaDrop address (0x00005EA00Ac477B1030CE78506496e8C2dE24bf5) is the permission hook that lets the SeaDrop contract mint on your token contract. If you deploy without setting it, the docs note you can call updateAllowedSeaDrop later, but that’s still another on-chain transaction you must execute correctly.

7. Don’t “improve” mint functions in a SeaDrop-compatible contract unless you’re ready to own the fallout. OpenSea is blunt here: “To ensure users have a seamless experience minting your drop on OpenSea, please do not modify any minting functionality.” People ignore this, tweak mint logic, and then wonder why the drop UI or mint flow breaks. If you need custom behavior, you can extend contracts, but treat minting paths as fragile integration points.

8. If you want programmatic or agent-assisted minting, set it up like you would any production key workflow: minimal permissions, short-lived keys, and explicit network checks. OpenSea’s “Build with AI Agents” docs provide an instant API key endpoint: POST https://api.opensea.io/api/v2/auth/keys, which returns a free-tier key with “60/min read, 5/min write, 30-day expiry.” They also document an MCP server endpoint (https://mcp.opensea.io/mcp) that exposes tools including “minting” and “SeaDrop contract deployment.” This is powerful for automation, but it’s also where people do the dumbest thing possible: pasting a real private key into a prompt or a script they don’t understand.

What goes wrong

Wrong network selected (you minted, but can’t find the NFT). Symptom: the transaction is confirmed, but your wallet or marketplace shows nothing, or you see the contract on one chain explorer but you’re checking another. Fix: check the transaction hash on the correct explorer for the chain you used, then add the NFT contract address to your wallet on that same network. Remember ERC-721 uniqueness is (contract address, tokenId); if you’re looking at the wrong chain, you’re looking at a different universe.

Insufficient gas or wrong gas token. Symptom: your wallet throws an “insufficient funds” error even though you have assets, or the transaction fails immediately. Fix: you need the native gas token on that network, not an ERC-20. Bridge or transfer in the correct gas token, then retry. If you’re deploying a contract, expect to need more gas than a simple mint.

Pending transaction that sits forever. Symptom: your mint is “pending” for a long time, and you’re afraid to click anything else. Fix: don’t spam retries; you can end up with multiple competing transactions. Use your wallet’s speed-up/cancel feature if available, and verify the nonce. If you’re comfortable, check the mempool status on a block explorer. The core idea is simple: the chain will only accept one transaction per nonce, so you either replace it with a higher-fee version or wait.

You approved something and left permissions open. Symptom: after minting or interacting with a drop, you notice your wallet asked for an approval, and now you’re uneasy about what can move your assets. Fix: review and revoke approvals you no longer need using a reputable approval management tool like Revoke.cash. This matters because ERC-721 includes approval mechanics, and approvals are a common “I didn’t get hacked, I just signed something” failure mode.

Metadata looks wrong or media is broken. Symptom: the NFT exists, but the image doesn’t load, attributes are missing, or the name is wrong. Fix: first confirm what tokenURI the contract returns for your tokenId (marketplaces often show it). If the tokenURI points to a URL you control, fix the hosted JSON/media. If it’s immutable (like an IPFS CID you can’t change), your recovery options depend on the contract: some contracts allow updating tokenURI; others don’t. This is why you validate metadata before minting.

SeaDrop mint fails or drop UI doesn’t work. Symptom: users can’t mint, or the mint button errors out even though the contract is deployed. Fix: verify you set the allowedSeaDrop address correctly (0x00005EA00Ac477B1030CE78506496e8C2dE24bf5 per the docs) or updated it via updateAllowedSeaDrop. If you modified minting functions, assume you broke compatibility; revert to the standard minting behavior if you want the OpenSea drop experience.

Private key exposure in CLI/agent flows. Symptom: you pasted a private key into a command, chat, or tool config, and now you’re not sure who saw it. Fix: treat it as compromised. Move assets to a fresh wallet immediately, rotate keys, and stop using raw private keys in automation. Use a hardware wallet or a secure signer setup instead. This is one of those mistakes that doesn’t always bite instantly, which is why it keeps happening.

When this isn't the right move

Minting isn’t the same as “getting an NFT on a marketplace.” If your real goal is to sell something quickly and you don’t care about contract ownership, a marketplace-managed flow can be the better choice because it reduces contract responsibility. Deploying your own ERC-721 contract just to mint one item is often overkill, and it increases the number of irreversible steps.

Running a primary drop also isn’t just “minting with a nicer page.” SeaDrop supports public drops, allowlists, server-signed mints, and token-gated drops, which is great—until you realize you now have operational tasks (Merkle roots, signature services, eligibility logic) that can fail in ways a simple mint can’t. If you don’t need those mechanics, keep it simple.

Tools and references

If you want the canonical ERC-721 behavior and the on-chain definition of uniqueness, ethereum.org’s ERC-721 standard page is the reference to keep open while you work.

If you want a practical deploy-and-mint flow that matches how a major marketplace expects collections to behave, OpenSea’s “Deploy an NFT Contract” tutorial is the direct path.

If you’re building a drop with sale mechanics, OpenSea’s SeaDrop docs are the relevant spec-level overview, including the allowedSeaDrop address and the warning about not modifying minting functions.

If you’re automating minting or deployment, OpenSea’s “Build with AI Agents” docs cover the API key endpoint and the MCP server endpoint (https://mcp.opensea.io/mcp) that exposes minting and SeaDrop deployment tools.