We publish the tail, not just the headline
Most providers advertise a p50 and stay quiet about the p99. A published tail is a claim only a confident operator makes, so it is one we make on Arc.
Commitments, credited under the SLA
Every figure below is a commitment per interface, measured by synthetic probes outside our own infrastructure. Uptime misses are credited automatically under the published SLA. For an incident or a regional question, contact the engineers who run the fleet directly.
The numbers we are held to
Uptime
Scale and Enterprise, credited against the SLA
99.99%
Pro targets 99.9%
JSON-RPC latency p50
From the nearest core region
< 10 ms
Archive reads included, not excluded
JSON-RPC latency p99
Published continuously
< 60 ms
The tail, not just the headline
Block to stream delivery p99
Commit to the gRPC client, end to end
< 150 ms
Measured from the commit, not from our ingest
Certificate availability
arc_getCertificate cached at commit
Every block
A missing certificate is an incident
Webhook delivery p99
With a replayable log
< 1 s
Safe at one confirmation on Arc
What we publish
Not a green tick and a percentage. The things an operator actually needs to size their own risk.
Per-region, per-interface latency
p50, p95 and p99 for JSON-RPC over HTTPS and WebSocket, and for gRPC streams, from synthetic probes outside our own infrastructure.
Historical incident log
Every incident with a written post-mortem, kept permanently. No quiet deletions once a quarter closes.
Head lag behind Arc
How far our nodes trail the network tip, per region. On a half-second chain even one block of lag is visible, so we show it.
Gas floor rejections
How many transactions we rejected for being below the 20 Gwei floor. Each one is a payment that would otherwise have vanished without a receipt.
Gap reports
The signed completeness statements behind stream and sink deliveries, so a skipped block is provable rather than suspected.
Publishing post-mortems and floor rejections is not generosity. In a market where providers still disagree on how arc_getCertificate behaves, being the participant whose numbers can be checked is the fastest route to being the one people trust.
Hold us to it.
Every correctness claim on this site is reproducible against Arc's own documentation and a public endpoint. Check ours, then check anyone else's.