Categories: Blockchain Article

Selling Free Data on a Blockchain Is Not About Storage

Data on Chain — Part 1 of 3 · ChainLab

Here is a tempting idea. Public data like real estate transaction prices is free and open. What if you wrapped it, put it on a blockchain, and sold access? The pitch writes itself: “verifiable, tamper-proof property data on-chain.”

The idea is worth pursuing, but almost everyone starts by asking the wrong question. They ask how much does it cost to store and update the data on-chain? The better question is what do you put on-chain at all? — because the answer to the first question swings by a factor of a hundred depending on the second.

Putting the data itself on-chain is a non-starter

National real estate filings accumulate thousands of records per day. Writing each record to storage costs roughly 20,000 gas per slot. A single day’s batch runs into the millions of gas. On Ethereum L1, one update cycle could cost hundreds of dollars — enough to eat your entire margin on a data product. So in practice you do not store the data on-chain at all. The data lives off-chain; the blockchain handles only access control and integrity proof.

Three realistic models

The access-gate model is the cheapest and most common. Data is served the normal way, through an API or database. The blockchain only tracks who has the right to read it — an NFT, an ERC-1155 ticket, or a time-based subscription contract. Updating the data itself costs essentially nothing; you just write to your off-chain database. On-chain transactions happen only when access rights change.

The hash-anchoring model adds verifiability. You keep the data off-chain (IPFS, Arweave, a database) but build a Merkle tree from each day’s dataset and write only the root on-chain. Buyers receive the data plus a Merkle proof and check it against the on-chain root. This is where “wrapping free data” starts to create real value: anyone can pull the same free source, but the proof that a dataset was fixed at a given moment and has not been altered since requires that anchored root.

The oracle model is for a narrower case — when the buyer is not a person but another smart contract that needs a processed figure, like a per-complex price index. That deserves its own discussion, and it gets one in Part 2.

The update cost, honestly

The whole point of the hash-anchoring pattern is that your update cost collapses to one transaction per update cycle, regardless of how many records changed. Whether one record moved or ten thousand did, you rebuild the tree and write a single new root — a storage write of roughly 40,000 gas including the base transaction.

  • On Ethereum L1, that is on the order of a dollar or a few, depending on gas prices.
  • On an L2 such as Base, Arbitrum, or Polygon, it is typically under a cent.

For a data-anchoring product the choice is obvious: run on an L2, batch daily, and your monthly on-chain cost stays in the range of pocket change. (Exact figures track gas and token prices, so confirm before you ship.)

Do not store. Batch and anchor. An update is one root write, not ten thousand record writes.

The catch nobody mentions

Two things quietly decide whether this business even works, and neither is technical.

First, licensing. Korean public real estate data carries a KOGL (공공누리) license type. If it is Type 1 (attribution only), commercial resale and derivative works are permitted with a source credit. But if it is Type 2 or Type 4, paid resale is blocked outright. Check the license on the specific dataset before you build anything.

Second, and more important: wrapping free data in a blockchain does not, by itself, create defensible value. Anyone can call the same free API. So the paid product needs genuine value on top — cleaning, normalization, index construction, anomaly filtering, real-time delivery, or verifiable provenance. The one thing a blockchain uniquely contributes is verifiable integrity plus programmable access: the ability to prove that a figure was fixed at a certain point and has not been tampered with. That is the thing someone might actually pay for. Everything else you could do with a normal server.

The thesis

Strip away the hype and the architecture points in one direction. You are not selling storage, and you are not really selling the data — the data is free. You are selling verifiability and access. The blockchain’s job is to turn a free, easily copied dataset into something whose integrity a third party can check without trusting you.

That reframing is the whole series. Part 2 looks at what changes when the consumer is a contract instead of a human. Part 3 asks the deeper question: when is “I cannot alter this” worth paying for?

Recent Posts

What a Blockchain Actually Sells: “I Can’t Alter This”

Data on Chain — Part 3 of 3 · ChainLab The first two parts were…

2 months ago

When Your Data Consumer Is a Smart Contract

Data on Chain — Part 2 of 3 · ChainLab In Part 1 we settled…

2 months ago

Why Not in Korea Yet? — The Regulation Story, Made Simple (5/5)

Korea's tech is world-class, so why isn't AI payment running smoothly here yet? The answer…

2 months ago

Escrow — A Vault That Holds Money Safely, and Why It’s Tricky (4/5)

You've probably used "safe payment" on a secondhand marketplace. AI payments need this too. The…

2 months ago

AP2 & MPP — “Ask-Permission-First” Payments vs. “Run-a-Tab” Payments (3/5)

If last part's x402 was a vending machine, these two approaches are closer to a…

2 months ago

x402 — The Simplest Way for a Web Page to Charge a Fee (2/5)

Put a coin in a vending machine, out comes a drink. x402 recreates that exact…

2 months ago