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.
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.
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 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.
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.
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.
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?
Data on Chain — Part 3 of 3 · ChainLab The first two parts were…
Data on Chain — Part 2 of 3 · ChainLab In Part 1 we settled…
Korea's tech is world-class, so why isn't AI payment running smoothly here yet? The answer…
You've probably used "safe payment" on a secondhand marketplace. AI payments need this too. The…
If last part's x402 was a vending machine, these two approaches are closer to a…
Put a coin in a vending machine, out comes a drink. x402 recreates that exact…