Nexus nodes: CLI hardware, task difficulty, and the Network transition

Proof workloads, the compute client, and the Exchange Upgrade

The compute client connected a task service to local proof generation, using the machine’s processor and memory to produce cryptographic evidence. A prover performed the expensive computation; the client then handled submission. These roles explain why hardware capacity mattered to node participation. They also separate compute contribution from placing an exchange order, which uses trading software and account margin.

The September 29, 2026 Exchange Upgrade superseded the Nexus Network as the canonical state system. The preceding testnet campaign era had already ended. Older instructions about connecting a node and earning points describe that earlier participation context.

The compute CLI retains controls for task requests and local proving. Its existence does not establish an active public proving campaign or a reward entitlement. Hardware assessment therefore concerns the documented client and a compatible task service, while any new Exchange incentive program has its own eligibility conditions.

Can your CPU and RAM sustain CLI proving?

A compatible CPU and sufficient available RAM determine whether an assigned proof workload can finish without exhausting the machine’s resources. A processor upgrade addresses execution capacity; memory capacity governs whether the workload fits.

Processor execution and concurrent work

In v0.10.19, --max-threads controls proving concurrency, while session setup limits the requested worker count using detected logical processor capacity and applies a memory projection when either a thread count or the optional --check-memory flag is explicitly selected. More concurrency means more work may overlap. It also increases competition for memory and processor time. This setting should not be interpreted as a precise operating-system limit on every thread that a proving subprocess creates.

Available memory and subprocesses

The prover runs proof generation in a subprocess, isolating that work from the main client. Memory pressure can terminate that subprocess before a usable proof reaches submission. Other applications and container limits affect the resources that it can actually use, even when the machine’s installed RAM looks sufficient. The v0.10.19 client offers an optional startup memory-risk check through --check-memory. That check uses a projection; it does not reserve memory or impose a hard memory ceiling.

Adaptive difficulty and a deliberate request limit

Adaptive difficulty changes the requested workload using completed-task performance, while an explicit difficulty override fixes the request setting. Those choices address task size separately from proving concurrency.

Automatic requests after successful work

In v0.10.19, the fetcher initially requests small_medium when no previous success exists. Successful submissions update its performance history. A sufficiently quick completed cycle can raise the next requested difficulty. The timing threshold belongs to that client version, and the cycle includes work after task receipt through submission. Slow delivery can therefore affect the recorded duration alongside proving speed.

The service can assign a different difficulty from the request. The assigned level matters when interpreting performance, because a requested higher level does not establish that the machine actually processed it.

An explicit ceiling for smaller work

nexus-compute-cli start --max-difficulty small requests the smaller supported difficulty ceiling. The override takes precedence over the adaptive request calculation in this version. Larger accepted names extend through the extra_large levels, with underscored names for additional tiers. Increasing the request limit changes what the client asks for; it does not create extra RAM or ensure assignment of harder work. A slower task alone also does not prove a memory failure.

Which compute-client package fits your operating system?

The v0.10.19 release configuration targets Linux and macOS on x86-64 and ARM64, plus Windows on x86-64. Operating system and processor architecture both determine the appropriate binary. A package built for the wrong target is a compatibility problem that additional memory cannot fix. Source compilation is another installation path, with its own compiler and dependency requirements. Processor instruction support also matters: the x86-64 macOS and Windows build settings enable AVX2, while the Linux release target uses different flags, so matching an operating system and architecture alone does not establish instruction compatibility.

Docker provides a container deployment path, but the container still shares the host’s finite CPU and memory resources. Its assigned limits belong in the hardware assessment. Establish binary compatibility before interpreting a crash as evidence that the next difficulty tier needs a faster computer.

Open full-size image

How can you distinguish proof generation from successful submission?

A successful local proof result establishes local computation, while a successful submission response establishes delivery through the client’s submission operation.

Open full-size image

Local generation and proof checks

The proving engine generates a proof and checks it locally before returning it for submission. A failure during generation points to a different stage from a network error after that work finishes. Task identifiers associate messages with assigned work, but an identifier alone does not show that a proof passed local checks.

Delivery and completion messages

The v0.10.19 worker increments its completed-task counter only after a successful submission. Its detailed completion message includes task size, duration, and difficulty. Read that message alongside submission errors: a return to a waiting state can follow a failed attempt. Neither local generation nor the client’s completion counter establishes eligibility for a token distribution, and buying faster hardware cannot repair an unavailable task service.

Running costs before the next hardware decision

Operating cost comes from the resources used and the time that they remain allocated. Local electricity cost depends on power draw, runtime, and the applicable tariff. A rented machine adds its billing terms. Longer proving attempts and failed work can consume those resources without adding successfully submitted tasks. Task difficulty and concurrency influence this cost exposure, so a hardware label alone cannot supply a fixed cost per proof.

Open full-size image

Older points totals are unsuitable as a fixed return estimate. Network-user incentive programs were planned to move to the Exchange over time, with their availability and terms requiring separate announcements. For existing compatible hardware, the immediate decision is whether a supported workload fits its resource budget and has an available service that accepts it. New spending needs a defined use beyond assumptions carried forward from the closed testnet campaigns.