Arc mainnetchainblock

The API described here is not yet accepting production traffic. Endpoints, parameters and prices are the Phase 1 design and may still change.

DocumentationRun a node

Operators

Run a node

A machine with a GPU, a stable connection, and a wallet on Arc. The rest is a config file and a schedule.

What you need

FieldTypeDescription
GPUhardware8 GB of VRAM at minimum. What you have decides your class, and your class decides which models — and which prices — you can serve.
ConnectionnetworkStable matters more than fast. 25 Mbit up is plenty; dropouts are what cost you.
WalletaddressAn address on Arc holding USDC, for collateral and for payouts. Chain ID 5042.
DiskstorageFrom 40 GB for Spark to several hundred for Vault. Weights are cached locally.

Classes

ClassVRAMTypical cardMin. collateral
Spark8–12 GBRTX 3060, 4060$150
Core16–24 GBRTX 4080, 4090$500
Forge32–48 GBRTX 6000 Ada, dual 4090$1,500
Vault80 GB+H100, multi-card servers$5,000
Spark and Vault open in Phase 2. Phase 1 runs Core and Forge only, so a 12 GB card can register but will not receive work yet.

Install

shell
curl -fsSL https://get.vacuumfi.com | sh vacuum init          # detects the GPU, picks a class, writes the configvacuum models pull   # downloads and verifies the weights for that classvacuum start

vacuum models pull checks each weights file against the hash in the on-chain registry before it will serve it. A file that does not match is discarded — you cannot accidentally serve a model you did not commit to, which is the failure mode that would get you slashed.

Post collateral

Collateral is what makes your promise credible, and what you lose if you break it. It is posted in USDC on Arc and scales with the class you are registering.

shell
vacuum collateral post --amount 850
  • Posting above the minimum raises your ceiling on concurrent work.
  • Withdrawal is possible only after an exit period, so no recent fraud can outrun a slash.
  • Confirmed fraud slashes it, voids unclaimed earnings, refunds the affected builders and removes the node. See Receipts and proofs.

Availability

The point of the network is the hours your machine is already idle. The client is built to get out of the way the moment it is not.

toml
# ~/.vacuum/config.toml [node]label = "workshop-01"payout = "0x4a7f...3d21"      # where earnings are claimed to, on Arc [availability]# The node takes work in these windows and is invisible outside them.schedule = ["00:00-09:00", "14:00-18:00"]pause_on_foreground_gpu = true  # yields within seconds when you launch a game [limits]max_concurrent = 4reserve_vram_mb = 2048          # left free for the desktop

With pause_on_foreground_gpu, launching a game frees the GPU within seconds: in-flight requests are handed back to the router, which fails them over to another node. You are not paid for the interrupted request, and your uptime score records it — so use the schedule for hours you know are yours, rather than relying on the interrupt.

shell
vacuum pause     # stop taking new work, finish what is in flightvacuum resume

Getting paid

You earn 80% of what each request costs the builder, accruing per token generated. Earnings from an epoch stay locked through its challenge window — six epochs, roughly six hours — and then become freely claimable.

shell
vacuum status   workshop-01   Core class   active  epoch         2926  (40% elapsed, closes in 36 min)  claimable     10.98 USDC  in challenge   1.54 USDC   across 6 epochs  reputation    99.7   audit sample rate 0.6% vacuum claim

vacuum claim settles everything past its window in a single transaction on Arc. There is no minimum and no schedule; unclaimed earnings simply accumulate. The same figures are in the node dashboard.

Keeping reputation

Reputation is not a badge, it is your revenue. The router prefers higher-rated nodes at equal specs, and your audit sample rate falls as your record lengthens — so a good node is both busier and cheaper to run.

  • Uptime inside your own windows matters more than total hours. Advertising availability you do not honour is the fastest way down.
  • Never modify the weights. Not a different quantization, not a newer engine build, not a “better” sampler. Any of those is model substitution as far as an audit is concerned.
  • Expect canaries. Requests with known answers arrive continuously and look exactly like real traffic. There is no way to serve them differently, which is the point.
  • Watch latency. A node that serves correctly but slowly loses traffic quietly, long before anything formal happens.