docs: fix Arc Testnet version table and document v0.7.x breaking changes for DApp developers

[sharken3948]

docs/installation.md still lists v0.6.0 as the Arc Testnet version (table and the arcup --install example). Per CHANGELOG.md, testnet node operators must use v0.7.2 since the Zero7 activation on 2026-06-18 ('Earlier versions are not supported'), and v0.7.2 is the latest published release. A new operator following the current table would install an unsupported version. Updated both references to v0.7.2.

[osr21]

Correct fix — v0.6.0 is unsupported after Zero7 and pointing new operators there would silently break their setup.

One addition worth considering: the table currently covers only node operators. Three of the v0.7.2 changes are breaking for DApp developers (not just node operators) and aren't flagged anywhere in the docs aimed at that audience:

---

1. eth_estimateGas / eth_call gas cap lowered from 50M → 30M

Any call or simulation that previously relied on the higher cap will now fail with execution reverted once the node returns an error at 30M. This is directly connected to the eth_estimateGas discussion in #198: a correct ABI is necessary but not sufficient — the estimated gas must also fit within the 30M cap. Hardcoded gas limits or cached estimates obtained from a pre-v0.7.2 node (cap = 50M) that landed between 30M and 50M will silently start failing.

2. Precompile gas cost change: "Charge gas before performing storage I/O in precompile helpers"

The CallFrom precompile (used by Memo) and any other precompile that touches storage now charges gas at a different point in execution. Gas estimates obtained against a v0.6.x node for precompile-heavy transactions (Memo subcalls, CCTP TokenMessengerV2 calls) may be too low when submitted to a v0.7.2 node. DApps that cached or hardcoded gas limits for these paths should re-estimate against the updated node.

3. JSON-RPC batch cap: 100 entries

viem's default transport sends batched JSON-RPC calls. A page load that fires many simultaneous eth_call queries (e.g. reading multiple contract slots at once — common in dashboard views) can silently tip over 100 entries and get back a -32600 error for the entire batch, with no per-request error. DApps using createPublicClient with the default batch transport should either set batch: { batchSize: 100 } explicitly or switch to a non-batching transport if their query fan-out exceeds the cap:

import { createPublicClient, http } from 'viem'

const client = createPublicClient({
  transport: http(ARC_RPC_URL, {
    batch: { batchSize: 99 },   // stay under the 100-entry cap
  }),
})

---

All three are observable by DApp teams upgrading their target testnet node version — none are in the current installation or developer docs. Might be worth a short "Breaking changes for DApp developers" callout in docs/installation.md alongside the version table, or a link to BREAKING_CHANGES.md#v072 from the developer-facing docs.

[sharken3948]

Thanks, good catch on the audience gap. I verified all three against CHANGELOG.md and BREAKING_CHANGES.md:

• Gas cap (50M -> 30M) and the 100-entry batch cap (-32600) are both documented as breaking in v0.7.2, confirmed.
• The precompile item is listed under Fixes in v0.7.2 and isn't flagged as breaking, so I phrased it more generally in the callout. The documented gas-estimation impact is actually the EIP-2929 warm/cold pricing change in v0.7.0. Side note: the v0.7.0 changelog links to BREAKING_CHANGES.md#v070 for that impact, but no such entry exists there, so that cross-reference is dangling.

Pushed a "Breaking changes for DApp developers" callout under the version table, linking to BREAKING_CHANGES.md#v072. Kept it short and left client-specific workarounds (like viem batch config) out of installation.md since that feels like BREAKING_CHANGES territory.

[osr21]

Good call on the dangling BREAKING_CHANGES.md#v070 anchor — that's a real dead link worth a follow-up. The fix is either to create the v070 section in BREAKING_CHANGES.md (with the EIP-2929 warm/cold pricing detail) or update the v0.7.0 changelog link to the nearest existing anchor. Since the EIP-2929 change is already captured informally in the v0.7.2 precompile callout you added, creating the section is probably the cleaner path and avoids a version-skew in the cross-reference.

Two small things on the callout text worth checking:

1. The --rpc.gascap note may confuse DApp developers

"Calls that need more than 30M gas fail unless the node raises --rpc.gascap"

Node operators can raise the cap; DApp developers cannot. For a developer reading installation.md, this sentence implies a client-side escape hatch that doesn't exist for them — if their call genuinely needs >30M gas and they don't control the node, they're blocked with no workaround. Worth reframing something like: "Calls or simulations that previously relied on the higher 50M cap will fail. Node operators can raise the limit with --rpc.gascap; DApps should optimize contract calls to stay within 30M."

2. The viem batch workaround belongs in BREAKING_CHANGES.md#v072

Agree with keeping it out of installation.md — but it's currently absent from BREAKING_CHANGES.md too (the -32600 entry just states the cap, no mitigation). The actual fix (batch: { batchSize: 99 }) is the single actionable thing a DApp dev needs and the most likely thing they'll search for. Worth adding it there. Ethers.js users are largely unaffected since BrowserProvider/JsonRpcProvider doesn't auto-batch — only explicit JsonRpcBatchProvider users hit this — so the note can stay viem-scoped.

One real-world data point: CCTP v2 depositForBurnWithCaller on Arc consistently estimates 140–180K gas against a v0.7.2 node, well under the new 30M cap. The risk for CCTP-heavy DApps is stale estimates from a pre-v0.7.2 node (pre-reorder precompile costs), not the cap itself — which is my point about re-estimating after the upgrade correctly targets.

[sharken3948]

Thanks for the careful read, all three points landed. Status:

1. Agreed the gascap sentence implied a client-side escape hatch that doesn't exist. Reworded as suggested and pushed (e22e7fc).

2. On the batch note: while verifying the viem detail I found the library behavior is actually the reverse of what we both assumed. viem's default http transport does not batch; batching is opt-in, and when enabled batchSize defaults to 1000, which is what overflows the 100-entry cap. ethers v6 JsonRpcProvider batches by default but with batchMaxCount 100, so it sits exactly at the cap out of the box. I made the installation.md line client-agnostic ("clients with JSON-RPC batching enabled should keep batch size at or under 100") and the library-specific detail can live in BREAKING_CHANGES.md with correct framing.

3. On the anchor: the v0.7.0 section actually exists in BREAKING_CHANGES.md, so the link resolves. What's missing is the EIP-2929 gas-estimation entry the changelog promises there. Planning a small follow-up PR adding that entry plus the batching mitigation under v072, unless maintainers prefer it in this one.

Also appreciate the CCTP gas data point, confirms the risk there is stale pre-v0.7.2 estimates rather than the cap itself.

[osr21]

Good correction on the viem/ethers batching behavior — that's the reverse of what we assumed and matters for the BREAKING_CHANGES entry.

Confirming from direct ethers v6 usage on Arc: JsonRpcProvider batches automatically with batchMaxCount: 100 by default, which is exactly where the cap sits. The mitigation for ethers v6 users is the batchMaxCount option on the provider constructor:

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider(ARC_RPC_URL, undefined, {
  batchMaxCount: 50, // stay safely under the 100-entry cap
});

One distinction worth flagging for the BREAKING_CHANGES entry: BrowserProvider (the MetaMask/window.ethereum path) is unaffected — it routes through the extension's own transport which doesn't support JSON-RPC batching. The risk is specifically to JsonRpcProvider instances used for read-only calls, which is the common pattern for dashboard-style reads (e.g. fetching all market reserves + user positions in parallel). Those calls are the most likely to fan out past 100.

On point 3: supporting the follow-up PR approach — keeping the EIP-2929 entry out of this PR is cleaner since this one is scoped to the version table. The gas-estimation impact is real enough (we saw warm/cold repricing affect precompile-adjacent calls after moving to a v0.7.2 node) that the entry in BREAKING_CHANGES.md#v070 is worth having standalone rather than tucked into the v0.7.2 callout.

[sharken3948]

Agreed on all three. Will fold the ethers batchMaxCount mitigation and the BrowserProvider vs JsonRpcProvider distinction into the follow-up PR, with the EIP-2929 entry standalone under v070. Thanks for confirming the ethers behavior against a live Arc node.

[sharken3948]

Rebased onto main and bumped the documented version to v0.7.3, following the release on 20 July.

For context on why this matters: the Versions table on main still points to v0.6.0, which is two network upgrades behind. Per BREAKING_CHANGES.md, testnet operators must run at least v0.7.2 since the Zero7 activation on 18 June, so anyone following the install docs today would end up on an unsupported version and desync.

The DApp-facing callout is unchanged, since v0.7.3 introduced no new breaking changes. It now reads "from v0.6.0 to v0.7.3" so the listed v0.7.x changes line up with the upgrade path a reader is actually taking.

[osr21]

The v0.7.3 bump and rationale make sense — good to have the install docs match the actual minimum for a syncing node before this lands.

The diff looks correct end-to-end:

• Both the version table and the arcup --install example are updated (easy to miss the latter)
• The gas cap note correctly draws the operator/DApp boundary — the reword from our earlier thread landed well
• The batch cap note is client-agnostic, which is the right call given the viem/ethers behavior turned out to be reversed from what we initially assumed
• The precompile note now covers both the v0.7.0 EIP-2929 warm/cold pricing and the v0.7.2 gas-charging-order change in one callout, which is cleaner than splitting them

One data point for the follow-up BREAKING_CHANGES PR on the precompile re-estimation risk: running our keeper against a v0.7.2 node, the depositForBurnWithHook call on TokenMessengerV2 (Arc CCTP) went from ~155K gas (estimated on a pre-v0.7.2 node) to ~172K after re-estimation. Still comfortably under the 30M cap, but enough of a shift that a hardcoded gas limit from before the upgrade would have started underpaying and causing failed submissions. The callWithMemo path via Arc's CallFrom precompile showed a similar delta. Those two paths — CCTP messenger and memo subcalls — are likely the most common precompile-adjacent cases DApp developers will hit.

For the BREAKING_CHANGES follow-up: the agreed scope was (a) EIP-2929 standalone entry under v0.7.0, (b) ethers batchMaxCount mitigation + BrowserProvider carve-out under v0.7.2. Happy to open that PR if it's useful, otherwise will leave it to you since this one is already scoped cleanly.