Somewhere right now, an institution is getting ready to launch its first crypto product. Not a pilot. A product with customer money behind it, a userbase counting on it, and the institution's name on the line. Everything has been organized around the launch. Months of engineering, legal review, and security audits, all aimed at a single milestone.
Then the product goes live. Customers show up with capital. And only now does the harder question come into focus: what happens next?
Day one is getting to mainnet. Day two is everything after: running a live product, with customer funds moving through it, on a system you don’t fully control. Day one absorbs almost all of the attention. People rush to mainnet, and once they're there, they exhale. But day two is where the operating actually happens. It's also where the next decade of crypto gets decided.
The map is not the territory
Almost a hundred years ago, Alfred Korzybski wrote a line that every blockchain product should live by: the map is not the territory.
The smart contract is the map. It is a precise, verifiable representation of how a system is supposed to behave. You can read it, audit it, formally verify it, fuzz it, test it against every edge case you can think of.
Then it goes live, and the live system becomes the territory. That same contract now runs against oracles and infrastructure it doesn't own, sits open to protocols it never integrated with, and moves with market conditions nobody scripted. It carries dependencies that the original code never accounted for. The map can be perfect. Yet the territory is messy, adversarial, and always changing.
Code is perfect. Systems are not.
The industry has spent enormous energy on the static - audits, formal verifications, fuzzing, bug bounties, security reviews. That work is critical and will remain so. But a deployed protocol is roughly half code and half the data flowing through it. The code is verifiable, but the flow is living and almost infinitely variable.
The most sophisticated crypto projects have spent years learning to account for the unpredictability of a live system, because at any meaningful scale of capital, the alternative is unacceptable. What changes now is the scale itself. The capital moving onchain over the next several years will be a different order of magnitude than the system has processed before, with a different class of operators behind it. Operational excellence in that environment is not optional, it is the prerequisite for the next phase.
A contract on its own can be audited and verified. An onchain action can be tested and observed. But a live system is different: it is those same contracts and actions exposed to every infrastructure, capital, governance, and counterparty scenario that can plausibly occur onchain, many of which cannot be anticipated in advance. This is simply a structural property of complex systems, and it is the job of operations to bridge the gap.
Operations is the next frontier
For most of the industry’s history, crypto's relationship to operations has been unusual. The bulk of the work has been proving that the technology can function at all. Convincing capital to use it was secondary. Operational practices slowly emerged from individual protocols, often as a competitive moat, but they rarely developed as a shared discipline. In any other industry, operations have always been intentionally put in place to enable systems to work.
Every decision in operations is a decision about risk. Dig deeper, and you’ll find operations is, at its core, risk mitigation. The good news for institutions arriving onchain is that their taxonomy of risk maps closely to crypto's. The hard part is inheriting it within a system with operating properties different from any they have run before. It is open, public, final, and composable. The product you launch is visible to anyone who cares to look, can be interacted with by anyone, settles irreversibly, and operates in active conversation with systems you do not own.
These properties are not flaws. They are the source of crypto's advantage. But they create externalities and dependencies that institutional risk frameworks were not built to address. The categories of risk that those frameworks already manage still apply. They just behave differently.
The four risks
- Code risk. In traditional finance, software runs behind APIs. Bugs hide there; security is partly a matter of obfuscation. Onchain, there is no obfuscation behind APIs. Every assumption is readable to an audience that includes adversaries, and they will seek to find anything you did not make explicit. The code has to work perfectly in order to survive day one, and then it has to keep working, with the same finality, every day after.
- Market risk. The category of risk that every financial institution knows: price moves, volatility, liquidity, correlation. Onchain, it shows up faster and with fewer circuit breakers. Pools drain in a block. Liquidations cascade through interconnected positions inside a single transaction. The speed is unforgiving.
- Process risk. What traditional finance today calls operational risk: keys, multisigs, governance, parameter updates, off-chain integrations, and especially the people responsible. A growing share of large incidents are not code exploits at all; they are operational exploits. Fat-finger errors and stale signers. Parameter changes that went out without anyone modeling the second-order effects. Worst of all, there is rarely an undo button in crypto.
- Dependency risk. Each protocol you integrate with is a counterparty. You need to know which ones you have, what their failure modes look like, and what your blast radius is when one of them fails. The difference onchain is that the dependency graph is denser, less obvious, and updated more frequently than its traditional counterpart. Cascading failures from a single protocol can move through downstream systems in a single block.
Modeling
Recognizing and identifying the risk is the first move. Modeling is what lets you act on it.
Capital markets desks do not push new strategies live without first testing them against synthetic conditions. Airlines do not put pilots in the sky without simulator hours. This continuous modeling practice of asking what a system will do in a certain environment before it actually does it is essential for every industry with a complex structure. These are industries that pay for failure in real time.
Onchain finance is now in that category. The most sophisticated protocols already operate this way: continuously simulating how a proposed change will behave against the live state before any code reaches mainnet, then continuing to model the system's behavior under stress scenarios it has not yet faced. That practice has been the quiet competitive advantage of the leading crypto-native teams for years. It is about to become the table-stakes requirement for the next wave of capital to operate onchain at scale.
Blockchain operations
The leading crypto-native teams are becoming more institutional. As a consequence, the institutions arriving onchain are inheriting the operational practices that crypto built. Despite arriving from different places, they are converging at the same point: blockchain operations.
Each side has something to learn from the other. The institutional side brings rigor, risk management, and the lived experience of running financial products at scale. The crypto-native side brings a working model of what products can look like when they are transparent, programmable, and composable from the start. The next phase belongs to the teams that combine both.
Don’t wait until day two to think about day two.
