What Your Stake Protects: Chain Halt Rescue

By Adam Liposky, co-founder. Part of a series on how Canopy works underneath the apps.

On Canopy, every app is its own blockchain. If you build on Canopy, you never have to think about the blockchain part, and most builders never do. In practice, an app being its own blockchain means something simple: the blockchain is where your app runs, the way a web app runs on servers. When people talk about a chain halting, what they are describing, from your users' point of view, is your app going offline.

Most discussions of blockchain security focus on attacks, someone trying to steal funds or rewrite history, and the staked collateral that makes that too expensive to attempt. That protection is real, but it is not the problem most builders actually run into. The more common problem is the outage. Your app stops responding, your users cannot do anything, and you are left trying to get it back while your community watches. Canopy's architecture includes a way to shorten that outage, called Chain Halt Rescue. This piece explains what causes these outages, why they usually last so long, and how Canopy gets apps back online faster. It assumes no background in how blockchains work under the hood.

Why Apps Go Offline

Every action in your app, a trade, a transfer, a vote, gets recorded in a new block, and a new block is only added when enough of the validators running your app agree on it. On Canopy, as on most proof-of-stake networks, "enough" means validators holding more than two-thirds of the voting power. That rule is what makes your app's records final and trustworthy, but it also means that if more than a third of those validators cannot take part, no new blocks get added. Your app is still there, but nothing new can happen in it. That is a chain halt.

Chain halts have three common causes, and none of them involves an attacker. The first is validators going offline, which can happen for ordinary reasons, like a cloud provider having an incident that takes down several operators at once, or a validator with a large share of your app's committee signing up before its server is actually running. The second is the software disagreeing with itself, where different copies of your app process the same activity and arrive at slightly different results, so they can no longer agree. The third is a plain bug, for example an update that some validators install and others do not, which splits them into groups that reject each other's work.

These are the same kinds of failure any software product runs into, and they become more likely the more often an app changes. That is especially relevant on Canopy, where apps are designed to be updated often, frequently with AI tools speeding up development.

Sui's experience in May 2026 shows how quickly one upgrade problem can turn into several. Over two days, the network halted three times, with the first and last halts each lasting roughly six hours. The first halt came from a bug in a new release. The team shipped a quick patch to restore service, accepting what it called a known issue with a low probability of causing another halt, and the next morning the network stopped again. When validators restarted to install the full fix, the restart itself exposed a third, previously unknown bug, and the network froze a third time. No user funds were lost, but every app on the network went offline three separate times in two days.

How Recovery Usually Works

When an app runs on its own standalone blockchain, getting it back online is mostly a coordination problem, and fixing the actual bug is often the quickest part. The usual sequence runs like this. The team finds the problem and, if needed, releases corrected software. Then that software has to reach validators holding at least two-thirds of the voting power, each of those independent operators has to install it, and finally they all have to restart at the same moment so the app can start adding blocks again.

Those last steps are where the time goes. The validators running your app are separate businesses in different time zones, and getting two-thirds of them to update and restart together depends on messages, calls, and goodwill. This step alone often adds another 24 hours to an outage after the fix is already ready. For your users, that is a full extra day of a frozen app, and the uncertainty about when it will return does its own damage to their confidence.

Solana's outage history shows how much of a halt can be coordination rather than repair. Restarting Solana after a halt requires operators to agree off-chain on a restart point, each generate a snapshot, reboot, and then wait until at least 80% of total stake is back online before blocks resume. In September 2021, a flood of bot traffic stalled the network for about 17 hours, and a second bug that appeared during the first restart forced a second coordinated restart. In February 2023, a single validator's malfunctioning software flooded the network with an oversized block, and recovery took almost 19 hours, with operators downgrading to an earlier version and restarting together by hand. In both cases, a large share of the downtime was spent getting enough independent operators to act at the same time.

The hours themselves are only part of the cost. What users and builders remember is that the app went down, and repeated outages turn into a reputation that outlasts any single fix. Solana is the clearest example. Its engineers resolved each incident and the network's reliability improved substantially over time, yet by mid-2022 it was being described in headlines as "reliably unreliable", and its outage history is still among the first things written about it years later. For an app, the stakes are higher still. A large network can absorb a damaged reputation across thousands of projects, but a single app whose users cannot reach it during a busy market, a product launch, or a moment of news may not get those users back. Reliability is rarely why people choose an app. It is very often why they leave one.

Why Canopy Does It Differently

The reason Canopy can rescue a halted app comes down to one design choice: your app does not keep its own list of who runs it. That list lives on the Security Root, the shared Canopy network that supplies validators to every app.

It helps to compare this with a standalone blockchain. There, the list of validators is stored inside the app's own blockchain. If the app halts, that list is frozen along with everything else, because changing it would require adding a new block, which is exactly what the app cannot do. The only way out is for people to coordinate by hand.

On Canopy the two are separated. Your app keeps its own data and its own logic, but the validators running it are registered and assigned on the Security Root, which keeps running regardless of what happens to any one app. Your app receives its current list of validators from the Security Root over a live connection, and whenever that list changes, your app picks up the new one and carries on, without losing track of what has already been agreed. In plain terms, the decision about who is running your app can be made on a network that is still working, even while your app is stuck.

The same separation helps when the problem is a bug. Your app's logic runs as a plugin alongside the Security Root software, so you can ship a corrected version of your app without any change to Canopy itself and without waiting for anyone else's approval. The Security Root also keeps checkpoints, compact records of your app's recent blocks, which give you an independent reference for your app's last known-good state.

What a Rescue Looks Like

When an app halts, the Security Root has three tools available: bring in different validators, restart the process of agreeing on blocks, and roll the app's records back to an earlier point. Which of these matters depends on why the app stopped.

If the validators running your app go offline

Suppose your app loses more than a third of its voting power because several operators are down. On a standalone blockchain, you would have to wait for them to return. On Canopy, other validators who are already staked on the Security Root can start running your app by adding it to their existing stake with a single transaction. They do not need new keys or new collateral, only a running copy of your app. Unresponsive validators can be paused or removed. All of this happens on a network that is still adding blocks, and your app receives its updated list of validators automatically. As soon as validators holding more than two-thirds of the new list's voting power are online, your app picks up from where it stopped.

If your app's software is at fault

If the outage comes from a bug in your app's own code, someone still has to fix it. What changes is everything after the fix. Your corrected app is an update to its plugin, which validators can install without touching anything else they run, and you can schedule the change to take effect at a specific block so that every copy of your app switches over at the same point. If the outage leaves your app's records in question, the checkpoints on the Security Root show where it last stood.

Either way, the part of recovery that usually takes the longest, getting two-thirds of a group of independent operators to act together, is handled through ordinary transactions on a network that is already running instead of through a day of calls and messages. That is how the Security Root recovers apps from halts.

Where the Stake Comes In

It would be easy to read all this as a story about software design, but the rescue depends just as much on who is standing behind your app. The Security Root holds a large group of validators who have already staked CNPY, already run professional infrastructure, and can extend their existing stake to cover another app without raising anything new.

That group is what makes a fast rescue possible. An app on its own standalone blockchain has no reserve of experienced operators to call on, and any new operator would first have to buy and stake that app's own token before helping. On Canopy, the operators are already in place and already accountable, because the CNPY they have staked is at risk if they misbehave while running your app. The same model that lets your app launch with security from its very first block is the one that lets it recover when something goes wrong.

This is the sense in which stake on Canopy protects something concrete. Economic security is usually described as the cost of an attack, and staked CNPY does raise that cost. But for most apps, most of the time, the benefit they will actually feel is continuity: knowing that if the validators running their app fail, a larger group of staked operators can step in through ordinary transactions on a network that keeps running. Every validator and delegator who stakes CNPY on the Security Root adds to the depth of that reserve.

Limitations

Chain Halt Rescue shortens outages, but it does not make apps immune to them. It cannot fix your bugs. As with any infrastructure, if your app goes down because of a flaw in its code, someone still has to find and correct it, and how quickly that happens depends on your team. What Canopy removes is the coordination delay that follows the fix.

It depends on validators choosing to help. Running an app is voluntary, and validators who step in take on the work of running your app and put their full stake at risk in it. Apps that have good relationships with operators, and that reward the validators running them, will likely find help faster than apps that have not.

Nothing in this post is financial advice.

Sources

• Chain Halt Rescue
• Utility
• State Machine
• Checkpoints as a Service
• Canoliq node repository (activation heights and committee joining)
• Canopy whitepaper v2.0, section 6.3
• Sui traces three mainnet halts to upgrade bugs (The Block, May 31, 2026)
• A Complete History of Solana Outages (Helius)
• Reliably unreliable: Solana price dives after latest network outage (FXStreet, June 2022)