chore: viem version floors are too loose — pnpm re-resolves to older versions on every lockfile refresh

[ryanRfox]

Problem

viem version pins across the x402 monorepo are too loose. ^-ranges with low floors don't survive pnpm install re-resolutions: the solver picks the lowest version that satisfies every constraint, and a one-time lockfile bump quietly reverts the next time a sub-package lands with a lower floor.

Concrete consequences:

1. PR chore(typescript): bump viem to 2.47.12 across all packages #2013 bumped lockfiles to viem 2.47.14, but bump eroded. Subsequent PRs (Batch-settlement TS sdk #2061, feat: added cdk to example #2197, others) added sub-packages pinned at ^2.39.x / ^2.43.x. pnpm re-resolved on later installs and the solver picked the lowest acceptable version across constraints. Direct viem resolutions in examples/typescript/pnpm-lock.yaml and e2e/pnpm-lock.yaml rolled back from 2.47.14 to 2.40.3 / 2.43.5 and 2.31.6 / 2.45.1 respectively.

2. viem updates published after the floor don't reach our builds. Every package.json that pins viem at ^2.x (where x is older than the latest) lets the solver downgrade. Each pnpm install re-resolution can drop the lockfile back to the floor. New viem versions — bug fixes, new chain definitions, perf work — silently fail to land.

3. The regression recurs on every new sub-package. Any future package.json added with a lower viem floor (typo, copy-paste, lazy template) re-creates the same erosion. There is no current gate that prevents this.

4. Downstream consumers of @x402/* inherit the floor. Published peerDependencies carry the package.json floor, not the lockfile resolution. End-users running pnpm install against the next SDK release see the same loose constraint.

Goals

• Every package.json listing viem under dependencies / devDependencies / peerDependencies pins a floor of ^2.48.11 (or tighter).
• Every direct viem resolution in typescript/pnpm-lock.yaml, examples/typescript/pnpm-lock.yaml, and e2e/pnpm-lock.yaml reads 2.48.x.
• Future PRs cannot silently re-introduce the regression: gate criterion is ^2.48.11 (or tighter) for any new viem-using package.json.

Non-goals

• viem source-of-truth changes upstream.
• Transitive viem versions pinned by other packages' constraints (e.g., @walletconnect/utils at 2.23.2). Those follow their own constraint chains and remain unchanged.
• Continuous freshness automation (Dependabot / Renovate). Tracked separately in chore: add scoped viem dependabot updates for /typescript #2002. Floor tightening is a durable fix; freshness automation is a complement.

Success criteria

• pnpm install --frozen-lockfile clean across typescript/, examples/typescript/, and e2e/.
• pnpm build clean for the typescript/ workspace.
• Every direct viem entry in all three lockfiles resolves to 2.48.x.
• The next sub-package added to the monorepo with a viem dependency cannot regress the lockfile below the floor.

Scope of impact

Affects every contributor running pnpm install against this monorepo (lockfile churn) and every downstream consumer of the next @x402/* SDK release (gains the bumped viem on their own next install). No runtime API change.

Related

• chore(typescript): bump viem to 2.47.12 across all packages #2013 — first viem lockfile bump; tightened lockfile but not floors. Erosion documented above.
• chore: add scoped viem dependabot updates for /typescript #2002 — Dependabot config for /typescript viem updates. Complementary freshness layer; does not tighten package.json floors.
• Stale viem/chains across all TS packages — new chains broken until lockfile updated #1971 — original problem statement on stale viem/chains across published packages. CLOSED.