A few weeks ago, a collector asked me exactly how Feral File uses IPFS. I started answering her, but somewhere in the answer I realized I was explaining how our system was supposed to work when what she really needed was evidence of how it actually worked. I couldn’t point her to one public place where she could see, work by work, what her art depended on without taking our word for it.
That became status.feralfile.com. It shows every work Feral File has published and what its artwork files depend on, checked from the outside, the way a collector’s wallet or browser fetches them. For a file to count as independently available, it has to answer through public infrastructure. A response only from Feral File’s own servers does not count.
To understand what we were measuring, it helps to be precise about what a blockchain does. The internet connected computers that still belong to particular people and companies. A public blockchain makes another arrangement possible: people who do not share an administrator can share the same programs and memory. A smart contract is one of those programs. It can maintain public state, including an artwork’s identity, ownership, history, and rules, and continue operating without one company controlling the computer it runs on.
That public computer is deliberately inefficient, though, so most digital artworks do not put every byte of the work on the blockchain itself. A smart contract may hold the work’s identity and state while pointing to metadata, and that metadata may in turn identify the files the artwork needs. Some works do store more directly on chain. Others use ordinary web servers. Many use IPFS.
The important thing about IPFS is that it changes how a file is identified. A normal web address effectively says: ask this server for this file. An IPFS content address says: give me the bytes that match this address. That address can be recorded in a smart contract or in the metadata the contract points to, but the address is not the file itself, and putting a file on IPFS does not guarantee that anyone will continue holding a copy. Someone, somewhere, still has to keep the bytes.
What content addressing gives us is a way to separate the identity of a file from the server holding it. A collector, museum, artist, or Feral File can each keep a copy. If the bytes are the same, the content address is the same, and none of us has to trust the others to know whether the copy has been altered. That is why the question of what a work points to and the question of whether someone is actually keeping it available have to be checked separately.
So we checked everything: 39,967 works published through Feral File over the past five years. Of those, 17,563 have content-addressed artwork files that currently resolve through public gateways without Feral File. Another 22,214 still have published media references that depend entirely on our infrastructure. The remaining 190 fall into two smaller groups: 184 have content-addressed media with files currently failing the public gateway probes, and six depend on a third-party platform. Those are the numbers from the August 3 probe; the page carries the current ones.
I wish the 22,214 number were smaller, but publishing it before we finish fixing it is part of the point. If we waited until everything was green, this would be a brochure rather than a status page.
We started with the oldest dependency. Feral File’s first exhibitions were published on the Bitmark blockchain. When Bitmark was retired, we preserved its history by putting the chain data on IPFS, anchoring its Merkle root on Ethereum, and timestamping it on Bitcoin. The ownership record therefore has a public, independently verifiable path outside the original Bitmark network. But thousands of artwork files from those exhibitions still had published references pointing only to Feral File’s content delivery network.
We have now made a content-addressed archival copy of every Bitmark-era series: 215 series, 398 GB, with every file verified byte for byte against the original. We then recorded the archive manifest in an append-only registry on Ethereum, so the manifest we publish and the history of earlier versions also have a public record outside our own database.
That still does not mean the work is finished. The archival copies exist, but the original published references for those works still point to our servers. We are changing those references so the works resolve independently of Feral File, with November 1 as the target for that phase. The Ethereum and Tezos works whose media still depends on our CDN follow the same path.
There are also two things the status page does not yet claim to know. It checks the artwork files, but it does not yet verify whether every token’s metadata reference is itself independently available. And it does not yet test whether every work still plays exactly as the artist intended. A file resolving and a software artwork rendering correctly are different tests, so those limits are on the page too.
If you own a Feral File work, you don’t have to understand any of this architecture to find out where yours stands. Go to status.feralfile.com and paste in its token ID. You can see the work’s state file by file, and for Bitmark-era works you can also see the content address of the archival copy. There is no account and no wallet connection.
The raw data sits beside the page, along with the code that builds it. If you want to keep a content-addressed copy yourself, you can also hold the same bytes we tested with one command:
ipfs pin add <address>
I started this because a collector asked me a question I thought I knew how to answer. The useful change wasn’t that I found a better explanation. It was that the answer became something she, or anyone else, could inspect without asking us. If we make an important promise about work people have entrusted to us, and there is a way to make that promise independently checkable, I think we should. I want more of the promises we make to work this way.
> Sean
Great exploration and explanation. I have been digging into how to pin my full collection and there are no great solutions…