Aleph Cloud tokenomics update proposal

Following the introduction of payment through credits, it is time to update the Aleph Cloud tokenomics. The goals of this proposal are the following:

  • Pay node operators based on real usage, not just availability

  • Make node incentives less sensitive to the whims of the crypto market

  • Drive more usage of Aleph Cloud (more users, more workloads, more revenue).

This post is a proposal. Nothing is set in stone until the community gathers feedback. To explain the new model, let’s start by explaining the credits payment system.

The credits payment system

Since end of January, anyone can buy Aleph Cloud credits using a smart contract deployed on Ethereum mainnet. Users can pay with ALEPH, USDC, ETH or any ERC20 token for credits to use on Aleph Cloud. The next update of the Aleph Cloud app will simplify interactions with this smart contract, and we’ll add credit card payments in future updates.

Role Key Change Expected Impact
CRN operators Rewards now tied to actual usage, not just uptime More predictable USD-equivalent income; larger nodes earn proportionally more
CCN operators Same usage-based model with topology adjustment Income adapts as CRN/CCN ratio evolves toward v2
Stakers 20% of all protocol revenue ~4.6% APR baseline (in ALEPH tokens); grows with organic usage
Users Pay with USDC/ETH/ALEPH via credits Simpler UX; credit card support coming

Simpler UX; credit card support coming

The smart contract swaps the received tokens to ALEPH upon payment, and then funnels the funds to 3 possible outputs:

  • a distribution pool (for operators + stakers)

  • a developers pool (protocol development; see below)

  • a burn address (not enabled at launch)

Here’s the split we’re proposing:

Distribution pool (95%)

  • CRNs: 60%

  • CCNs: 15%

  • Stakers: 20%

Developers pool: 5%
Burn: 0% for now

Two important notes:

  • We propose to timelock the dev pool, then later use it to refill incentives once unlocked.

  • We’re not enabling burn at launch. We want to keep it as a lever for later, once organic revenue is covering a meaningful part of node operating costs. We’ll come back with a separate governance proposal that defines the activation conditions.

You can explore the source code of the smart contract for more details: https://github.com/aleph-im/aleph-contract-eth-credit.

Usage incentives

The current incentives model simply rewards nodes for being healthy and connected to the network. The new model rewards usage. While organic usage will eventually pay for all nodes, we need to bootstrap this model. To achieve this, we will repurpose the incentives pool to guarantee a minimum level of usage for a set network size (or, in other words, a fixed amount of Compute Units).

The VMs deployed as part of this incentives program will be public goods selected to raise awareness about Aleph Cloud while guaranteeing viable rewards for the current network size:

  • AI agents

  • Free services: CI agents, storage services, etc.

  • Marketing initiatives.

We computed a sweet spot of roughly 70% usage for 350 CRNs, or 3,000 Compute Units (CUs). At the current price of $0.011 per CU per hour, this yields a subsidy of $23,760 over 30 days. Following the split presented above, this yields the following rewards for node operators at $0.025/ALEPH:

  • CRNs: 1,630 ALEPH per 30-day period

  • CCNs: 1,426 ALEPH per 30-day period

  • Stakers: 4.6% yearly APR (denominated in ALEPH tokens)

These numbers are averages and depend on parameters like the number of CUs per CRN, the CRNs linked to a given CCN, etc. Overall, it is now incentivized to run larger CRNs with more Compute Units.

Once organic usage picks up and becomes significant, the incentives program will either be reduced or kept to increase the size of the network, depending on market conditions.

Additionally, the ecosystem pool will be used to provide credits to attract and onboard paying customers to Aleph Cloud, which will lead to organic usage and revenue down the line.

Minimum wage

The proposed model does affect the rewards of CCN operators: at current network parameters, they would get around 40% of what they receive today. Operators can increase their revenue by:

  • Linking CRNs with more CUs

  • Linking CRNs with special features (confidential VMs, GPUs)

And the network will also evolve towards supporting more CRNs per CCN, increasing revenue for all. The network configuration being what they are, a transition phase is necessary. This is why we propose a minimum wage system to give node operators time to adapt to the new tokenomics. A pool of rewards will be shared between CRNs and CCNs over the next 6 months. The initial amount will be 900000 Aleph per 30-day period and will decrease linearly until the new system fully takes over.

Fairness

VMs will be allocated fairly among CRNs with scores above 80% to reach the target usage on these nodes. For CRNs with inferior scores, only VMs requesting to be allocated on one of these nodes will be allocated there. Note that nodes without support for public IPv6 cannot be used to run instances for technical reasons.

GPUs and confidential VMs

While we focus on standard Compute Units in this proposal, the new model ultimately ties pricing to node rewards. GPUs and confidential CRNs will therefore earn more than regular CRNs by design. As for guaranteeing usage, GPU nodes have historically maintained near-100% usage levels on the network, and ecosystem initiatives will use confidential VMs preferentially.

Sensitivity to market conditions

Unlike pure token-emission models, this design protects node operators from extreme market swings through USD-denominated usage targets and a 1,350,000 ALEPH monthly emission cap. We stress-tested this model against pessimistic scenarios (declining token prices, slow organic growth) to ensure multi-year sustainability of the incentives pool.

To avoid depleting the incentives pool instantaneously if the token price were to drop significantly, the subsidies are capped at 1,350,000 ALEPH per month. When this cap is reached, rewards are distributed proportionally across all eligible nodes, meaning individual payouts decrease but no node is excluded.

Changes related to Aleph v2

Aleph v2 keeps the same idea, but CCNs will manage more CRNs and we’ll introduce new node types. As that ratio changes, the CRN/CCN split should evolve too, also accounting for CCNs getting heavier hardware requirements.

Timeline

The credits system is already up and running, supports instances today and will support confidential VMs with the next update of CCNs coming next week. We still need to implement the rewards distribution system as well as guarantee the fair allocation of VMs across all nodes on the network. We expect the development of these features to take a few more weeks. Reasonably, the new system can be fully functional by April 2026.

Sunsetting Holder Tier and Pay As You Go

Credits will fully replace Pay As You Go (PAYG) and holder tier payments. PAYG will be phased out by beginning of March. The date for the deprecation of holder tier is yet to be determined.

  • Existing PAYG VMs will keep on running until the user deletes them or the payment stream is cancelled. The remaining ALEPH on their account can be converted to credits.

  • Existing holder tier VMs will keep on running until the user deletes them or reduces their balance below the minimum threshold required to fund their VMs.

  • Existing holder tier files will be stored until the user deletes them or reduces their balance below the minimum threshold required to store their files.

Conclusion

The new Aleph Cloud tokenomics aim to make payments on the network simpler, reward node operators more predictably and fairly, and orient the network towards growth.

We post this as a proposal on the community forum for a good reason: we want your feedback! We developed a tool to experiment with the tokenomics and analyze the impact of different parameters on the profitability of nodes and the longevity of the incentives pool. You can try it out at https://tokenomics.aleph.cloud.

Next steps

This proposal will remain open for community feedback until March 10, 2026. We strongly encourage:

The target implementation date is April 2026.

I would like to preface this by saying that I am in full agreement with this new payment system. The previous system was unsustainable; everything would have collapsed in a short time. In fact, in my opinion, we are already late. Still, better late than never!

However, I have a few questions:

  1. When the new system is fully operational, will a CRN only earn if it is being used, regardless of whether it is linked to a CCN? Correct? In other words, even if a CRN is not linked to a CCN, but it is being used, it will still earn rewards, correct? I imagine, then, that whether or not it’s linked to a CCN is irrelevant

  2. I believe it will be quite impossible to maintain a CCN. Even by linking high-performance CRNs (GPUs, etc.), I think it will be hard just to break even. Furthermore, it is currently just as difficult to find high-performance CRNs that are already operational. By doing this, you will force CCN operators to set up and link their own CRNs themselves—all just to break even. Who would be willing to do that? Aren’t you afraid of ending up with only about 10 active CCNs on the network?

  3. In my opinion, specifically for CCNs, there should always be a minimum reward. If the goal is simply to reduce the number of active CCNs, have you considered making their activation more difficult? For example, by significantly increasing the number of ALEPH tokens required to activate them? It is currently 200k ALEPH; it could go up to 400k or more. You could also increase the minimum amount of ALEPH in staking to make them operational (currently 500k, it could rise to 1 million).

Hey, appreciate the candor. Let me answer your questions:

  1. VMs will only be allocated to CRNs linked to a CCN. This gives us trust in the CRN, coming from the fact that a staked CCN links them. The CCN/CRN relationship is only gonna get more important with v2 as well, so this is preparation for that in a way.
  2. It’s really gonna depend on usage, how CRNs adapt to the new model and how you source the hardware. If you link large CRNs running CCNs at a profit is absolutely possible. It’s also possible to reduce costs by self-hosting, sharing hosting, etc. We know that it’s very likely that the current proposal ends up in a reduction of the number of CCNs. but we hope that the measures we propose and the efforts we make on increasing the usage of the network will help counter-balancing that. We’re more than happy to discuss changes to the numbers we proposed if it helps make everyone happier in the long run.
  3. That’s an option, the problem is that it also makes CCNs less attractive compared to regular staking (more stake required = lower APR). The problem with minimum wage is that it’s not derived from usage, so there must be an incentives pool feeding into that (the ALEPH token does not support minting new tokens, so we can’t do inflation Solana-style). But if you can think of a mechanism to achieve the same effect that could be interesting.