Mainnet: onboarding route for a non-validator operator — need blocks + certificates from height 18,474,680 and ongoing sync (sentry peer or follow endpoint)

[Canada1991]

Hi Arc team — we operate an Arc mainnet archive full node (chain id 5042, arc-node v0.8.0, EL archive / CL --no-consensus) in --follow sync mode.

Since 2026-08-31 every follow endpoint reachable to non-onboarded operators has gone away (rpc.blockdaemon.mainnet.arc.io and rpc.drpc.mainnet.arc.io → 401, rpc.mainnet.arc.io / rpc.quicknode.mainnet.arc.io → 403, the community proxies shut down), so our node is stalled at height 18,474,679.

What we need

1. Historical blocks and certificates starting at height 18,474,680 (through the current tip), and
2. ongoing sync from there.

docs/running-an-arc-node.md describes RPC-provider nodes syncing the CL "from sentry endpoints" via --p2p.persistent-peers <SENTRY_MULTIADDRS>, with addresses "provided during onboarding". So concretely, either of these would restore us:

• A sentry / full-node multiaddr on TCP/27000 that will allowlist our node, running v0.7.0+ protocol ids, and retaining certificates back to 18,474,680 — note --full sets --prune.certificates.distance 237600 (≈33 h of blocks), so a default-pruned sentry cannot serve a node that is days behind; or
• A mainnet RPC endpoint serving eth_getBlockByNumber(n, true) and arc_getCertificate(n) from 18,474,680 to tip.

Questions

• What is the official onboarding route for a non-validator mainnet operator to obtain sentry peers or a follow endpoint? (The guide references onboarding but doesn't say where to apply.)
• If mainnet peering only opens at the 2026-09-16 public launch, could you confirm that, and whether the official mainnet --follow.endpoint URLs will be published in the operator guide? (Related: docs: mainnet operator notes — versions table row and network selection guide #260 documented the same gap in August.)
• default_rpc_sync_endpoint() in crates/malachite-app/src/config.rs returns an error for chain 5042 — is a mainnet default planned?

We're happy to share our IP and CL PeerId privately with whoever handles onboarding, and to offer our archive node (--enable-arc-rpc, arc_getCertificate served) as a public follow endpoint / sync peer once we're back at tip.

Thanks!

[osr21]

External operator here, not Circle — I can't answer the onboarding-policy questions, but I ran down the parts that are checkable against the repo and against live infrastructure, and two of the premises change the ask.

Your Q3 — confirmed, and it's broader than mainnet

default_rpc_sync_endpoint (crates/malachite-app/src/config.rs:198) matches exactly two chain IDs:

TESTNET_CHAIN_ID => "https://rpc.testnet.arc.io/",   // 5042002
LOCALDEV_CHAIN_ID => "http://localhost:8545",        // 1337
_ => return Err(eyre!("No default follow endpoint for chain ID {chain_id}. \
                       Use --follow.endpoint to specify one explicitly.")),

So --follow without an explicit --follow.endpoint aborts at startup on mainnet (5042) and on devnet (5042001) — the fallback arm isn't mainnet-specific. Worth noting for whoever adds a mainnet default: the tests cover testnet, localdev, and 999 for the error path, so nothing currently pins a mainnet arm either way.

The certificate-pruning premise looks inverted

This is the part I'd re-frame, because it may be blocking you on something that isn't true. --prune.certificates.distance defaults to 0, which disables pruning (crates/malachite-cli/src/cmd/start.rs, default_value = "0"). The 237,600 figure is applied only when a preset is passed explicitly:

// crates/malachite-app/src/main.rs:190
let certificates_distance = if cmd.full || cmd.minimal {
    PRESETS_PRUNE_CERTIFICATES_DISTANCE   // 237_600
} else { ... };

Two consequences:

1. A sentry is only certificate-pruned if its CL was started with --full/--minimal. The guide's own RPC-node example passes --full to arc-node-execution, and the arc-node-consensus start block in that same example carries no preset at all — so a sentry built to the documented example retains certificates back to genesis. "A default-pruned sentry cannot serve a node that is days behind" reads the default backwards.
2. --full buys you nothing extra here anyway: both preset flags set the same CL distance, as their own help text says — "on the CL, both --full and --minimal retain the same certificate history for now; the distinction applies at the EL layer."

So the accurate version of the ask is narrower and much easier to satisfy: a sentry whose CL was not started with a pruning preset — probably most of them.

Related, since it determines which side of a peer matters: certificates live on the CL. arc_getCertificate is an EL method (crates/evm-node/src/rpc/arc.rs) that proxies upstream to the CL's GET /commit?height=… — that's why --rpc.addr is mandatory alongside --enable-arc-rpc. EL pruning presets are therefore irrelevant to whether an endpoint can answer for 18,474,680. Handy for triage: get_certificate.rs maps a pruned or missing height to Certificate not found under a dedicated NOT_FOUND code, while transport failures map to Upstream certificate server unreachable / Timeout fetching certificate. Distinct surfaces, so you can tell "peer pruned it" from "peer blocked me" without guessing.

One requirement to hand to anyone offering you an endpoint: follow mode needs both arc_getCertificate and eth_getBlockByNumber per height (rpc_sync/client.rs:109,116), plus a WebSocket subscription for the height-status feed. A generic RPC provider that only exposes the eth namespace won't work as a --follow.endpoint, however healthy it looks.

Snapshots don't get you out of it either — I checked

The obvious workaround is to skip the gap with a snapshot restore rather than requesting five days of certificates. It isn't available, and there's a trap in checking it. arc-snapshots takes --chain arc-mainnet, but the listing query sends the bare network name (Display renders mainnet/testnet), so querying the prefixed form returns an empty list that looks like an outage. With the value the client actually sends:

query	result (2026-09-05)
?network=mainnet	{"snapshots":[],"v2Snapshots":[]} — zero objects, v1 and v2
?network=testnet	20 v1 entries + 5 v2; newest v2 at block 60,555,960, 2026-09-05T09:18:00Z
?network=devnet	empty

So there is no published mainnet snapshot of either format. Since v0.8.0's --chain resolution requires a complete storage v2 entry, on mainnet it would fail with no complete storage v2 snapshot found for mainnet; this deployment may not publish storage v2 — which reads like a format problem but is really "nothing published at all". Your gap is wider than endpoints: no mainnet snapshots, no open follow endpoint, no published sentries.

Time-critical, and earlier than the date you're planning around

Zero7/Zero8 activate on mainnet at timestamp 1789052400 — 2026-09-10 15:00 UTC, five days out and six days before the 2026-09-16 date in your post. Verified in the v0.8.0 tag, not just main: ARC_ZERO7_HARDFORK_TIMESTAMP_ACTIVATION_MAINNET and ARC_ZERO8_…_MAINNET in crates/execution-config/src/hardforks.rs:407,411, matching the CHANGELOG note that mainnet operators must be on a supporting version before it.

You're on v0.8.0, so you're covered — but two implications for a node that's currently stalled: whatever you catch up from has to be on a supporting version too, and when you do resume you'll be replaying straight across the fork boundary, so don't downgrade to chase a peer that's on something older.

Two things I couldn't confirm

• Your height and the mainnet tip. I get exactly the access state you describe — 403 (Cloudflare) on rpc.mainnet.arc.io and rpc.quicknode.mainnet.arc.io, 401 on the drpc and blockdaemon mainnet hostnames — so I can corroborate that mainnet is closed to non-onboarded operators, but not that the tip is where you think it is.
• The 2026-09-16 launch date appears nowhere in this repository. The only dated mainnet commitment in-tree is the 2026-09-10 fork above.

One correction on your citation

#260 is a docs PR I opened on 2026-08-12, not a Circle acknowledgment of the gap — and it's still open and unmerged. It deliberately avoided listing mainnet RPC or snapshot URLs precisely because none resolve publicly, so it documents the gap rather than closing it. Fair to cite for "this was already visible in August", but it carries no commitment from anyone.

For the record, the gap is reproducible rather than an oversight on your side: "provided during onboarding" appears six times in docs/running-an-arc-node.md (lines 581, 610, 639, 695, 733, 736), there is no SUPPORT.md, CONTRIBUTING.md covers only protobuf and build tooling, and the README lists no operator contact. There is no route in this repository to the thing the guide tells you to obtain.

---

Verification caveat: no cargo or rustc available to me, so the Rust findings are source review at v0.8.0 and main — CI is authoritative. The HTTP results are live checks run today and will age.

Disclosure: I'm an external community contributor, unaffiliated with Circle, with no write access to this repository. Nothing here is an official answer on onboarding or launch timing.

[Canada1991]

Thanks @osr21 — that's genuinely useful, and I've verified the checkable parts against our node and the v0.8.0 source before replying.

Certificate pruning — you're right, my premise was inverted. --prune.certificates.distance defaults to 0 (no pruning) and only the --full/--minimal presets set 237,600 (crates/malachite-app/src/main.rs:190). So the ask narrows to a sentry/full node whose CL was not started with a pruning preset — which, per the guide's own example, is probably most of them. (Ironically our own CL was started with --full, so we ourselves only retain certificates back to 18,237,079; we'll drop the preset.)

/commit — confirmed. Our CL's GET /commit?height=18474679 returns the same object as the EL's arc_getCertificate (height/round/block_hash/signatures), and a missing height gives 404 {"error":"Certificate not found"} / EL -32004, distinct from transport errors. That means any operator willing to expose or proxy their CL /commit route is a certificate source for us — we've added that as a supported upstream type in our relay, alongside JSON-RPC arc_getCertificate.

Blocks are no longer the problem. rpc.arc-scan.org (Arcscan) serves full blocks at tip for chain 5042 — we've verified block 18,474,680 there and use it as our block source — but refuses the arc_ namespace by policy. So the only thing we still need is certificates from 18,474,680 to tip (plus ongoing), which is a small payload.

Tip: Arcscan reports ~19.28M as of 2026-09-05, ~800k ahead of us and growing ~2 blocks/s, consistent with the sub-second block time.

Sept 10 fork: understood — we're on v0.8.0 and won't downgrade; whatever we catch up from must be on a supporting version too. And thanks for the correction on #260; I'll cite it as "documented the gap", not as an acknowledgment.

Updated ask for Circle (or any onboarded operator reading this): a mainnet CL /commit route or arc_getCertificate endpoint covering 18,474,680 → tip, or a sentry multiaddr whose CL runs without a pruning preset. Happy to share our IP and CL PeerId privately.

[tinwech]

Hi @Canada1991, thanks for reaching out. The official mainnet snapshot and RPC will be available following the public launch on Sep 16. The docs will also be updated at the time.