Blocked on upstream: @x402/svm must move to @solana-program ^0.16/^0.18 before the kit 8 bump is cheap

[VickyXAI]

#358 bumps @solana/kit 5.5.1 → 8.2.0. It is safe to sign with and it costs 26% of the bundle. The cost is not intrinsic to kit 8 — it is caused by one upstream lag, and it disappears on its own when that lag clears. This issue records the unblock condition so the work is not repeated.

Why it costs anything

@x402/svm@2.21.0 (and 2.25.0, current) still declares:

"@solana-program/token": "^0.9.0",
"@solana-program/token-2022": "^0.6.1",
"@solana-program/compute-budget": "^0.11.0"

Those three peer on @solana/kit: "^5.0", so bumping kit alone leaves three unmet peers directly on the payment-signing path. #358 forces them forward with overrides to 0.16.1 / 0.16.1 / 0.18.1, which peer on ^8.0.0. That override-driven nesting is what duplicates the stateless @solana/* packages — 20 copies of @solana/errors, 9 of codecs-core — and pushes dist/cli.js from 8.00 MB to 10.11 MB.

@solana/kit@8.2.0 installed on its own resolves to exactly one @solana/errors. kit 5.5.1 with @x402/svm and the old @solana-program versions also resolves to one. The duplication exists only in the overlap.

Unblock condition: @x402/svm publishes a release whose own @solana-program/* deps are on ^0.16 / ^0.18. At that point #358 becomes a one-line version bump, the overrides come back out, and there is no bundle cost. @x402/svm's own kit peer is already >=5.1.0, not ^5.0, so it needs no waiver.

Two mitigations already tried and failed — do not retry

1. overrides pinning all 20 @solana/* subpackages to 8.2.0 → bundle unchanged at 10.11 MB.
2. An esbuild onResolve plugin canonicalising ^@solana/ through createRequire → worse, 11.36 MB / 21 copies of errors.

What is already settled, so nobody re-derives it

• Signing is byte-identical. Driving @x402/svm's real ExactSvmScheme.createPaymentPayload and ExactSvmSchemeV1.createPaymentPayload with a fixed keypair, fixed blockhash and fixed memo against a stubbed RPC produces identical signed wire transactions under 5.5.1 and 8.2.0.
• All 32 symbols @x402/svm and ClawRouter import from kit / @solana-program/* exist in 8.2.0. Zero removed, zero renamed.
• The 2026-03-06 failure mode does not recur: one copy each of @solana/signers, @solana/transactions, @solana/transaction-messages. build: guard the invariant that actually held on 2026-03-06 #375 now enforces that as a build guard, so a future bump cannot regress it silently.
• The duplicated packages are stateless — @solana/errors identifies by e.name === "SolanaError", never instanceof.
• Peers are clean under the overrides: npm ls reports zero invalid, zero unmet non-optional.

What the bump buys, honestly

Nothing demonstrable on this repo today. The content-length defect in @solana/rpc-transport-http@5.5.1 is real — body.length is UTF-16 code units, not bytes — but it under-states only for non-ASCII, and every Solana RPC body on this path is ASCII (base58 addresses, base64 transactions, ASCII method names), where String.length equals the byte length and undici accepts the header. #352's own description called it "sensitive to … if", a hardening claim rather than a reproduced failure; the Solana fetch failed that was reproduced was an unreachable RPC endpoint, fixed separately in v0.12.271.

So there is no urgency, which is what makes waiting the right call rather than a deferral.

When it does land

One real paid Solana call through the built bundle before release. The byte-identical result proves construction and signing agree between kit versions; it does not prove the facilitator accepts the transaction, and no test in the repo signs an SVM payment — src/x402-sdk.test.ts only asserts registerExactSvmScheme doesn't throw.

Also re-lock and rebuild dist/, which is committed here; #358 as it stands does not.