Move Slow, Break Nothing

Speed has become a default core value of the crypto community. Fast transactions, fast launches, fast pivots. Prices that move 20% before you sit down for breakfast. The culture rewards whoever ships first, and punishes anyone who waits to verify. 

That’s fine for prices. Prices are supposed to move fast. But prices aren’t the only kinds of facts, and the data that supports real decisions requires a different pace. 

Anyone working in tech companies will have heard the project management triangle: You can have fast, cheap, or good. Choose two. Within this triangle, for data, I argue that fast is easier to build than reliable and that these two things pull in opposite directions. 

When I worked on the Open Database License, the problem we were solving wasn’t a lack of data. It was a lack of a usable, trustworthy foundation for publishing data. Data projects relied on licenses built for software, not databases, creating legal uncertainty that made sharing risky or unclear. This was a gating problem preventing adoption. 

Nobody wants to build on unstable foundations. These gating problems - fear of an unstable foundation -  is in a way what most product legal and commercial legal work is when you work as in house counsel at tech companies. Want to build a semiconductor partnership that could span a decade or more? You want certainty for the relationship and the legal foundation. Investing in building your own data center? You need that investment to pay off over the long term - you want reliability and not a decade of problems.

The solution to instability and building for the long term isn’t speed: it’s getting the structure right, so that people can rely on what’s being built. This is one of the loudest tensions showing up in Web3 today and it's more than just the underlying blockchain technology. It’s all the other forces that drive adoption. 

The Compounding Cost of Bad Data 

What happens when data moves faster than anyone can validate it? For instance, an ecosystem manager researches a project, finds fragmented and outdated information, and makes a decision based on incomplete facts. Someone else references that decision. A third party picks up the reference. Three months later, a strategy document cites the original as a source. LLMs see these bad sources and just cite them as fact. The bad data hasn’t just affected one decision: it’s accumulated, right across a chain of decisions. In academia, this compounding of bad data is caught through moving slow, peer review, and showing your work.

The cost of this isn’t immediately visible. It compounds, quietly. By the time anyone notices that the foundation is unreliable, there’s already a structure built on top. This is the unrecognised cost of fast data in Web3. It’s not just that individual facts are wrong. But wrong facts compound into flawed maps of the ecosystem, and flawed maps drive flawed decisions at scale. 

What Slowing Down Means

Slow data isn’t a criticism of ambition. It’s a methodology. 

At The Grid, we use the ‘Four Eyes’ principle for every data point we publish. An LLM assists with initial data cleaning, and a human reviewer confirms the result. We have double validated over 3,000 Web3 profiles and 6,300 products this way. 

This whole process takes a lot longer than having AI scrape the internet and calling it a day. But the internet, scraped raw, is not a source of truth. It’s the source of the occasional signal within a sea of noise. Finding those signals takes work, and good work takes time. 

This distinction matters far more now than it did two years ago. AI systems ingest web content at scale, and picks up errors, outdated facts, and biases, alongside accurate information. Once this happens, bad data isn’t sitting inertly in a database anymore. AI systems are processing, citing, and redistributing it at machine-speed. If we apply Metcalfe’s Law, then the downstream consequences of starting with unreliable data are arguably growing faster than the data itself. 

Why the Ecosystem Needs This Now 

The experimentation phase of Web3 is beginning to wind down, and the integration phase is beginning. Real institutions are allocating real capital. Regulators are asking real questions. Builders are making long-term infrastructure decisions. 

All of this requires reliable data. Not fast information: reliable information. 

The ecosystem has excellent on-chain data. Block explorers, analytics platforms, and transaction records tell you what happened on a given blockchain with precision and speed. What this data doesn’t tell you, is who built what you’re looking at, what products it supports, which ecosystems it operates in, or whether the team behind it even still exists. 

This off-chain context is what makes on-chain data actionable. And this is the part that requires time: for collection, verification, and maintenance. 

Move Slow and Break Nothing  

Moving fast and breaking things might work for introducing product features. It’s a poor approach to the information layer that ecosystem participants depend on to make decisions. A broken feature can get patched. But a broken information layer erodes trust, until people stop relying on it at all. 

This isn’t an argument against speed. This is a case for applying the right standard to the right problem. Prices need to move fast. Liquidity needs to move fast. Code can ship fast (and teams can later patch it). But the data layer that tells you what exists in this ecosystem, who built it, and whether it’s still active? This needs to be right, before it can afford speed.

And because this data is so critical, we’ve committed to an open data core using the ODbL (the same license behind OpenStreetMap), and have our open data available via our API for everyone to use. 

At The Grid, we’re building the infrastructure that the next phase of Web3 depends on. It’s not a sprint. It’s more like the Tour de France - multistage, multiday. Endurance over the long term.

To read more about our ethos of why this data is important to us, see Hold Your Horses: Deliberate Data In A Fast-Paced World by our Co-Founder/CEO Jonathan Knegtel.