Decentralized GameNFT Marketplace

At a Glance

Token standardERC721

Asset storageIPFS

Off-chain computeMoralis

Security checkSHA-3

The Problem

Game asset marketplaces need transparent ownership and secure transfers, but storing everything directly on-chain is expensive and inflexible. The project needed to preserve decentralization and verifiability while keeping storage and computation costs practical for a real marketplace workflow.

System Architecture

Details Inspector

Smart Contracts (ERC721 + Marketplace)

Service

Two contracts handle the full marketplace lifecycle. NFTToken extends OpenZeppelin's ERC721 with EIP-2981 royalty enforcement: minting assigns a tokenId, stores a tokenURI pointing to IPFS, and registers a royalty basis-points value per token. NFTMarketplace handles listing (verified ownership required), purchasing (price match, royalty split, ownership transfer via safeTransferFrom), and royalty disbursement to the original creator on every secondary sale. All state — listings, prices, royalty recipients — lives on-chain. The contracts are immutable after deployment.

Why This Component

Splitting token logic from marketplace logic is the standard ERC721 pattern. NFTToken is a lean, standards-compliant token contract; NFTMarketplace is a separate contract that operates on tokens it does not own, requiring explicit approval before it can transfer. This keeps the token contract auditable and reusable across multiple marketplace deployments.

Immutability is a constraint, not a feature

Once deployed, the contracts cannot be patched. Every bug is permanent. OpenZeppelin's audited base contracts reduce surface area, but custom marketplace logic still requires rigorous pre-deployment testing. Proxy upgrade patterns exist but add governance complexity — choose them only if post-deployment upgrades are a hard requirement.

Trade-offs

On-chain state is globally verifiable and censorship-resistant. Gas costs are real: every listing, purchase, and royalty payment costs the user ETH. Complex marketplace logic (auctions, bundles) multiplies gas consumption. The contract size limit (24 KB) constrains how much logic you can pack into a single contract.

Alternatives

ERC-1155 (multi-token standard) is preferable for fungible game items; ERC-721 is the right choice for unique, non-fungible assets. Lazy minting (signing a voucher off-chain, minting on first purchase) defers gas costs to the buyer and is common in high-volume marketplaces.

The On-Chain / Off-Chain Split

Decentralization is a spectrum. Storing every asset and computation on-chain would make the marketplace prohibitively expensive. Instead, the design draws a deliberate trust boundary: ownership, transfers, and royalty rules live on-chain where they must be tamper-proof; media, metadata, and heavy computation live off-chain where storage and gas costs are manageable. SHA-3 hash anchoring bridges the two sides so off-chain results remain publicly verifiable.

On-chainSource of truth

·NFT ownership — ERC721 transfer events are the authoritative ledger
·Marketplace listings — Listing price and seller stored in contract state
·Royalty enforcement — EIP-2981 royaltyInfo called on every sale, on-chain
·SHA-3 hashes — Off-chain result digests anchored in contract events

Off-chainCost reduction

·Media + metadata — IPFS CIDs stored on-chain; files live off-chain
·Game result computation — Moralis cloud functions run expensive logic off-chain
·Leaderboard aggregation — Too expensive to compute on-chain per transaction
·Anti-cheat verification — Results hashed and anchored — off-chain speed, on-chain proof

NFT Lifecycle Flows

Two flows cover the core marketplace lifecycle. Minting traces a game asset from IPFS upload through metadata anchoring to on-chain token creation. The purchase flow shows how a buyer's ETH is split between royalty, seller proceeds, and NFT ownership transfer in a single atomic contract call. Click any step to inspect the contract interaction.

Key Decisions

1
Kept large asset payloads in IPFS so the chain stores references, not the full media payload, dramatically reducing cost.
2
Extended OpenZeppelin contracts instead of writing token logic from scratch to inherit audited ERC721 behavior.
3
Used Moralis for off-chain workflows where raw on-chain execution would make gas costs unreasonable.
4
Added on-chain SHA-3 verification to preserve trust even when some calculations happen off-chain.

Outcomes

Delivered a working NFT marketplace flow covering minting, listing, purchase, and asset lookup.
Reduced blockchain storage overhead by moving media and metadata to IPFS while preserving immutable references.
Introduced creator royalty and anti-cheating mechanisms that improved both marketplace utility and user trust.

Lessons Learned

1Decentralization is a spectrum; practical products often need carefully bounded off-chain systems to stay usable.
2Using audited contract libraries is almost always the right default for student and early-stage blockchain projects.
3Hash anchoring is a strong compromise when you need off-chain speed without giving up verifiability.
4Developer tooling matters a lot in smart contract work — Hardhat made iteration far safer and faster.

At a Glance

The Problem

System Architecture

Frontend dApp

Smart Contracts (ERC721 + Marketplace)

IPFS Asset Storage

Moralis Off-Chain Compute

SHA-3 Hash Anchoring