Blog
Blog
DepthSignal did not begin with the idea that crypto needed another chart, another dashboard, or another slogan about smarter trading. It began with a narrower and more frustrating observation: the research describing useful market microstructure signals was already public, but the infrastructure required to use those signals reliably was still concentrated in teams with the time and money to build it themselves.
That distinction matters. There is a big difference between a market where the ideas are secret and a market where the ideas are public but the implementation burden is so high that only a small group can use them effectively. Crypto has increasingly looked like the second case.
Papers on order flow, market impact, liquidity fragility, and informed trading have existed for years. A serious researcher could read them, understand them, and still end up working with the same thin data surfaces everyone else was using. The blockage was not intellectual access. The blockage was the amount of engineering required before the first live question could even be asked honestly.
That is why DepthSignal exists. Not because the market lacked theory. Because the path from theory to practical use was too expensive for too many capable researchers.
The academic story was not missing. Long before crypto teams started talking more seriously about microstructure, the broader literature had already established the information content of order book events and signed flow.
Order Flow Imbalance gave researchers a disciplined way to describe directional pressure from book updates rather than relying only on lagging price summaries. Kyle's Lambda gave a direct way to think about how price responds to signed flow rather than pretending visible size alone defines liquidity. VPIN offered a way to think about toxicity and one-sided flow risk rather than treating all activity as equal. Hasbrouck's work made the same broad point repeatedly from another direction: the book and the flow contain information before the final tape compresses it.
None of that was hidden. A capable reader could find the papers, follow the logic, and understand the implications. That is one reason what is market microstructure remains such an important framing post for this whole category. The central concepts are learnable. The market does not require a secret priesthood to explain what flow, depth, and impact are doing.
The asymmetry appeared one step later. Institutional desks did not just read the literature. They built around it. They collected deeper feeds, preserved event order, normalized cross-venue schemas, and turned those ideas into stable production features. Everyone else often stopped at comprehension because the infrastructure tax was too high.
That is a structural gap, not a knowledge gap.
The most common misconception is that computing a microstructure feature is the hard part. Usually it is not. The hard part is everything that has to be true before the feature can be trusted.
A feature like OFI is simple enough to describe. But a useful live OFI feed requires reliable order book ingestion, coherent sequencing, stable symbol mapping, venue-specific normalization, and enough continuity that a short outage or schema change does not silently poison the calculation. A feature like Lambda is not hard because the regression is philosophically deep. It is hard because the signed flow input has to be trustworthy at the moment it matters.
This is where many independent teams get trapped. The first prototype works on a narrow sample, so the feature appears within reach. Then the operational layer expands. One exchange changes a WebSocket message shape. Another throttles more aggressively. A third handles reconnect state differently. The dataset grows, the storage model changes, and now the team is doing infrastructure maintenance instead of actual research.
That is not a sign of incompetence. It is the normal consequence of taking a problem that looks like feature engineering and discovering that it is really distributed systems, normalization, and monitoring in disguise.
Once that becomes clear, the market splits into two classes of participants. Teams that can afford to absorb the infrastructure tax keep going. Teams that cannot either scale the project down, move back toward simpler proxies, or disappear into a half-finished collector that never became trustworthy enough for serious use.
That was the pattern worth attacking.
The easiest bad decision would have been to build a broad "everything" platform and hope the product story assembled itself later. That category mistake happens constantly in data businesses. The product tries to be a charting tool, a research warehouse, a signal engine, a sentiment system, and a compliance layer at once. The result is often broad but vague.
That was not the right problem definition here.
The narrow problem was more useful: if smaller teams and solo researchers can already understand the microstructure concepts, what exactly stops them from using those concepts in live work? The answer kept pointing back to the same place. They were not blocked by theory. They were blocked by the time required to build and maintain the feed, normalization, and feature-computation layer before getting to strategy work.
So DepthSignal was not designed to replace strategy. It was designed to remove the most repetitive and expensive infrastructure work sitting between public research and practical use. That is a much narrower claim, and it is easier to keep honest.
It also means there are things DepthSignal explicitly is not trying to do. It is not an execution engine. It is not a recommendation system. It is not a promise that a published feature automatically becomes a profitable strategy for everyone who touches it. Those claims would be sloppy and unserious.
The product thesis is simpler: make it easier to work with normalized live microstructure context without forcing every team to rebuild the same ingestion and feature layer from scratch.
The same general microstructure ideas existed long before crypto, but crypto turned the implementation burden into a sharper problem.
Venue fragmentation is worse. Data quality is less standardized. Quoting discipline is more uneven. Historical archives are less uniform. Aggressor-side information and event semantics are not consistently exposed. Even the apparently basic question of whether one venue's flow should be trusted in isolation becomes harder because cross-venue routing and liquidity quality vary so much.
That means a crypto researcher is often solving two problems at once: the universal problem of turning order book events into useful features and the crypto-specific problem of doing it across noisier, more fragmented, less standardized venues.
This is exactly why real-time crypto microstructure data became a practical category rather than just a descriptive label. Once fragmentation and event volume reach a certain point, the infrastructure itself becomes a product layer. It is no longer a side concern.
The same logic shows up in comparisons between raw-event archives and feature-delivery systems. A replay archive can be excellent and still leave the live feature-computation burden with the buyer. A feature API can be extremely useful and still not replace event-exact historical reconstruction. The point is not that one architecture dominates every workflow. The point is that crypto magnifies the cost of choosing the wrong layer to build internally.
DepthSignal was built with that cost in mind, not with the fantasy that one product can erase all architectural tradeoffs.
Once the problem definition was clean, the design constraint followed naturally.
Could a technically capable person reach a meaningful microstructure question quickly, without first spending weeks building the plumbing?
That was the test that mattered more than any broad positioning language. If a user still had to stand up a large ingestion pipeline before seeing the first useful signal, then the product had not really solved the access problem. It had only moved the interface around.
A useful product in this space has to compress the distance between theory and use. It has to let the user spend more time asking whether the signal matters and less time proving that the collector survived last night's exchange reconnect. It has to reduce the number of hidden operations tasks that sit between a research idea and a serious experiment.
That does not eliminate all engineering. It should not. Good research still requires judgment, validation, and strategy design. But the system should remove the repetitive infrastructure layer that many teams only build because no one offered it in a usable form. That is also why crypto market data access tightening in 2026 matters: once raw access gets harder, the hidden cost of rebuilding the same ingestion layer gets worse rather than better.
This is also the reason the best question for any buyer is not "does the provider have data?" The better question is "which part of my workflow am I still forced to build myself after I buy?" If the answer is still "the whole live feature layer," then the product is not solving the same problem.
The argument for a product like this gets stronger, not weaker, as exchange data access tightens.
When public feeds were looser, a small team could at least imagine brute-forcing its way through collection and normalization at low cost. That path is getting less durable. More restrictive access, narrower depth, and higher operational overhead increase the value of a layer that already solved the ingestion and feature-computation burden.
At the same time, the strategy landscape itself has not become simpler. If anything, it has become more hostile to shallow proxies. Teams that still want to work with actual pressure, impact, liquidity, and regime-sensitive signals need a practical way to do it without paying the full infrastructure tax every time they test a new question.
That is the gap DepthSignal is built to narrow.
Not by pretending the literature was missing. Not by pretending strategy is solved. Not by pretending one API turns a weak process into a strong one. By making the part that was repeatedly rebuilt, and repeatedly underpriced, less of a private burden.
In that sense, the product origin is not romantic at all. It is a practical response to an old asymmetry. The research was public. The infrastructure was not. Making that layer more accessible is still the most honest reason for the product to exist.
Yes. The useful ideas around flow, impact, and liquidity were already in public research and widely understood by serious market microstructure readers.
Usable infrastructure. Collecting, normalizing, and continuously computing live microstructure features across venues was still too expensive for many smaller teams to build well.
No. It is trying to remove a large portion of the repetitive infrastructure burden that sits before strategy research can begin honestly.
Because many teams are not blocked by lack of raw bytes. They are blocked by the time and operational cost required to turn those bytes into stable, usable feature context.