20% of revenue used for burning: Can ICP Cloud Engines support a token revaluation?

Original author: Xiaobing

Over the weekend, the ICP community suddenly came alive. The focus of discussion was Cloud Engines, a product that lets enterprises run private subnets on the Internet Computer.

The reason for the excitement is straightforward: DFINITY tied Cloud Engines to a deflationary plan called Mission 70. Node providers sell Cloud Engines to enterprises, keeping 80% of the revenue for themselves and handing the remaining 20% to the network to buy and burn ICP. If there are enough enterprise customers, ICP's inflation rate will be cut from 9.72% to 2.92%—a 70% reduction.

This is a very clean narrative: enterprises move to the cloud → revenue is generated → tokens are burned → supply contracts → price re-rates. With ICP down 99.6% from its all-time high and its circulating market cap compressed to $1.1 billion, any story that can credibly tell of "fundamentals driving a price reversal" will be amplified by the community.

The question is: what stage is this story currently at?

What exactly are Cloud Engines?

Think of Cloud Engines as a "custom data center."

ICP's public network is a shared highway, with all applications running on the same pool of nodes. Cloud Engines, by contrast, gives enterprises a dedicated lane: you choose your own node providers, decide which country the machines are located in, and control the number of replicas yourself. The underlying protocol, smart contracts, and chain-key cryptography are exactly the same as the public network, but the hardware and data sovereignty belong to you.

For enterprises, the selling point is "no lock-in." If you don't like a particular node provider, just swap them out—no need to migrate code or change your architecture. The vendor lock-in problem that gives CTOs the biggest headaches in traditional cloud computing is solved by Cloud Engines through protocol-level standardization.

Node providers list their hardware on opencloud.org, filterable by geographic location, specifications, and runtime duration. Enterprises pick nodes there, assemble their own subnets, starting with a minimum of 4 nodes.

Sounds ideal, but there are a few details worth noting.

The gap between narrative and reality

One capability DFINITY repeatedly emphasizes in its promotion is SEV-encrypted nodes, which prevent even node providers from seeing the data running on them. This is extremely important for financial, healthcare, and government customers.

But SEV nodes don't exist today.

A developer in the community put it clearly on the forum: SEV encryption is a roadmap feature, with zero nodes available. Also on the roadmap is "operator-controlled upgrades," letting enterprises decide when to upgrade their subnets rather than being forced by the protocol. This feature hasn't launched either.

What Cloud Engines can actually do today: sovereign isolation, single-tenancy, no lock-in, hardware optionality, and fixed costs. Is that enough to get enterprises to pay? Yes, but only for scenarios with hard requirements around data sovereignty.

Cases that have already landed include Pakistan's national cloud engine and a UNDP pilot project. Pakistan's ChatT, a sovereign communication app, has entered its rollout phase. These cases prove the product works, but there's still a clear distance from "large-scale enterprise adoption."

The Mission 70 whitepaper contains a set of key numbers.

ICP's current cycle burn rate is approximately 0.0689 TCYCLES/s. To achieve the 70% deflation target, this number needs to reach 0.77 XDR/s—roughly 15 times the current level.

Mission 70 splits inflation reduction into two legs: the supply side cuts node rewards, contributing 44% of the reduction; the demand side relies on increased burning, which must contribute the remaining 26%. Supply-side measures are relatively controllable—cutting first-generation node rewards by 40% and reducing the minimum node count per subnet from 13 to 7 are things governance votes can decide.

But the demand side depends entirely on the market. For 20% of Cloud Engines revenue to translate into sufficient ICP burn, Cloud Engines' revenue scale needs to reach a certain threshold. Based on the current burn base of $6,000 per day, it needs to grow from near zero to tens of thousands of dollars in additional daily burns for this leg to stand.

An analyst on Reddit expressed a representative attitude: bullish on ICP long-term, but taking a "prove it first" stance on achieving the 70% target within 2026. They believe they need to see the cycle burn rate stabilize consistently at 0.3 to 0.5 TCYCLES/s before trusting that the trend is real.

How should we read this card?

ICP Cloud Engines' positioning hits a real need: enterprises want to move to the cloud but don't want to be held hostage by AWS and Azure, and some scenarios require data sovereignty. Using blockchain infrastructure to do this makes logical sense.

But from an investment perspective, there's a timing gap here.

The narrative is running ahead of the product. The 20% burn mechanism is already being discussed by the community as the core logic for token re-rating, but Cloud Engines has only just begun Early Access, SEV-encrypted nodes are still on the roadmap, and total daily burns are under $10,000. The token has already fallen 99.6% from its high, with market cap compressed to $1.1 billion—the valuation is indeed cheap.

Every link in this chain takes time: Cloud Engines from Early Access to full commercial launch, enterprise customers from pilot to scaled procurement, node providers from a handful to a competitive market, and the 20% revenue share from a paper mechanism to actually generating meaningful burn volume.

Mission 70's supply-side measures—cutting node rewards and shrinking subnets—are the nearer catalysts. If these governance proposals land in the coming months, the inflation rate will see a step-down reduction, which has a more direct short-term impact on price than Cloud Engines.

The Cloud Engines story is a farther-off bet. It's a bet that ICP can carve out a small slice of a trillion-dollar cloud computing market, and that the revenue from that slice will be enough for the 20% burn ratio to create real deflationary pressure.

At the current stage, it's a trade where narrative precedes fundamentals. The Pakistan and UNDP cases prove feasibility, but not scalability.

How far away is the token re-rating? At minimum, we need to wait until Cloud Engines produces its first batch of quantifiable burn data. Until then, all deflation calculations are discounting today's price with future revenue.