If you’re serious about Creating 3D and interactive NFTs, the best results come from a smart toolchain: a modeling pipeline built on the glTF 2.0 format, a performant web viewer for real-time interactivity, robust decentralized storage, and a creator-owned smart contract that follows the core NFT standards. In plain terms, a 3D/interactive NFT is a non-fungible token (ERC-721 or ERC-1155) whose media and metadata point to assets such as GLB/glTF scenes or even an HTML/WebGL app, allowing buyers to rotate, animate, and interact with your work right in the browser or AR viewer.
Quick definition: an NFT is a unique token on a blockchain; 3D/interactive NFTs are those whose image or animation_url fields reference 3D files or web apps that render interactively. OpenSea’s metadata spec explicitly supports GLTF/GLB, MP4/WEBM, audio, and even HTML pages for rich interaction.
At a glance, the build path looks like this:
1) model in a glTF-friendly DCC (e.g., Blender); 2) optimize meshes, textures, and animation; 3) choose a real-time viewer (Three.js/Babylon/<model-viewer>/Unity WebGL); 4) host assets on IPFS/Filecoin or Arweave; 5) deploy an ERC-721/1155 contract (OpenZeppelin + Remix/Hardhat); 6) set image/animation_url to your GLB/HTML; 7) list or airdrop on a marketplace (e.g., Zora, OpenSea). A short disclaimer before we dive in: NFTs can involve financial risk and legal/IP considerations—treat the following as educational guidance, not investment or legal advice.
Below are 11 carefully selected tools and platforms, each explained with concrete steps, specs, and guardrails so you can ship interactive collectibles that render reliably across wallets and marketplaces.
1. Blender + glTF 2.0 Export: Your 3D Creation Workhorse
Answer first: Use Blender to model, rig, and animate your assets, then export to glTF 2.0/GLB—the web-native format that preserves PBR materials, animations, skins, and morph targets with efficient transmission. Blender’s official glTF 2.0 exporter supports metallic-roughness PBR and unlit materials and converts textures to PNG/JPEG as needed, making it the most dependable starting point for WebGL pipelines.
Blender’s glTF exporter is mature, widely used, and kept in sync with the Khronos specification. It automatically handles texture conversions (e.g., PNG/JPEG) and writes a single .glb (binary glTF) or a .gltf + .bin + textures set, so you can pick portability or modularity. GLB is convenient for marketplaces that accept one file per NFT, while split glTF is handy when you want to reuse textures across variants. The exporter also preserves vertex skins, morph targets (shape keys), cameras, and animation clips, all of which map cleanly to web viewers like Three.js and Babylon.js. If you’re shipping stylized work, the KHR_materials_unlit path avoids PBR overhead for fast, crisp rendering; if you’re chasing realism, stick with metallic-roughness and keep texture sizes in check.
How to do it (Blender → GLB):
- Model clean topology; apply transforms; keep scale consistent (e.g., meters).
- UV unwrap all meshes; pack UVs efficiently; avoid overlapping UVs unless intentional.
- Bake and compress textures to PNG/JPEG, typically 1,024–2,048 px for hero assets; trim alpha where possible.
- Name animation actions clearly (e.g., Idle, Spin, Open)—export with “NLA Strips” if needed.
- File → Export → glTF 2.0; choose GLB for a single file; enable “Apply Modifiers,” “+Y Up,” and include materials/animations.
Numbers & guardrails:
- Aim for < 50 MB per GLB when targeting single-item uploads on OpenSea (its single-item upload limit is 50 MB; larger limits exist in Drops). Keep texture sets to ≤ 2–3 2K maps per hero mesh; consider 1K for props.
- Favor tri counts under ~100k–200k per asset for smooth WebGL on laptops; heavy scenes can be split into multiple tokens or streamed.
Wrap-up: A clean Blender → glTF 2.0 pipeline ensures your NFT renders predictably across viewers and marketplaces, giving you a solid foundation for interactivity.
2. Web Viewers & Engines for Interactivity: Three.js, Babylon.js, <model-viewer>, PlayCanvas, A-Frame
Answer first: To make your NFT interactive, render the GLB/glTF or an HTML app via the animation_url. Browser-first engines like Three.js and Babylon.js load glTF with PBR materials, skins, and animations; <model-viewer> offers a no-code component with AR; PlayCanvas provides a high-performance engine and open-source glTF viewer; A-Frame gives declarative VR/AR scenes. OpenSea’s metadata supports GLB/GLTF and HTML in animation_url, so collectors can rotate, animate, or interact right in the listing page or a token-gated site.
Three.js’s GLTFLoader brings in meshes, materials, skins, morph targets, and animation clips; Babylon.js’s glTF loader supports progressive loading and a breadth of glTF 2.0 extensions for rich rendering; <model-viewer> adds easy lighting, exposure, and mobile AR; PlayCanvas ships a reference glTF Viewer and a production-ready engine; A-Frame’s gltf-model component makes scene authoring approachable. In practice, you can prototype a viewer with <model-viewer> in minutes, then graduate to Three.js/Babylon.js or PlayCanvas for custom shaders, physics, or multiplayer.
How to wire an interactive animation_url:
- Host your GLB or HTML app on IPFS/Arweave (see Items 8–9).
- In your NFT metadata JSON, set animation_url to the asset’s ipfs://CID or a gateway URL; keep image as a poster PNG for wallets.
- For Three.js/Babylon/PlayCanvas apps, bundle a minimal HTML with a canvas and loader; ensure absolute URLs for assets.
- With <model-viewer>, embed a simple HTML page using <model-viewer src=”ipfs://…/asset.glb” ar auto-rotate camera-controls>.
Numbers & guardrails:
- Target 60 FPS on mid-range laptops; progressive/streaming loaders in Babylon.js can reduce time-to-first-frame.
- Use glTF (not legacy formats) and keep the number of draw calls low; PlayCanvas and Three.js both handle GLB well, but excessive materials hurt performance. blog.playcanvas.com
Wrap-up: Pick the viewer that matches your complexity: <model-viewer> for speed and AR, Three.js/Babylon for custom WebGL, PlayCanvas/A-Frame for full apps and WebXR.
3. Unity WebGL + thirdweb Unity SDK: Game-Grade Interaction with Wallets
Answer first: If you need physics, complex animation graphs, or game-style UX, Unity’s WebGL target lets you ship your scene to the browser, while thirdweb’s Unity SDK adds wallet connection, NFT minting/claiming, and marketplace actions in-engine. Build once, publish to the web, and point your NFT’s animation_url at the hosted Unity WebGL build for a fully interactive token experience.
Unity compiles your scene to WebAssembly/JS and outputs a Build/ folder that runs in modern browsers. With thirdweb’s Unity SDK, you can connect EVM wallets, read token ownership, call ERC-721/1155 methods, and even implement game loops like “burn to redeem” or NFT-gated scenes. This approach suits 3D generative sculptures with physics, interactive dioramas, or playable collectibles. The trade-off is bundle size and memory—optimize aggressively and lazy-load heavy content.
How to ship a WebGL + wallet experience:
- In Unity, switch File → Build Settings → WebGL, then Build & Run; host the output on a static site or IPFS gateway.
- Add thirdweb Unity SDK; wire a connect-wallet UI, then read tokenURI and fetch GLB or JSON metadata on demand.
- Point your NFT’s animation_url to the hosted index.html so marketplaces can open it in an iframe/lightbox.
Numbers & guardrails:
- Keep initial WebGL payloads lean; split large scenes into AssetBundles or addressables and stream them. thirdweb shows patterns for rendering 3D NFT assets inside Unity via asset bundles. thirdweb
- Test across browsers; Safari and mobile WebGL have tighter memory limits than desktop Chromium engines.
Wrap-up: Unity + thirdweb gives you “game-feel” interactivity with first-class wallet/NFT primitives—ideal when a simple web viewer isn’t enough.
4. Manifold Studio & Extensions: No-Code Creator-Owned Contracts (Plus HTML & Dynamic NFTs)
Answer first: Manifold Studio lets you deploy your own ERC-721 or ERC-1155 contract—no code required—so you keep creator ownership while minting rich media, including .glb and HTML NFTs. Developers can attach Dynamic NFT Extensions that switch metadata on-chain (e.g., time-based states), giving you a path from static 3D pieces to interactive tokens without rebuilding your contract.
Manifold’s Creator Core contracts support minting, transferring, and modifying token metadata identifiers under your control, and the platform’s UI streamlines deployment and drop configuration. For 3D artists, native GLB support and HTML NFTs make it straightforward to deliver real-time experiences via animation_url. When you’re ready to go dynamic—say, day/night cycles or evolving sculptures—Manifold’s extension pattern demonstrates how to return different metadata depending on block time or other conditions.
How to launch with Manifold:
- Create a Creator contract (ERC-721 or ERC-1155) in Studio; configure name, symbol, and royalty info.
- Upload your .glb or an .html interactive; Manifold lists supported types explicitly, including .glb and .html.
- (Optional) Add a Dynamic NFT Extension that changes token URI based on logic like timestamps.
Numbers & guardrails:
- Use a poster image (~2–3 MB PNG/JPEG) in image for wallet previews; keep your GLB under OpenSea’s single-item 50 MB limit where relevant.
- If you plan frequent metadata changes, implement the ERC-4906 MetadataUpdate event so marketplaces refresh quickly.
Wrap-up: Manifold balances no-code simplicity with extendability—perfect for artists who want control of their contracts and the option to go dynamic later.
5. Zora Protocol & Creator Tools: Mint, Distribute, and Interoperate
Answer first: Zora provides a creator-friendly protocol and tools to mint and distribute NFTs, plus an L2 network focused on NFTs that’s compatible with major marketplaces. You can launch collections, editions, or experimental formats, then use animation_url to point at GLB/HTML for interactive displays on-chain.
Zora’s creator flow makes it simple to publish assets and benefit from an NFT-native ecosystem designed for discovery and low-cost transactions on its L2. Its protocol and SDKs integrate with standard ERC-721/1155 semantics, so your 3D and interactive media behave like any other NFT across compatible wallets and markets. For projects that expect high mint volumes or on-chain interactions (e.g., evolving art tied to user actions), a cost-efficient L2 can keep gas predictable.
How to use Zora in a 3D/interactive pipeline:
- Create a collection via Zora’s creator tools; upload your media and metadata.
- Ensure metadata includes image (poster) and animation_url (GLB/HTML) for interactivity.
- List or enable mint pages, then embed or link from your site and social channels.
Numbers & guardrails:
- Favor GLB (binary glTF) for a single-file animation_url; combine with streaming if your interactive is heavier than 50 MB on marketplaces that enforce that limit.
- For royalties, implement EIP-2981 in your contract so compatible marketplaces can read payout info uniformly.
Wrap-up: Zora’s protocol + L2 simplify minting and distribution while staying friendly to 3D/interactive media conventions.
6. thirdweb SDKs & Contract Kits: Multichain Apps, Drops, and Dynamic Collections
Answer first: thirdweb offers SDKs for React/TypeScript, Unity, Python, and more, plus audited contract factories (ERC-721/1155, drops, marketplaces). It’s a developer-grade way to add wallet flows, token gating, on-chain royalties, and dynamic NFT behaviors such as loyalty points or evolving metadata—without reinventing your backend.
You can scaffold a full mint site or marketplace quickly, then extend it with serverless functions or CRON jobs that update metadata (e.g., levels, traits, or rarity unlocks). thirdweb’s examples cover on-chain metadata, loyalty programs, and gaming-oriented patterns (e.g., burn-to-redeem), and its Unity SDK pairs naturally with WebGL builds (see Item 3). Taken together, it’s a productive stack for studios that want to ship, measure, and iterate.
How to ship with thirdweb:
- Use the CLI to bootstrap a minting site or contract (npx thirdweb create). docs.celo.org
- Deploy ERC-721/1155 drop or collection contracts, then call mintTo/claim endpoints from your app. docs.moonbeam.network
- For dynamic NFTs, follow thirdweb’s loyalty card or on-chain metadata guides; update attributes over time. thirdweb
Numbers & guardrails:
- Keep per-mint payloads minimal; large animation_url assets can be pre-pinned to IPFS (see Item 8) and referenced by CID.
- Expose royaltyInfo via EIP-2981 to align with marketplaces’ payout readers.
Wrap-up: thirdweb accelerates multichain, production-grade NFT apps and is especially strong for interactive 3D/game-adjacent launches.
7. OpenSea Metadata & Listing: Getting Interactivity to Render
Answer first: To ensure your 3D/interactive NFT displays correctly on major marketplaces, follow OpenSea’s metadata standard. Set a high-resolution poster in image and put your GLB/HTML/WebM in animation_url. OpenSea explicitly lists GLTF/GLB, WebM/MP4/M4V/OGV/OGG, and MP3/WAV/OGA, and it supports HTML for rich, JavaScript-powered experiences. Respect the 50 MB single-item upload cap (higher limits apply to Drops). Implement EIP-2981 royalties for consistent secondary-sale payouts.
OpenSea caches images and reads traits from your JSON, so ensure your attributes follow the common [{ “trait_type”: “…”,”value”: “…” }] pattern. If you plan to update metadata, emit the ERC-4906 MetadataUpdate event so marketplaces know to refresh. When you pin assets to IPFS or Arweave, keep the JSON’s links content-addressed (CID or permaweb TX) to avoid link rot and to give buyers confidence that the media won’t silently change.
How to get it right on first mint:
- Validate your JSON against OpenSea’s field list (name, description, image, animation_url, attributes).
- Use a 3000×3000 poster image for crisp thumbnails; keep the GLB under the size cap or host via IPFS/Arweave and reference by CID/URI.
- If you change on-chain tokenURI, emit MetadataUpdate so marketplaces auto-refresh.
Wrap-up: Correct metadata is what makes interactivity show up in listings; treat animation_url and EIP-2981/EIP-4906 as non-negotiables.
8. IPFS + Filecoin with NFT.Storage: Content-Addressed Media for NFTs
Answer first: IPFS gives you content-addressed storage via CIDs, so the hash is the address; NFT.Storage pins your media to IPFS and stores it on Filecoin for long-term durability, exposing ipfs:// URIs you can place in image/animation_url. This combo is the mainstream default for off-chain NFT media.
With IPFS, anyone retrieving ipfs://bafy… verifies the content cryptographically, preventing silent swaps. NFT.Storage historically offered free uploads (“Classic”); today, the project’s Classic uploads are decommissioned, while the new service emphasizes long-term preservation on Filecoin with a one-time fee model—plan budgets and pinning strategies accordingly. For maximum resilience, pin with multiple services or run your own IPFS node, and consider gateway fallbacks in your HTML viewer.
How to publish to IPFS for NFTs:
- Generate a JSON metadata file with name, description, image, animation_url, and attributes.
- Upload media and JSON via NFT.Storage (client SDK or web UI); you’ll receive CIDs for each asset.
- Reference assets using ipfs://<CID> rather than HTTP URLs to preserve content addressing; follow IPFS’s NFT best-practices.
Numbers & guardrails:
- Treat CIDs as immutable; updating media means minting a new CID and (if needed) updating tokenURI + emitting ERC-4906.
- Prefer GLB for animation_url to keep to a single file; if your interactive is an HTML app, bundle assets and avoid cross-origin blocking.
Wrap-up: IPFS/Filecoin via NFT.Storage is the standard way to keep 3D assets verifiable and widely retrievable, while staying compatible with wallets and markets.
Storage quick comparison (glance)
| Option | What it is | When to use | Notable traits |
|---|---|---|---|
| IPFS + Filecoin (NFT.Storage) | Content-addressed storage with long-term deals on Filecoin | General 3D/HTML NFT media | CIDs, verifiable; new NFT.Storage uses one-time fee model. |
| Arweave + Bundlr | Permanent on-chain data (permaweb) with fast uploads | Immutable, archival-grade media or full HTML apps | Bundlr speeds uploads; per-byte upfront cost; permanent persistence. |
9. Arweave + Bundlr: Permanent “Permaweb” for Immutable 3D/HTML NFTs
Answer first: When you need permanence, Arweave stores data on-chain for the long haul, and Bundlr (Irys) batches uploads and lets you pay with many chains’ tokens while achieving dramatically faster throughput. For interactive NFTs—especially HTML apps where you want code to persist unaltered—Arweave is a strong choice.
Arweave’s design aims to make data available indefinitely; you pay once up front and the network economically incentivizes continued storage. Creators often use Bundlr or similar “bundlers” that package many files into a single on-chain transaction (ANS-104 bundles) and provide instant availability via gateways. This is particularly useful for multi-file HTML experiences: you can ship JS/CSS/GLB/texture files together, then set animation_url to the Arweave TX URL (or ar:// URI) and know the experience won’t disappear because a gateway cache expired.
How to publish an interactive NFT to Arweave:
- Use a Bundlr/Irys SDK or CLI to upload your GLB and/or HTML app; capture the returned transaction ID.
- Put the ar://<txid> (or HTTPS gateway) in animation_url; keep image as a static PNG/JPEG poster.
- For structured directories, consider ArFS (Arweave File System) to organize files and metadata. docs.ardrive.io
Numbers & guardrails:
- Bundlr reports ~3,000× faster uploads than direct on-chain posting—handy for big GLBs or multi-file HTML builds. Medium
- Test your viewer across multiple Arweave gateways to ensure robustness under load.
Wrap-up: If immutability is part of the artwork’s concept or collector promise, Arweave + Bundlr delivers “forever-storage” for your 3D scenes and web apps.
10. OpenZeppelin + Remix + Hardhat: The Secure Smart-Contract Stack
Answer first: Use OpenZeppelin Contracts (battle-tested ERC-721/1155/2981/4906), Remix (browser IDE) for quick deployment, and Hardhat for local development, testing, and scripted deployments. This trio is the default for shipping secure, upgrade-aware NFT contracts that marketplaces and wallets already understand. HardhatGitHubwizard.openzeppelin.com
OpenZeppelin’s Contracts Wizard generates a minimal ERC-721/1155 with features like royalties (EIP-2981), enumerable/token URI storage, access control, and pausing. You can compile and deploy in Remix with an injected wallet, or set up Hardhat for automated tests, networks, and CI. If you’ll be updating token URIs (for dynamic metadata), add ERC-4906 events so marketplaces refresh efficiently; if you need complex drops, consider layering marketplace or drop contracts (thirdweb or your own) atop these base primitives.
How to go from zero to mint:
- Use Contracts Wizard to scaffold ERC-721 + Royalty; download the Solidity file.
- In Remix, paste the contract, compile, and deploy via MetaMask.
- For production, initialize a Hardhat project, write tests, and configure deployments (e.g., Ignition).
Common mistakes to avoid:
- Hard-coding HTTP URLs in tokenURI (prefer content-addressed IPFS/Arweave links).
- Skipping royaltyInfo (EIP-2981) and MetadataUpdate (EIP-4906), which hinders marketplace behavior.
Wrap-up: The OZ + Remix + Hardhat stack keeps your NFT contracts standards-compliant, auditable, and easy to maintain as your 3D project scales.
11. Chainlink Automation & Oracles + ERC-4906: Truly Dynamic NFTs
Answer first: For NFTs that change with data or time, pair your contract with Chainlink Automation (to schedule updates) and Chainlink oracles (to fetch off-chain signals), and emit ERC-4906 events whenever metadata changes so marketplaces refresh. This is how you go from “click-to-rotate” to living works that evolve with weather, scores, or user actions.
Chainlink’s guides show how to schedule NFT state changes and rebuild metadata on demand, while the oracles safely bring in external data (think sports stats, IoT sensors, or DeFi prices). Your contract can switch the tokenURI between different JSON CIDs or compute URIs dynamically; on update, fire MetadataUpdate(tokenId) (or BatchMetadataUpdate) so marketplaces pick up the new visuals immediately. For simple time-of-day or randomization, you can rely on block data; for richer dynamics (e.g., “evolves after 100 on-chain interactions”), track counters and checkpoints in storage.
How to implement dynamic behavior:
- Add Automation to trigger updateState() periodically (e.g., hourly) or on conditions.
- Use oracles for external events; update on-chain attributes and swap metadata CIDs. Chainlink
- Emit MetadataUpdate/BatchMetadataUpdate so wallets/markets refresh.
Numbers & guardrails:
- Keep on-chain update gas under practical limits; batch updates with BatchMetadataUpdate(_from, _to) for ranges.
- Cache heavy assets; only the small JSON changes need to point to new CIDs.
Wrap-up: With Chainlink Automation and ERC-4906, your 3D NFTs can respond to the world, while staying legible to marketplaces and wallets.
Conclusion
Bringing a responsive 3D artwork on-chain isn’t about any single app—it’s about composing the right stack. Model in Blender and export clean glTF 2.0; pick a web viewer or engine that matches your ambition; use IPFS/Filecoin or Arweave for durable, verifiable storage; mint on creator-owned contracts (Manifold, OZ) and list where metadata standards are honored; and when you’re ready, fold in dynamic behavior with Chainlink and ERC-4906. If you keep file sizes trim, adopt open standards (ERC-721/1155/2981), and test on the same gateways and marketplaces your collectors use, your tokens will render fast, look right, and age well.
Next steps: choose one item above to pilot a small drop—say, a five-piece GLB mini-series with animation_url pointing to a <model-viewer> page on Arweave—then evolve into a richer interactive or game-like experience with Unity + thirdweb. Ship one, learn, iterate, repeat—and invite your collectors to play, not just look.
Call to action: Ready to build? Pick your stack from the 11 above, start with a single test mint, and turn your next 3D idea into an interactive NFT collectors can explore.
FAQs
1) What’s the difference between image and animation_url in NFT metadata?
image is a static poster (PNG/JPEG/SVG) that wallets use for thumbnails; animation_url points to richer media such as GLB/GLTF, video, audio, or even an HTML page for interactive/WebGL experiences. Using both ensures your token looks good in simple UIs and shines in advanced viewers or marketplace lightboxes. Follow OpenSea’s metadata fields so your assets render consistently.
2) Should I mint ERC-721 or ERC-1155 for 3D/interactive collections?
ERC-721 represents unique one-of-ones; ERC-1155 lets a single contract issue both unique and editioned items efficiently (batch mints/transfers). If you’re selling editions of the same GLB or interactive, 1155 can reduce gas and simplify management; if every piece is unique, 721 is the classic fit. ethereum.org
3) How do I keep my NFT’s media from breaking in the future?
Use content-addressed storage (IPFS CIDs) or permanent storage (Arweave). Avoid mutable HTTP URLs that can change or disappear. Pin with multiple providers or run your own node; when you must update, publish new CIDs and emit ERC-4906 metadata-update events so marketplaces refresh.
4) Can marketplaces actually render GLB/glTF or HTML?
Yes. OpenSea’s spec lists GLTF/GLB and supports HTML in animation_url, enabling interactive NFTs that use JavaScript, WebGL, or WebXR. Some curated markets may have partial 3D support; always check each platform’s file-type notes before listing.
5) How do royalties work for 3D NFTs?
Implement EIP-2981 (royaltyInfo) in your ERC-721/1155 contract. This standard lets marketplaces query the royalty recipient and amount, improving payout consistency across venues. You’ll still want to verify each market’s enforcement policy, but EIP-2981 is the common language.
6) What about performance—how large can my GLB be?
As a rule of thumb, keep single-item GLBs under 50 MB to fit OpenSea’s upload cap and maintain snappy loads. Use mesh decimation, texture compression, and lazy loading. Engines like Babylon.js support progressive loading to reduce time-to-first-frame for big scenes. OpenSea Help Center
7) Do I need a custom contract, or can I use a platform like Manifold or Zora?
If you want full control and provenance under your contract address, Manifold’s Creator contracts are a strong no-code option. Zora offers protocol-level minting and an NFT-focused L2 for low-cost distribution. Both are compatible with ERC-721/1155 standards and major marketplaces.
8) How do I add animation or state changes over time?
Use a dynamic NFT pattern: schedule updates with Chainlink Automation, fetch external data with oracles if needed, switch metadata CIDs or compute URIs on the fly, and emit ERC-4906 events for refresh. For simple cycles, you can base state on block timestamps without external data. Chainlink
9) Which web viewer should I start with if I’m not a WebGL developer?
Try <model-viewer> first—it’s a single HTML tag with built-in controls and optional AR. As your needs grow, step up to Three.js or Babylon.js for custom shaders, physics, or multi-scene orchestration. PlayCanvas and A-Frame are strong choices for full apps and WebXR.
10) What’s the minimal end-to-end setup for a pilot drop?
Blender → export GLB; upload GLB + PNG + metadata JSON to NFT.Storage (IPFS/Filecoin) to get CIDs; deploy a minimal ERC-721 + EIP-2981 via OpenZeppelin + Remix; mint one token with image: ipfs://…/poster.png and animation_url: ipfs://…/model.glb; list on Zora or OpenSea. This path balances simplicity, durability, and standards compliance.
References
- Metadata Standards — OpenSea Docs (published) — OpenSea Developer Documentation
- ERC-721: Non-Fungible Token Standard — Ethereum Improvement Proposals — Jan 24, 2018 — Ethereum Improvement Proposals
- ERC-1155: Multi-Token Standard — Ethereum Improvement Proposals — Jun 17, 2018 — Ethereum Improvement Proposals
- Token Standards (NFT standards overview) — ethereum.org — (updated) — ethereum.org
- EIP-2981: NFT Royalty Standard — Ethereum Improvement Proposals — Sep 15, 2020 — Ethereum Improvement Proposals
- ERC-4906: Metadata Update Extension — Ethereum Improvement Proposals — Mar 13, 2022 — Ethereum Improvement Proposals
- glTF 2.0 Export (Blender Manual) — Blender Foundation — (current manual) — docs.blender.org
- GLTFLoader (Three.js) — threejs.org — (docs) — threejs.org
- glTF File Loader (Babylon.js) — Babylon.js Docs — (docs) — doc.babylonjs.com
- Progressive glTF Loading (Babylon.js) — Babylon.js Docs — (docs) — doc.babylonjs.com
- <model-viewer> Docs & AR — modelviewer.dev / Google — (docs) — and https://developers.google.com/ar/develop/webxr/modelviewer modelviewer.dev
- Unity WebGL: Getting Started & Build Output — Unity Docs — (docs) — and https://docs.unity3d.com/6000.2/Documentation/Manual/webgl-building.html Unity Documentation
- Unity SDK — thirdweb — (docs) — thirdweb docs
- Manifold Creator (ERC-721/1155) — Manifold Docs — Nov 26, (doc date) — docs.manifold.xyz
- Manifold Studio Supported File Types — Manifold Help — May 29, (doc date) — help.manifold.xyz
- Dynamic NFT Extension (Manifold) — Manifold Docs — Mar 19, (doc date) — docs.manifold.xyz
- Zora Docs — ZORA — (docs) — and Zora Network overview — OpenSea Learn — Aug 22, (article date) — https://opensea.io/learn/blockchain/what-is-the-zora-network docs.zora.co
- IPFS: Content Identifiers (CIDs) — IPFS Docs — (docs) — IPFS Docs
- NFT.Storage (current site & client SDK) — Protocol Labs — (docs) — and https://nftstorage.github.io/nft.storage/client/ nft.storage
- NFT.Storage Classic Decommission Notice — GitHub — (notice) — GitHub
- Best Practices for Storing NFT Data on IPFS — IPFS Docs — (guide) — IPFS Docs
- Arweave Lightpaper (Permanent Storage) — arweave.org — (paper) — arweave.org
- Bundlr / Irys SDK Docs — Bundlr — (docs) — and ANS-104 Bundler — AR.IO Docs — https://docs.ar.io/gateways/bundler staging.docs.bundlr.network
- OpenZeppelin Contracts & Wizard — OpenZeppelin — (docs) — and https://docs.openzeppelin.com/contracts/5.x/wizard wizard.openzeppelin.com
- Remix — Ethereum IDE — remix.ethereum.org & docs — and https://remix-ide.readthedocs.io/en/latest/create_deploy.html remix.ethereum.org
- Hardhat: Getting Started — hardhat.org — (docs) — and Ignition — https://hardhat.org/ignition/docs/getting-started Hardhat
