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

Activity

1. osr21 commented on Sep 5, 2026

   

   osr21

   on Sep 5, 2026

   More actions

   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.
2. Canada1991 commented on Sep 6, 2026

   

   Canada1991

   on Sep 6, 2026

   Author

   More actions

   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.
3. tinwech commented on Sep 8, 2026

   

   tinwech

   on Sep 8, 2026

   More actions

   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.
4. huklaa commented on Sep 10, 2026

   

   huklaa

   on Sep 10, 2026

   More actions

   Hi, I would like to work on this issue. Could you assign it to me?
5. vishalsolana

   added a commit that references this issue on Sep 16, 2026

   Point mainnet at rpc.mainnet.arc.io - today is Circle's confirmed lau…

   ...

   034861c
6. eniolasonowo commented on Sep 19, 2026

   

   eniolasonowo

   on Sep 19, 2026

   More actions

   @Canada1991 Goodday, I want to share CL PeerId / IP
7. cossin commented on Oct 19, 2026

   

   cossin

   on Oct 19, 2026

   More actions

   Hi @tinwech and Arc team, I’d also like to ask about the onboarding process for independent mainnet RPC node operators.

   My project currently uses QuickNode, but network latency has led me to explore running a self-hosted RPC node with direct sentry peering rather than relying on an upstream RPC follow endpoint. My preferred deployment location is Hong Kong, with Singapore as an alternative.

   Could you please clarify:

   • Are independent operators eligible for mainnet sentry peering?
   • Who should I contact, or which form should I use to apply?
   • Are sentry peers available in Hong Kong or Singapore?
   • What are the technical requirements, access policies, and any associated fees?
   • Where can I obtain the recommended mainnet snapshot for initial synchronization?

   I can provide my server IP and node Peer ID privately once the deployment requirements are confirmed. If this issue isn’t the right place for this request, a pointer to the appropriate team would be appreciated.

   Thanks!
8. adizere commented on Oct 26, 2026

   

   adizere

   on Oct 26, 2026

   More actions

   Hey,
   Thanks for your inquiry. Can you provide more details on what is the problem you have with the current latency and why do you need to fix it?