Frequently Asked Questions

Yes, increasing the number of CRNs per CCN is the general direction. This benefits both node types: CRNs give away a smaller share of revenue to their CCN, while CCNs see higher total revenue overall due to the greater number of linked CRNs.

The current network configuration limits CCNs to 5 CRNs, and the ratio of healthy nodes sits closer to 3.5 in practice. A transition phase is needed before the expanded linking can roll out.

5 CRNs per CCN is too low and not economically sustainable under the new usage-based model. The rebalancing is a core part of the proposal with team-wide consensus.

The basic formula is: Usage% × N × price per CU × 0.65, where N is the number of Compute Units the CRN provides. At 100% usage this simplifies to N × price per CU × 0.65. There can be some fluctuations for users requiring more disk.

Cost per CU (Compute Unit) is the key metric. Smaller nodes do not necessarily win on this metric — operators should evaluate their hardware carefully.

Yes. Node operators receive an amount of USD expressed in ALEPH, meaning the number of tokens received as rewards will vary inversely with the token price. It is up to node operators to decide whether to hold rewards (e.g. to set up more nodes or stake) or sell them.

It is considered the only sustainable long-term model given the project's history. Inflation was considered as an alternative but the Aleph token smart contract does not support it.

Yes. The holder tier is being removed as it is no longer considered viable.

The minimum wage pool totals 2,700,000 ALEPH over 6 months, with a linear decrease over that period. The first month's allocation is 900,000 ALEPH.

The pool is currently split equally three ways: 1/3 to CCNs, 1/3 to CRNs, and 1/3 to stakers.

Yes. The subsidy is allocated per CU of actual VMs allocated to the node — meaning it is based on CU work done (actual VM allocation), not raw CU capacity. The subsidy allocates VMs up to a network-wide cap of 3,000 CUs, with the goal of keeping healthy nodes sufficiently busy at all times.

The first iteration of the system will apply a slight skew in allocation towards more decentralised nodes, but the team acknowledges the full complexity has not yet been addressed in the current proposal. Several factors complicate a simple decentralisation-first approach:

• User filters: Users will be able to specify requirements such as geographic region, excluded datacenters, or minimum replication across providers.
• Fairness: The system must treat node operators in the same area equitably.
• Resilience: Filling the most decentralised node first is not necessarily optimal — spreading VMs reduces the migration burden in the event of a datacenter incident.
• Logical vs. geographical decentralisation: A single operator running 10 geographically distributed nodes still represents a single point of failure in a coordinated attack scenario.

The team has indicated that additional complexity and pricing premiums will likely be introduced in future iterations to fully capture these dynamics.

Yes. Some users may specifically require datacenter IPs, while others — such as AI agents that need to access services without being identified as automated — may prefer residential IPs. This use case is expected to be factored into the allocation model.

Yes, the team has confirmed that network utilisation metrics will be made available.

Not at launch, but the team has confirmed this visibility will be made available once the new system is deployed. The goal is to provide operators with a breakdown such as CPU cores in use, RAM in use, and corresponding earnings per hour.

The technical verification methodology has not yet been detailed publicly and is expected to be clarified in forthcoming documentation.

Confidential VMs run at a 2x price premium. They also typically provide more compute units, meaning higher overall revenue potential for node operators.

Growing demand is expected from users running confidential AI agents, which should lead to better usage levels on confidential VM nodes.

4th generation AMD EPYC processors (9004 or 8004 series) are required. 3rd gen cannot be used as its security has been compromised, and this requirement cannot be lowered.

One CU is defined as 1 vCPU, 2 GiB RAM, and 20 GiB disk.

Yes, more price categories are likely needed to account for the diversity of hardware in the network, and pricing premiums are expected to be introduced to reflect decentralisation factors. The team acknowledges current pricing may not be granular enough.

Three areas remain open to feedback: exact numbers and parameter tuning, the transition phase model (currently a relatively sharp linear decrease), and pricing granularity to better reflect hardware diversity.

Yes. The team has acknowledged having blind spots and welcomes constructive criticism across all aspects of the proposal, despite the long internal deliberation process.