OpenSea, MetaMask, and ipfs:// — what NFT projects actually need to know

A question we get from NFT projects considering Octopin: "Will my tokens still show up on OpenSea? Will MetaMask render them? What if Octopin goes down?"

The short answer is yes, yes, and your tokens are still fine — because of how IPFS actually works under the hood. None of those services care which pinning provider you use. They care whether someone on the IPFS network has the bytes.

This post explains the resolution path that turns an ipfs://<cid>/<file> URI in your smart contract into a rendered image on OpenSea. Once you understand the path, infrastructure choices stop feeling load-bearing.

What "ipfs://<cid>" actually means

When your ERC-721 contract returns an ipfs:// URI from tokenURI(id), the URI has no server in it. It's pure content addressing: "the file whose SHA-256 hash equals this CID". The marketplace or wallet has to figure out where to get the bytes.

That's a deliberate design. IPFS decouples what content is from who is hosting it. Anyone who has the bytes and is online can serve them. Your pinning provider is just one of N possible sources.

The resolution path, end to end

When OpenSea loads an NFT page with an ipfs://<cid> URI, here's what actually happens:

1. OpenSea reads tokenURI from your contract via an Ethereum / Polygon / Solana RPC call. They get back something like ipfs://bafybeigid.../metadata/42.json.
2. OpenSea's server rewrites the URI to a gateway URL. They run their own IPFS gateway pool. Internally the URI becomes something like https://gateway.opensea.io/ipfs/bafybeigid.../metadata/42.json.
3. The OpenSea gateway looks up providers. It asks its connected IPFS nodes (and modern indexers like cid.contact) "who has bafybeigid...?". The answer is a list of peers + HTTPS gateways currently advertising they have the bytes.
4. OpenSea fetches the bytes from any working provider (Pinata, web3.storage, Octopin, anyone). It doesn't care which one responds first.
5. OpenSea hashes the bytes to verify they actually match the CID. If they don't, the provider gets dropped and OpenSea tries the next one. (This is why IPFS is "trustless" — you can't serve fake content under someone else's CID.)
6. OpenSea caches the result on its CDN. Subsequent visitors see it instantly. The pinning provider isn't hit again for a long time.

The whole flow takes maybe 200 ms on a cache hit, 1–3 seconds on a cache miss. Steps 3 and 4 are the only ones where your pinning provider matters at all — and only as one of several possible sources.

MetaMask, Phantom, and other wallets

Wallets work the same way with one twist: they often use a different default gateway than OpenSea, and may let you change it in settings.

• MetaMask — defaults to dweb.link (Protocol Labs' gateway). Settings → Security → IPFS gateway lets you change it. dweb.link consults IPNI; finds you if you're published there.
• Phantom — uses its own gateway pool, mostly transparent to users. Resolves ipfs:// NFT URIs out of the box.
• Magic Eden — runs gateway infrastructure similar to OpenSea. Same model: their gateway resolves CIDs from any available provider.
• Etherscan — uses a public gateway pool. Doesn't render NFT images itself but links out via gateway URLs for inspection.

None of these wallets or marketplaces have a hard dependency on a specific pinning provider. They have a dependency on the IPFS network — which has hundreds of nodes cooperating to serve content. Your pinning provider plugs into that network as one node among many.

What this means for "will Octopin going down break my NFTs?"

Octopin running an IPFS node is what gets your CIDs onto the public network. Once they're indexed on cid.contact and other peers have fetched them at least once (which happens organically as marketplaces and wallets resolve the URIs), your bytes exist in multiple places.

Here's the realistic scenario if Octopin disappeared tomorrow:

• Hot CIDs (viewed recently by marketplaces): cached on OpenSea / dweb.link / nftstorage.link / Pinata gateway pool / various peer nodes. Continue resolving for weeks while caches expire.
• Cold CIDs (not viewed in months): eventually drop out of caches. You'd need to re-pin them somewhere to keep them resolvable.
• The on-chain ipfs:// URI itself: unchanged. Repinning to Pinata or self-hosting restores resolution without any contract change.

This is the same scenario that played out with Storacha shutting down: NFTs pinned only there started failing to resolve once their cache expired at marketplace gateways. The fix is pinning to a new provider, not contract changes.

The takeaway

If your tokenURI uses ipfs://<cid> (which it should — see the next post), your pinning provider is replaceable. Pick whichever one fits your pricing and reliability needs. If it stops working, you re-pin elsewhere. The contract never changes.

The thing you should worry about is: are your CIDs registered on cid.contact (IPNI)? Are your bytes pinned somewhere durable today? Those two questions determine whether marketplaces and wallets can find your content. Brand of pinning provider is almost incidental.

Next post: why your contract should use ipfs:// URIs and never hardcode a gateway hostname.