DFINITY has tied its new Cloud Engines enterprise product to a proposed “Mission 70” token-economics plan that would direct 20% of Cloud Engines revenue toward buying and burning ICP, while leaving the remaining 80% with the node providers supplying the infrastructure. The plan aims to reduce ICP’s annual inflation rate from 9.72% to 2.92%, combining governance-led cuts to node rewards with a substantial increase in demand-driven token burns.
Cloud Engines is designed for companies that want to run private Internet Computer subnets without giving up the protocol’s core development tools and architecture. Customers can select their node providers, specify the country where their hardware runs, choose replica counts, and launch a subnet beginning with four nodes. The product places data-location control and infrastructure choice at the center of DFINITY’s enterprise pitch.
The proposed burn mechanism gives Cloud Engines a direct connection to ICP’s supply model. Revenue from private-subnet deployments would create a recurring source of token purchases and destruction, but its impact will depend on actual enterprise spending rather than a fixed protocol subsidy. That makes the demand portion of Mission 70 materially less certain than the reward reductions that can be enacted through governance.
A two-part route to lower ICP inflation
Mission 70 divides its proposed 70% reduction in ICP inflation between supply-side changes and higher token burns. DFINITY’s plan attributes 44 percentage points of the reduction to lower node-provider rewards, while the remaining 26 percentage points would need to come from additional demand for Internet Computer compute resources, including Cloud Engines deployments.
The distinction shapes the timeline. Governance participants can vote on reward parameters and subnet configuration rules, while revenue-funded burns depend on whether enterprises adopt the product, how much capacity they use, and how quickly features on the Cloud Engines roadmap reach production.
Among the supply-side measures under discussion are a 40% reduction in rewards for “generation 1” node providers and a cut in the minimum number of nodes required for a subnet, from 13 to seven. Reducing the subnet minimum could lower the cost of launching some deployments and change the amount of infrastructure required to support a given workload. Cutting node rewards would directly reduce new ICP issuance paid to operators.
DFINITY’s current figures place cycle burn at about 0.0689 TCYCLES per second. Reaching Mission 70’s stated deflation target would require burns of 0.77 XDR per second, roughly 15 times the current rate. The gap shows that Cloud Engines would need meaningful revenue generation, alongside other usage growth, before the demand-side component could meet its target.
The baseline daily burn cited in the plan is approximately $6,000. Under a structure that sends 20% of Cloud Engines revenue to ICP purchases and burns, burn levels in the tens of thousands of dollars per day would require correspondingly larger and sustained customer spending. No scaled data directly linking existing Cloud Engines revenue to ICP burn has yet been provided.
Private subnets target sovereignty-sensitive workloads
Cloud Engines is aimed most clearly at organizations with strict requirements over where data is processed and which hardware hosts it. Through opencloud.org, node providers can list hardware, while customers can filter offers by location, system specifications, and deployment duration. The marketplace-style structure is intended to give customers a choice of providers rather than binding an application to a single infrastructure operator.
DFINITY also presents portability as a core feature. A company using a Cloud Engines subnet could switch node providers without rewriting its code or redesigning its application architecture, according to the product’s stated model. For organizations wary of dependence on a single cloud operator, this could provide a different operating model from conventional managed-cloud contracts.
The product currently offers sovereign isolation, single-tenant operation, hardware selection, fixed-cost deployment, and no provider lock-in, according to the supplied product details. These functions address present-day data residency and workload isolation needs more directly than they address the broader technical ambitions outlined in later roadmaps.
Some roadmap features have not yet launched. Secure Encrypted Virtualization, or SEV, nodes are not live, and opencloud.org currently shows zero available encrypted nodes. Operator-controlled upgrades have also not shipped. Those limitations matter for enterprise buyers assessing whether the product can meet specialized security or change-management policies today, rather than after future releases.
Early deployments offer limited evidence on scale
DFINITY has cited a Pakistan national Cloud Engines initiative and a United Nations Development Programme pilot among deployed examples. Pakistan’s ChatT, described as a sovereign communications application, has moved into a promotion phase. These projects provide early evidence that the model is being tested in public-sector and sovereignty-focused settings, though they do not yet establish a large recurring revenue base for the burn mechanism.
The enterprise proposition also faces a practical balancing act. Offering customers control over geography, hardware, provider selection, and subnet size could appeal to regulated or government-linked users. Yet those same deployments may involve longer procurement cycles than conventional self-service cloud products, slowing the pace at which usage converts into protocol-level burn.
ICP has fallen 99.6% from its historical peak, according to the market metrics cited alongside Mission 70, and its circulating market value is about $1.1 billion. Those figures provide context for why changes to token issuance and burns draw attention, but they do not determine whether the proposed model will produce a sustained reduction in supply growth.
Mission 70’s near-term deliverables are therefore likely to be judged first by governance decisions on node rewards and subnet rules. The larger demand-side promise rests on whether Cloud Engines can turn data-sovereignty requirements into durable enterprise revenue, giving the planned 20% burn allocation enough scale to narrow the large gap between present burn levels and the target.
To relate Mission 70’s deflation mechanics to trading behavior, explore our concise guide: understand crypto tokenomics in depth.
Disclaimer: The content on this page is provided for general informational purposes only and does not represent the views or financial advice of Toobit. We make no guarantees regarding the accuracy or completeness of this information and shall not be held liable for any errors, omissions, or outcomes resulting from its use. Investing in digital assets involves risk; users should independently evaluate their financial situation and the risks involved. For further details, please consult our Terms of Service and Risk Disclosure.
