ARC链

Desktop GUI (requires a screen)

These stable names are generated by the unified v0.8.0 release pipeline; until that exact release is published, the links intentionally do not resolve. The macOS package metadata declares 11.0 as its minimum, but CI currently runs the package only on macOS 15; no older-macOS or Windows-version runtime floor is claimed until those exact versions receive a release-blocking test. The GUI is not a server binary: it needs a graphical session. An EC2/VPS/SSH-only machine should use the headless installer below. Linux ARM64 is also headless-only.

The public v0.7.11 desktop could manually check, verify, and install a signed update from Settings, but its saved automatic-update preference never started a scheduler. The v0.8.0 candidate now checks the signed manifest shortly after startup and every 24 hours when that setting is enabled. Background checks do not download or install anything; the user confirms installation. macOS, Windows, and Linux AppImage can then update in place. .deb and .rpm remain owned by their package managers; the app reports the available version but cannot invoke in-app replacement for those channels.

📖 Desktop controls: Getting Started with ARC Node — release gates, identity, inference evidence, faucet, mined reward receipts, and FAQ.

---

Install binaries/config only; print the command but do not start anything

bash install.sh --version 0.8.0 --no-service --no-auto-update

Serve deterministic community inference. The installer adds

Reproducible pin; an older version is rejected if a newer one is installed

bash install.sh --version 0.8.0

For an install that kept the scheduled updater, the manual commands are:

v0.8.0 release status and quickstart

Source-freeze snapshot (2026-08-31; tag-stable): At this commit's review cutoff, v0.8.0 / protocol v3 was not published or deployed, and GitHub latest was still the desktop-only v0.7.11 bundle. This is a historical pre-tag statement, not a live status probe. An immutable v0.8.0 tag keeps this source-freeze record; determine current release and fleet status only from the exact release evidence and signed rollout receipts described below. The default branch may receive a reviewed post-rollout status update.

This README does not use the moving latest release as an install source. The immutable v0.8.x release is intentionally not promoted to GitHub's global latest channel while unsigned v0.7 updaters remain in the field. A first v0.7-to-v0.8 migration is therefore manual and pinned to the exact tag; the legacy updater is not a supported migration mechanism.

If the complete exact v0.8.0 release shows every required asset, SHA256SUMS, and SHA256SUMS.sig, an SSH/EC2/VPS operator can run:

```bash curl -fsSLO --proto '=https' --proto-redir '=https' --tlsv1.2 https://raw.githubusercontent.com/FerrumVir/arc-chain/v0.8.0/install.sh ARC_INSTALL_SHA256=0413fdd6088d0522841c472abfcf460b1ffaba67a6923355325d699c2f5b0242 if command -v sha256sum >/dev/null 2>&1; then printf '%s %s\n' "$ARC_INSTALL_SHA256" install.sh | sha256sum -c - else printf '%s %s\n' "$ARC_INSTALL_SHA256" install.sh | shasum -a 256 -c - fi

Observer/router quickstart. Add a verified --model path to execute inference.

bash install.sh --version 0.8.0 ```

Expected install.sh SHA-256 for this candidate: 0413fdd6088d0522841c472abfcf460b1ffaba67a6923355325d699c2f5b0242.

The unified release contract restores headless Linux amd64 and arm64, Intel and Apple Silicon macOS, Windows CLI binaries, signed desktop-updater payloads, normalized desktop installers, and one checksummed installer. Until the exact release evidence exists, build and test only from a reviewed checkout; do not treat the commands above as a production download. Publication alone never proves fleet deployment: the public fleet also requires the coordinated recovery/cutover gate. Unsigned artifacts, updater signatures, the owner-signed checksum manifest, draft publication, and read-only release verification cross separate exact-ID/digest-bound jobs; protected key windows execute only reviewed direct signing tools and never repository programs.

Command-line network demos

Inspect a public inference response, its trace, and the evidence the selected coordinator actually returns:

ARC_COORDINATOR=http://127.0.0.1:9944 bash scripts/arc-demo.sh

Run this only against a controlled local or reviewed recovery-candidate coordinator. Automatic public-fleet discovery is disabled because the public v2 seeds have mixed versions and divergent state. The script inspects the selected pipeline, dispatches a prompt, prints its trace, and asks for recomputation.

A word on that re-run, because it is the point of the demo. The coordinator caches by (model, prompt, max_tokens), so simply POSTing the same prompt twice is answered out of cache and proves nothing. The script sends force_recompute: a supporting candidate reports ✓ DETERMINISTIC after two pipeline walks; a cache response is labeled ● SERVED FROM CACHE (hash match).

Attempt to recompute a past public inference claim on your own machine:

ARC_COORDINATOR=http://127.0.0.1:9944 bash scripts/arc-verify.sh --latest

The historical script sweeps seeds for an inference record, replays its prompt, and compares reported commitments. Its VERIFIED label means only that those reported hashes matched. A cache response is not recomputation, and the public v2 model ID below does not bind the weight bytes, so this is not exact-artifact proof.

In the read-only 2026-08-28 public-v2 snapshot, model_hash was still a BLAKE3 of the model's shape label (arc-32L-4096d-32h-32000v), not of the weight bytes. It proves the same declared shape, not the same tensors. The unpublished v0.8.0/v3 candidate instead streams the complete --model artifact through BLAKE3 and uses that exact byte commitment for shard routing, worker eligibility, caches, attestations, and verification. Do not read that candidate behavior as already deployed on the public fleet.

---

Network endpoints

The production-v3 candidate configuration uses these six explicit, literal-IPv4 TLS origins. P2P addresses are separate and are never converted into RPC URLs at runtime. The locked rollout stages SHA-pinned Caddy 2.11.4 and requests a publicly trusted IP-address certificate from Let's Encrypt's production ACME service with the shortlived profile and HTTP-01 challenge. This removes the shared nip.io/sslip.io wildcard-DNS dependency; certificate issuance and renewal still fail closed on the public ACME and port-80 reachability checks. These candidate origins are not evidence that the v3 cutover is complete: use them only after the locked rollout has installed and verified every gateway.

Raw public http://IP:9090 origins are legacy diagnostics, not supported v3 client or validator configuration. Non-loopback production RPC must use HTTPS.

The sealed protocol-v3 gateway exposes only the following exact public API. Unknown paths and methods return 404/405; a handler existing in source does not make it public.

Public GET paths carried verbatim in the sealed rollout manifest:

/health /info /network/info /stats /validators /block/latest /blocks /inference/readiness /inference/attestations /economics/rewards /faucet/status /community/reward_policy /workers/scoreboard /shards /models /models/shards

/community/list remains an internal wire-compatibility handler, but it is not exposed by the protocol-v3 public gateway because its GET implementation prunes stale in-memory registrations. Dashboards, walkthroughs, health checks, and recovery probes use the read-only /workers/scoreboard endpoint and query /community/reward_policy separately for issuance readiness.

The gateway also admits these strictly shaped public GET routes:

/block/{height} /block/{height}/txs /tx/{hash} /tx/{hash}/full /account/{address} /account/{address}/txs /worker/earnings/{address} /community/reward_receipt/{tx_hash} /community/reward_job/{job_id}

Public POST paths carried verbatim in the sealed rollout manifest:

/inference/run /inference/run_consensus /community/register /community/heartbeat /community/claim_work /community/submit_work /tx/submit /tx/submit_signed /tx/submit_batch /faucet/claim

Clients may probe the mutation-free /inference/readiness contract at multiple origins, but one inference click selects one origin and sends at most one POST. Every timeout, reset, HTTP error, or malformed response after that POST is an ambiguous possibly-settled outcome and is never replayed on another route. /inference/run* has a 4,000-second upstream timeout, worker submission has a 2,700-second timeout, and the validator-only approval path has a 1,500-second timeout. The faucet POST is only a submission; only a successful mined receipt confirms the 1 ARC credit.

/internal/community/reward/approve, /shards/announce, /inference/forward_shard, and /inference/cleanup_shard are restricted to the six sealed validator IPs and have no browser CORS policy. The source handlers /inference/run_sharded, /inference/results, /community/reward_approval/{job_id}, and /eth are intentionally not routed by the public v3 gateway. Legacy/demo documents describing those paths are not the production API contract. /tx/submit is the public flat transfer contract and /tx/submit_batch is its batch form, used across the supported SDKs. The batch contract has a hard 64-item maximum and shares the atomic 10 tx/s per-sender admission policy with the single and generic signed routes. The node rejects every request item that omits either the transaction signature or its public key; publishing these routes does not restore unsigned transaction submission.

/worker/earnings/{address} returns only confirmed mined 0x25 receipt rows. The v0.8 production rollout forces archive mode on all six selectable public validators, disables receipt/transaction/WAL pruning in that mode, requires archive_mode=true from every earnings response, and restarts every validator after the two rollout receipts are mined before re-proving both rows. Once that cutover passes, this is complete gross reward history since the v3 recovery boundary across every later recovery epoch—not a wallet's net balance after transfers or spending. The exact history_domain field makes that all-v3 scope machine-checkable. Historical receipt rows retain their own recovery_epoch, validator_set_id, and transaction_domain; the matching top-level fields describe the current issuance/readiness context and need not equal older rows. The desktop keeps a valid zero separate from an unavailable or malformed RPC response and never turns a failed read into “0 ARC.” Projection is null with an explicit reason unless policy, confirmed history, treasury, and remaining consensus budget all permit one. These durability claims are still candidate behavior until the protected production cutover completes.

The public v2 seeds still exhibit two known API bugs: /models double-counts replicated layer coverage, and /worker/earnings/{addr} reports display arithmetic rather than mined income. The v3 candidate fixes both: coverage is a range union, while earnings count only successful retained CommunityInferenceReward receipts. A submitted reward, raw 0x16 attestation, failed receipt, or faucet POST never increments confirmed ARC. Forward projections are available only from an explicit active reward policy, confirmed receipt history, a treasury that can fund another full reward, and remaining consensus block/epoch/worker/coordinator budget; otherwise the value is null and the API returns the reason. The v0.8 reward is a protocol-capped testnet promotional compute subsidy, not customer demand or revenue. Five-of-six recomputation proves output agreement, not that a customer paid for the job. Those fixes are not live until the fleet cutover completes.

See docs/HOW-SHARDING-WORKS.md for the wire protocol.

---