HPC on VirtEngine

Supercomputing does not sell like cloud: work arrives as jobs with resource requirements, walltime limits, and partition targets, scheduled by systems like SLURM against allocation policies. Forcing that model into long-running container leases loses everything that makes HPC HPC.

The x/hpc module models batch work natively: on-chain HPC jobs are first-class marketplace objects with their own lifecycle, offered and priced through the same exchange economics as everything else.

The provider daemon's HPC integration connects to existing cluster controllers through native adapters — SLURM with munge or JWT authentication and per-partition configuration, plus MOAB and Open OnDemand. The cluster's scheduler remains in charge of its own resources; the marketplace becomes another source of authorized work.

A job lifecycle service polls on-chain jobs, dispatches them through the adapter, and tracks them to completion with configurable concurrency limits and timeouts. State recovery is crash-safe: a daemon restart does not orphan running jobs or double-dispatch queued ones. Job events, security events, and usage reports flow to a dedicated audit log.

HPC usage batches enter the same pipeline as container leases: signed records, the 24-hour dispute window, escrow drawdown, the governed take. For facilities, that means spare-cycle monetization lands as settled chain payments — no new billing infrastructure, no invoicing external users.

Facilities monetize idle cycles at prices they set per partition, without disturbing primary-user allocations. Tenants — ML teams above all — get access to scheduler-class capacity with real interconnects, through an order they can post today instead of an allocation process measured in months. The operational detail lives in docs/hpc-provider-operations.md, docs/hpc-node-agent.md, and docs/hpc-workload-publishing.md in the protocol repo.