A new proposal within the Internet Computer Protocol ecosystem has cleared the approval stage, setting plans in motion to build a test cloud engine that leans on a mix of traditional cloud providers and a revenue-sharing model.
Proposal 141334 outlines the creation of an initial test engine made up of four cloud nodes distributed across major infrastructure platforms including Amazon Web Services, Google Cloud Platform and Microsoft Azure. The move signals a practical experiment in blending decentralised network design with existing cloud infrastructure rather than relying solely on independent node providers.
The structure introduces a different economic setup compared to typical network participation on ICP. Nodes that form part of this cloud engine will not receive fixed rewards from the network. Instead, their earnings depend on the activity generated within the engine itself. Operators are set to receive 80 per cent of the revenue produced, while the remaining 20 per cent will be used to burn ICP tokens.
This burn mechanism feeds into a deflationary model, where tokens are permanently removed from circulation as usage increases. In theory, this creates a direct link between network activity and token supply, with higher demand leading to more tokens being burned. Supporters argue that such a model aligns incentives between infrastructure providers and the broader ecosystem.
At the same time, the proposal reflects a wider discussion within decentralised networks about the role of large cloud providers. While ICP has long positioned itself as a decentralised alternative to traditional cloud services, the inclusion of platforms like AWS, Google Cloud and Azure in this test phase suggests a more flexible approach. It opens the door to hybrid setups where decentralised protocols can operate alongside established infrastructure, at least during early experimentation.
There are practical reasons behind this direction. Established cloud platforms offer reliability, global reach and familiar tooling, which can help test new systems under stable conditions. For developers and operators, this can lower the barrier to entry when experimenting with new configurations such as cloud engines.
However, the approach is not without questions. Some in the broader blockchain space have raised concerns about relying on centralised providers, even in a limited testing phase. The balance between convenience and decentralisation remains a point of debate, particularly for networks that have built their identity around reducing dependence on large tech firms.
The revenue-sharing model also introduces a shift in how node operators think about participation. Without fixed payments, operators take on more exposure to usage levels. This could encourage a focus on performance and efficiency, as higher activity directly translates into higher returns. On the other hand, it may also introduce variability that some operators find less predictable compared to steady rewards.
For the ICP network, the test cloud engine acts as a live trial rather than a final design. It provides a controlled environment to observe how hybrid infrastructure and deflationary incentives play out in practice. Outcomes from this phase are likely to inform whether similar models are expanded, adjusted or set aside in future proposals.
The decision to route a portion of revenue into token burns adds another layer to ICP’s broader token economics. Deflationary mechanisms have become a familiar feature across several blockchain projects, often framed as a way to balance supply with network usage. The effectiveness of such models, however, tends to depend on sustained activity rather than short-term spikes.
What stands out in this proposal is the attempt to tie infrastructure performance, revenue generation and token supply into a single loop. If the engine attracts meaningful usage, node operators benefit while the circulating supply of ICP tightens. If activity remains low, both earnings and burn rates stay limited.
For now, the focus shifts to implementation. The deployment of four nodes across major cloud platforms will offer early signals on performance, cost dynamics and developer interest. It will also provide a clearer picture of how well the model fits within ICP’s longer-term direction.
As with many protocol-level changes, the real test begins after approval. The proposal has set the framework, but its impact will depend on how the system performs once it moves from concept to operation.
Dear Reader,
Ledger Life is an independent platform dedicated to covering the Internet Computer (ICP) ecosystem and beyond. We focus on real stories, builder updates, project launches, and the quiet innovations that often get missed.
We’re not backed by sponsors. We rely on readers like you.
If you find value in what we publish—whether it’s deep dives into dApps, explainers on decentralised tech, or just keeping track of what’s moving in Web3—please consider making a donation. It helps us cover costs, stay consistent, and remain truly independent.
Your support goes a long way.
🧠 ICP Principal: ins6i-d53ug-zxmgh-qvum3-r3pvl-ufcvu-bdyon-ovzdy-d26k3-lgq2v-3qe
🧾 ICP Address: f8deb966878f8b83204b251d5d799e0345ea72b8e62e8cf9da8d8830e1b3b05f
Every contribution helps keep the lights on, the stories flowing, and the crypto clutter out.
Thank you for reading, sharing, and being part of this experiment in decentralised media.
—Team Ledger Life
Community Discussion