EN ES FR IT RU UC PT DE JA KO CH FA HI AR
Decentralized archive · 2026

How to back up your NFTs before Foundation shuts down

A step-by-step guide so your work doesn't vanish with the marketplace. The blockchain remembers, but the files need someone to hold them.

By Ernesto Cisneros Cino · Composer, crypto artist, founder of Impulses.art · April 2026

Foundation is closing. The tokens will remain on the blockchain forever, but the files that make them up (images, videos, metadata) live on IPFS, pinned by Foundation's nodes that will eventually go offline. When that happens, the links will stop resolving and the artworks will become visually orphaned tokens, even though everything on-chain will still be there.

This guide walks you through backing up your entire corpus on an independent, decentralized pinning service, without paying a cent. By the end, your work will be protected by infrastructure you control, not by a company that can shut down tomorrow.

It takes between 30 minutes and 2 hours depending on how many pieces you have. Every minute is worth it.

Step 01

What you'll do exactly

Understanding the problem and the solution before starting will save you confusion later.

The problem

When you minted a piece on Foundation, the smart contract stored a reference on Ethereum (a CID, Content Identifier) pointing to your JSON metadata file on IPFS. That JSON holds the title, description, and in turn points with another CID to the actual image or video file.

The token is permanent. But CID files only exist while some IPFS node keeps them pinned. Foundation had them pinned on its own nodes. When they turn those nodes off, if no one else is pinning those files, they vanish from the network.

The solution

You'll pin the same CIDs on your own node (actually, on a free service acting as your node). This isn't copying the files somewhere else, it's reinforcing their existence within the same IPFS network. The CID stays the same, the piece stays the same, but now it has redundancy: it lives on Foundation's nodes and on yours.

When Foundation shuts down its nodes, yours remain active. The IPFS links keep working. Your work survives the closing of the marketplace.

Important

The Ethereum token (your ownership, history, sales) is never at risk. What's at risk is the visual and descriptive layer. This backs up that layer.

Step 02

Why Filebase and not Pinata

Pinata was a pioneer but its free tier no longer works for this specific case. Filebase is the honest alternative.

Pinata charges for the exact feature we need (Import from IPFS, pinning existing CIDs). On the free tier you can only upload new files from your computer, not pin CIDs that already exist on the network.

Filebase offers 5 GB of storage, up to 1,000 files, a dedicated gateway, and the Import CID feature, all included in the free tier without a credit card. That's five times more space than Pinata, and the key function is unrestricted.

Filebase also uses 3x redundancy across geographically distinct locations, which is real redundancy, not marketing language.

A philosophical note

Pinata isn't a bad service. It's that your case (pinning already minted work) is exactly what their current business model pushes to paid plans. Filebase treats that case as legitimate free usage.

Step 03

Create your free Filebase account

Five minutes, no credit card.

  1. Go to filebase.com and click Get Started Free or Sign Up.
  2. Enter your email and create a strong password. No card required, no billing info.
  3. Confirm your email via the link they send.
  4. Log in to the dashboard with your username and password.

You'll see your empty workspace. The interface is clean, English-only, but the flow is simple.

Go to Filebase →

Step 04

Create your archive bucket

A bucket is like a folder where your pins will live.

  1. In the dashboard, click Buckets in the side navigation.
  2. Click Create Bucket.
  3. Give it a unique name, for example your-name-nft-archive. Bucket names are global, so if yours is taken you'll need another.
  4. Under Network, select IPFS. Don't pick Sia or any other network, you need IPFS for your Foundation NFTs.
  5. Confirm with Create.
About S3 Private vs Public

Filebase will show you a notice saying public buckets require a paid plan. Ignore it, keep it on S3 Private. That notice refers to S3 access (Amazon's protocol), which isn't used by NFTs. Your files will still be publicly accessible by CID from any IPFS gateway: ipfs.io, dweb.link, cloudflare-ipfs.com. The private bucket setting doesn't restrict that.

Step 05

Get the CIDs for each piece

Each piece has two CIDs you need to identify: one for the JSON metadata, another for the image or video file.

Method 1: From Foundation (while it's still up)

  1. Go to your Foundation profile and open one of your pieces.
  2. Under the Details or Token Details tab you'll find an IPFS or Metadata link.
  3. It looks like https://ipfs.io/ipfs/QmXX.../metadata.json. Save it.
  4. The metadata CID is the part between /ipfs/ and /metadata.json: QmXX...

Method 2: Open the JSON and pull the media CID

Open the JSON in your browser. You'll see something like this:

JSON metadata { "name": "Your piece", "description": "...", "image": "ipfs://QmYY.../nft.mp4" }

The image field value (or sometimes animation_url) starts with ipfs:// followed by another CID. That's the media CID. Save it as well.

Build a simple inventory table

For each piece, record:

A simple spreadsheet is enough. Do this while Foundation is still accessible. If you wait, pulling the data out could be significantly harder later.

Tip

If you have an easy-to-copy inventory on your Foundation profile, grab it in bulk. You can also look up your tokens directly on Etherscan by searching your wallet and filtering for NFTs.

Step 06

Pin your CIDs on Filebase

This is where the magic happens. Filebase finds your files on the IPFS network and copies them onto its nodes.

Process for each piece

  1. Open the bucket you created by clicking its name.
  2. You'll see three options: Import CID, New Folder, Upload. Click Import CID.
  3. A form opens. Paste the metadata JSON CID for the first piece.
  4. Give it a descriptive name, for example my-piece-metadata.json.
  5. Confirm with Search and Pin.

Filebase will look up the CID on the IPFS network (this takes a few seconds) and pin it on its nodes. The status will go from Pinning (in progress, orange icon) to Pinned (confirmed, green icon).

Repeat for the media file CID:

  1. Import CID again.
  2. Paste the video or image CID.
  3. Name: my-piece-media.mp4 (or the correct extension).
  4. Confirm.

Recommended naming convention

Use consistent names so your bucket is easy to browse later. Suggestion:

Names should be lowercase, with hyphens instead of spaces, no accents or special characters. This avoids problems with URLs and filesystems.

Estimated time

Each pin takes from a few seconds (for small JSONs) to a couple of minutes (for heavy videos). For a corpus of 10-15 pieces, plan on 40 minutes to 1 hour of manual work.

Nice detail

If you pin a CID that Filebase already has pinned elsewhere (because another artist pinned the same file), it pins almost instantly. IPFS doesn't duplicate files, it reinforces their presence.

Step 07

Verify everything worked

Before calling the backup done, verify the files are actually accessible from the public network.

Check 1: Everything marked Pinned

Look at the Status column in your bucket. All files should have a green icon and Pinned label. If any is still Pinning (orange) after several minutes, wait longer or refresh.

Check 2: Accessible from a public gateway

Copy one of your CIDs and paste it into this URL, replacing [CID]:

Test CID https://dweb.link/ipfs/[CID]

If you can see the content (the JSON or the video), your pin is live on the decentralized network, accessible from any gateway, without needing Foundation or Filebase.

Check 3: Reasonable storage use

Look at your bucket's Storage indicator. A typical NFT video weighs between 10 and 80 MB. If you have 15 pieces with video, you'll be around 500-800 MB. Far from the 5 GB free tier limit.

If you're close to the limit (because you have more pieces or very heavy videos), consider pinning only metadata for less critical pieces and leaving their videos without extra backup (they'll still live on other public IPFS nodes for a while).

Step 08

Update the links on your website

If you have a personal website or portfolio linking to your NFTs, those links need to change. The ones pointing at Foundation will die.

What to replace

Look for links on your site like these:

https://foundation.app/mint/eth/0x...../tokenID https://fnd-collections.mypinata.cloud/ipfs/QmXX.../metadata.json https://fnd-collections4.mypinata.cloud/ipfs/...

All of those will stop working. They should be replaced with stable IPFS gateway links.

Which links to use

I recommend three kinds of link per piece:

1. Metadata (technical record of the piece):

https://dweb.link/ipfs/[METADATA_CID]/metadata.json

2. Media (the video or image):

https://dweb.link/ipfs/[MEDIA_CID]/nft.mp4

3. Etherscan (on-chain ownership verification):

https://etherscan.io/token/[CONTRACT]?a=[TOKEN_ID]

This third link replaces the Foundation link. Where you used to point at the marketplace, you now point at the public Ethereum registry, which never shuts down.

About gateways

I use dweb.link because it's run by Protocol Labs (foundation, not a for-profit company), relatively fast, and neutral. Valid alternatives: ipfs.io (same provider, sometimes slower), cloudflare-ipfs.com (fast but depends on a centralized company). Any of them works; the CID is what matters.

Step 09

If your pieces are on Arweave (no backup needed)

Some Foundation pieces use Arweave instead of IPFS. They have built-in permanence.

If when you open your piece's metadata you see URLs ending in arweave.net or starting with a hash followed by .arweave.net, your piece lives on Arweave, not IPFS.

Arweave is a different decentralized storage network, with a philosophically different model: you pay once at mint time, and storage is guaranteed for two hundred years via an endowment fund that keeps paying nodes indefinitely.

Practical conclusion: if one of your pieces is on Arweave, no need to back it up. Its permanence is structural. Just note it in your inventory and move on to the others.

Step 10

Before Foundation shuts down completely

Final actions before lights out.

Delist unsold pieces

If you have pieces listed for sale on Foundation that still don't have a buyer, consider delisting them before the shutdown. This releases the token from Foundation's escrow contract and returns it to your wallet (or the minter's). Costs a bit of gas but saves complications later.

Document collaborators

If you have pieces with on-chain split, remind your collaborators to do this backup from their side as well. The split stays active while the contract exists, but the files need multiple nodes backing them to survive.

Export curatorial information

Foundation holds information that doesn't live on-chain: sales history with collector names, editorial descriptions, exact auction dates, bids, followers. All of that disappears when Foundation does. Screenshot or export whatever you can before the shutdown.

Tell your story

If you've been in the crypto art space for years, you're a witness to a chapter of cultural history few lived from the inside. Write down what you remember. Event photos, community names, platforms that fell, bans that hit artists from embargoed countries. That narrative archive matters as much as the CIDs.

When you're done

Once you've pinned every piece, verified public access, and updated your website links, your corpus will survive Foundation's closing. The work remains. The story continues.

Step 11

What if Filebase itself shuts down one day?

Fair question. If you're backing up to avoid depending on Foundation, aren't you just moving the dependency to another company? Worth answering honestly.

The short answer

If Filebase shut down tomorrow, your files wouldn't disappear instantly. IPFS works by accumulation of nodes that replicate the same content, not through a single point of failure. Closing Filebase only removes one of the copies of your file, not all of them.

More importantly, CIDs are universal. They don't belong to Filebase. If tomorrow you open an account with another provider and paste the same CIDs, you have active backup again within minutes. Your inventory (the spreadsheet from Step 05) is everything you need to migrate.

How IPFS persistence actually works

A file on IPFS exists as long as at least one node keeps it actively pinned. When Filebase pins your CIDs, its nodes (typically replicated 3x across distinct locations) keep the file live.

But Filebase isn't the only one holding your files. Every time someone visits an IPFS gateway and loads your piece, that gateway caches it temporarily. Every interaction leaves ephemeral copies. Foundation still has your CIDs pinned until they close. The network has a natural replication inertia.

Three possible scenarios if Filebase shut down

Scenario 1, shutdown with prior notice (the expected case): serious services announce closures weeks or months in advance. You'd have plenty of time to migrate to another provider: 4EVERLAND, Web3.Storage, Lighthouse. Since you already have your CID inventory, migration is trivial: open an account, import the same CIDs, and continue.

Scenario 2, abrupt shutdown without notice: unlikely but possible. Your files would only disappear if simultaneously no other node has them. For files with any activity, this is statistically rare.

Scenario 3, acquisition by another company (the most common): a larger company buys the smaller one and keeps the service running with new terms. Your pins stay active through the transition. Recent ecosystem example: KnownOrigin was acquired by eBay, with serious consequences, but previously minted files remained accessible.

The robust strategy: multi-provider redundancy

The philosophically correct answer isn't just trusting that Filebase won't shut down, but not depending exclusively on Filebase. Real decentralization requires real redundancy. Four levels of protection, implementable gradually:

Level 1, what you already have: active pins on Filebase. 5 GB free. Covers the standard case.

Level 2, parallel redundancy: open a second free account with another provider and replicate the same pins. Solid options:

With the same CIDs pinned on two distinct providers, one closing doesn't affect the other. That's precisely what decentralization enables: not being tied to any particular provider.

Level 3, local physical copy: download all media files to your hard drive or external disk, organized by folder. Doesn't serve public links, but guarantees that if every node in the world fails, you still hold the masters. This is the archivist's last-resort backup.

Level 4, optional and advanced: run your own IPFS node with IPFS Desktop or IPFS CLI on one of your machines. Maximum technical autonomy. Your node is only active when your computer is, so it complements rather than replaces managed services.

Pragmatic recommendation

For now, stick with just Filebase (Level 1). It's enough for real short-term risk. Filebase has been operating since 2019 and appears institutionally more stable than others right now.

In 3 to 6 months, if you want to reinforce, open an account with 4EVERLAND or Web3.Storage and replicate the pins. 15 minutes of work, because you already have the inventory with every CID. That gives you real redundancy without over-engineering.

The local hard drive copy you can do whenever you have time, no rush but worth doing. Your own IPFS node only if you enjoy managing infrastructure.

A philosophical note

There's a critical difference between centralization and dependency. Filebase is a centralized provider (private company, their own servers), but your use of Filebase is decoupable: CIDs are standard IPFS, your inventory lives on your disk, and you can move to another provider anytime. Very different from how you depended on Foundation, where Foundation closing meant losing the links, the narrative, the profile, and the community. This time, any shutdown would be annoying but not catastrophic. That's real progress.

FAQ

Frequently asked questions

Short, direct answers to what artists are asking right now about the Foundation shutdown and NFT preservation.

What happens to my NFTs when Foundation shuts down?

The tokens stay on Ethereum forever, untouched. What's at risk is the off-chain layer: the metadata JSON and the media files (images, videos) that currently live on Foundation's IPFS nodes. When those nodes go offline, files may become inaccessible unless you pin them on another service. Your ownership is safe; the visual representation needs backup.

Do I need to move my NFTs to another blockchain?

No. NFTs stay on Ethereum regardless of Foundation's fate. Foundation is a marketplace interface; Ethereum is the underlying blockchain. You only need to back up the off-chain files, not move tokens.

Is Filebase really free for NFT backup?

Yes. 5 GB storage, up to 1,000 pinned files, dedicated IPFS gateway, and the Import CID function, all free without a credit card. This is the feature combination Pinata moved to paid plans.

What is an IPFS CID and why does it matter?

A CID (Content Identifier) is a cryptographic hash that uniquely identifies a file on IPFS by its content. Your NFT's smart contract stores a reference to a CID pointing to metadata, which points to the media CID. CIDs only resolve to content while nodes have the files pinned. No pins, no content, regardless of the token's existence.

What if Filebase itself shuts down?

Covered in detail in Step 11 above. Short version: CIDs are universal, so you can migrate to another IPFS provider (4EVERLAND, Web3.Storage, Lighthouse) in minutes using your inventory. For robustness, use multi-provider redundancy.

Should I delist unsold NFTs before Foundation closes?

Recommended. Delisting releases the token from Foundation's escrow contract back to the minter's wallet, freeing it for future relisting elsewhere. Costs a bit of gas but prevents complications.

How long does the full backup process take?

For 10-15 NFTs, plan on 30 minutes to 2 hours. JSON metadata pins in seconds; video files may take a couple of minutes each. The process is repetitive but not complex once the CID inventory is ready.

What if my NFTs are on Arweave, not IPFS?

No backup needed. Arweave provides permanent storage by design: paid once at mint, preserved for approximately 200 years via an economic endowment that pays nodes indefinitely.

Does this guide work for artists outside Foundation?

Yes. The same process applies to any NFT on Ethereum whose metadata and media live on IPFS. SuperRare, Zora, Objkt, KnownOrigin (pre-shutdown), Rarible: the workflow is identical. Only the source of the CIDs differs.

Can I pin someone else's NFTs as a collector?

Yes, and it's encouraged. CIDs are public by design. Pinning NFTs you collected protects your collection from the failure of original nodes. Consider notifying the artist as a courtesy, especially if you have direct contact.

Technical extension

How to run your own IPFS node

This section is for artists with some technical comfort who want the next level of autonomy. It's not necessary to back up your work (Filebase is enough), but if the idea of not depending on any provider appeals to you, here's the path.

What running your own node means

An IPFS node is a computer that participates in the network as one more member of the swarm. When you install the software, your machine can pin files, serve them to the world, and keep them alive without depending on any commercial service. You move from being a client of a provider to being a full participant of the network. The digital equivalent of owning your own printing press instead of depending on a publishing house.

Key difference with Filebase: with Filebase you ask a company to pin your files on their servers. With your own node, you are the server.

Important trade-off

Your node only serves files while your computer is powered on and connected to the internet. If you shut the machine down, your files still exist on other network nodes (Filebase, public gateways, other pinning services), but you stop contributing. For real permanent backup, your node needs to be active most of the time.

Two real paths, depending on how much control you want

Path A: IPFS Desktop (the most accessible)

Graphical application you install like any other program on macOS, Windows, or Linux. Setup in 5 minutes, visual interface, no command line required. Ideal for experimenting and learning.

Pros: simple installation, visual interface, you can close the app when you don't need it.
Cons: consumes RAM while running (200-400 MB), depends on not accidentally closing the app, and when you shut the computer down you lose availability.

Path B: Dedicated Raspberry Pi (the serious option)

Buy a Raspberry Pi (around 75-120 USD with case, power supply, and SD card), install IPFS on it, and leave it on 24/7 at home connected to your router. Dedicated permanent node with electrical consumption of an LED bulb (5-10 watts, about 2-3 USD monthly).

Pros: real permanent node, doesn't consume resources from your main computer, full technical autonomy.
Cons: requires initial purchase, more complex technical installation (command line), router configuration for external accessibility.

Recommendation

Start with IPFS Desktop. Learn the concept without economic commitment. If after a few weeks you feel you actually use it and want real permanence, then evaluate investing in a dedicated Raspberry Pi.

Step by step with IPFS Desktop

Step 1: Download the installer

Go to ipfs.tech/install/ipfs-desktop/ (official project domain). Choose your operating system installer: macOS, Windows, or Linux.

Step 2: Install

On macOS, open the .dmg and drag the icon to Applications. On Windows, run the .exe. On Linux, generally an .AppImage. On macOS the first time, the system may warn about an unverified developer: go to System Preferences → Security and grant manual permission. Normal, doesn't imply the software is insecure.

Step 3: First run

When you open the application for the first time, it does three things automatically. First, it creates a unique cryptographic identity for your node (like a permanent ID for your node on the network). Second, it connects to the global IPFS network and in a few seconds you'll see dozens or hundreds of connected peers (other nodes). Third, it opens an interface with five tabs: Status, Files, Explore, Peers, Settings.

Step 4: Pin your first CID

Go to the Files tab. At the top there's an Import button. When you click it, a menu unfolds with options. Choose From IPFS (sometimes shown as Add by CID or Import from IPFS). Paste one of your CIDs and confirm.

Your node will start downloading the file from other nodes that have it (Filebase, public gateways, any active source). In seconds or minutes (depending on size) the file is pinned locally. At that moment your computer is one of the bees that sustains that CID.

Step 5: Verify it works

Two simple checks. First, in Files you should see the CID with a pin icon and the downloaded size. Second, open in your browser:

Local gateway http://localhost:8080/ipfs/[your-CID]

That localhost:8080 is the local gateway your own node raises. If you see the content, your node is actively serving the file. That's real technical autonomy.

Step 6: Pin the rest of your corpus

Repeat the process with every CID in your inventory. For a 10-15 piece corpus, plan on 30 minutes to 2 hours depending on your connection.

Practical considerations for daily use

Resource consumption: IPFS Desktop uses between 200-400 MB of RAM when active. Not a problem on modern computers, but noticeable on machines with little memory. You can configure limits in Settings.

Bandwidth: your node doesn't only download, it also uploads to other nodes requesting files. If you have limited connection, configure limits in Settings. With normal home connection you won't notice.

Shutting down the computer: your CIDs stay alive on the network as long as other nodes have them pinned (Filebase remains backup). Your node simply stops contributing temporarily. When you turn on again, it resumes automatically.

Disk space: each pinned CID occupies its size on your local disk. Calculate: for 500 MB of Foundation corpus, your node occupies 500 MB. For large Tezos corpora it can be several GB. Check your disk has space.

What this concretely gives you

The natural evolution toward Raspberry Pi

If after experimenting with IPFS Desktop you feel you want real permanence, the natural path is:

  1. Buy a Raspberry Pi 4 (4 or 8 GB of RAM) with power supply, case, and 128 GB microSD card. Total approximately 100-150 USD.
  2. Connect it to your router via ethernet cable in a corner of your home.
  3. Install IPFS following Raspberry Pi specific tutorials (abundant in English, some in Spanish).
  4. Configure automatic restart for power outages to keep the node always active.
  5. Advanced optional: configure your own subdomain (for example ipfs.yourname.art) pointing to your Raspberry to have your own gateway.

That last step, your own gateway with your own domain, is maximum sovereignty. You no longer depend even on dweb.link or ipfs.io. The links on your website will be yours: ipfs.yourname.art/ipfs/[CID]/file.mp4.

To be clear

Having your own node doesn't replace Filebase or make obsolete the work you already did. It complements it. The ideal strategy combines: Filebase as always-active managed backup + IPFS Desktop or Raspberry Pi as your own node reinforcing from your own infrastructure + local hard drive copy as last-resort archive. Three redundant layers, each protected by different design.

❦ ❦ ❦

Need help?

If you have specific questions, reaching out directly is fastest. Several of us in the community are doing this work these weeks, and the sooner you back up, the better.

ernestocisneros.art →