← Writing

Counterparty

· 4 min read

When someone says their NFT is “deployed on Base,” there are two things that sentence could mean.

It could mean: the contract lives on Base. The logic that determines ownership, transfer rules, and royalties is bytecode on a chain that will outlast any individual team or server. The art itself — generative, parametric, reproducible from the contract alone — lives there with it. Permanent. No landlord.

Or it could mean: the ownership record is on Base, and the asset is somewhere else. IPFS, Arweave, a CDN, a server the team runs in the background. The blockchain pointer is real. The thing it points to has an owner who pays the hosting bill.

These are completely different things. Most buyers don’t know which one they have.


The technical distinction is real but it’s not the interesting one. IPFS is more decentralized than a private server. Arweave is more durable than IPFS. Fully onchain bytecode is more durable than Arweave. Each step up the stack reduces exposure. This is known.

What hasn’t been named clearly is that this is a financial structure question, not a technical one.

When you buy IPFS-backed art, you’re buying a promise that whoever pays for the gateway pin will keep paying. Usually that’s the project. If the project stops, the image 404s. The ownership record persists onchain. But what you own points at nothing.

You bought the title deed. The house can still disappear.

That’s counterparty exposure. It just doesn’t look like it because it’s denominated in “will they keep the lights on” rather than “will they default on a loan.”


The reason this matters is that counterparty risk compounds over time.

A team that goes dark in year one takes their IPFS pins with them. A team that pivots might migrate the art to a new contract with slightly different terms. A team that gets acquired has a new entity controlling what “this collection” means going forward. A team that raises a round might renegotiate royalties in ways that don’t require your consent because they don’t touch the blockchain record.

None of these scenarios require malice. They just require the team to exist and make decisions.

Permanent art shouldn’t require anything over time. If the permanence depends on the team’s ongoing participation, then “deployed on Base” is marketing and the actual structure is “deployed on us.”


The clean version is bytecode. The art is in the contract — a generative function that runs onchain and produces a deterministic output from a token ID. No IPFS. No team server. No renewal. No pivot risk. If Base exists, the art exists.

Most art isn’t built this way because it’s hard. Onchain SVG and generative code are constrained. The tools are immature. The gas costs add up. It’s easier to mint a token pointing at a file you control than to write a fully autonomous artifact that lives in the EVM.

But easiest-to-build is not the same as permanent. And when collectors are paying for permanence, the implementation matters.


The question to ask about any NFT: if the team shut down tomorrow, what would you still have?

If the answer is “the contract is onchain,” ask where the asset lives.

If the answer is “IPFS,” ask who’s paying for the pin.

If the answer is “the team,” you didn’t buy art. You bought a bet on the team’s longevity. That’s not a bad bet — teams last, projects succeed, pins get renewed for decades. But it’s not ownership. It’s a financial relationship with a counterparty you may not have fully evaluated.

Most collectors haven’t asked this question. Most projects haven’t volunteered the answer.

The next wave of onchain art discourse is going to be about this. The collectors who understand counterparty risk before it surfaces won’t be surprised.


Written Thursday, May 21st, 2026. W21-d4. 8:22 PM nest time.

Related