Skip to content

Take mppx 0.16.0 and viem 2.57.13, release 3.1.7 - #166

Merged
vvillait88 merged 1 commit into
mainfrom
sweep-2026-10-29
Oct 29, 2026
Merged

vvillait88 merged 1 commit into
mainfrom
sweep-2026-10-29

Conversation

@vvillait88

@vvillait88 vvillait88 commented Oct 29, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Maintenance sweep for the coupled payment set: mppx 0.15.0 to 0.16.0 and viem 2.57.11 to 2.57.13 (exact pins, with the viem override), plus typescript-eslint 8.72.1. Version 3.1.7.

Worked with: Varun.

Why a release: viem and mppx are both bundled into dist (the literal import('mppx') calls are inlined). Building main and this branch differs only in viem's inlined isHex helper and its version string; every bundled mppx file is identical between 0.15.0 and 0.16.0 (review confirmed it file by file). So the viem patch reaches the published artifact.

What was checked in mppx 0.16 before taking it:

  • The Tempo zero-amount proof's EIP-712 domain stays at version 3 (dist/tempo/internal/proof.js), so agent, verifier and stores stay compatible.
  • mppx/attestation became mppx/identity, and Mppx.create({ attestation }) now throws. Nothing in this library or the stores uses attestation.
  • The client now refuses to sign a zero-amount Tempo proof unless the challenge realm is the server's hostname. The verifier side is unaffected, and every store's live challenge carries its own hostname as the realm (fullenrich read from a live 402; martin-estate and sayer-and-stone set realm to their app host).
  • allowKeyAuthorization was removed from fee-payer policy; nothing here sets it.

Releasing follows the merge (tag v3.1.7). pay takes the same set, the storefronts then take 3.1.7, and a live settle on Base, Tempo and Solana closes the coupled move.

Type of change

  • Bug fix (no breaking change)
  • New feature (no breaking change)
  • Breaking change (existing callers must update)
  • Docs, tests, or internal maintenance only

Public API

None. Peer ranges are unchanged.

Test plan

bun run lint, typecheck, knip, test and build all exit 0. bun install --frozen-lockfile is a no-op (670 installs across 690 packages). OSV over bun.lock reports no issues. Dist diff against main: only the bundled viem code and its version string.

Checklist

  • Tests cover the new behavior, and the suite passes locally (no behavior change; suite passes)
  • Lint, format, and type checks pass
  • Docs and README examples updated if the public surface changed (no public surface change)
  • No secrets, credentials, or personal data in the diff or the tests

viem is bundled into dist, so the patch reaches the published artifact.
mppx 0.16 keeps the Tempo proof domain at version 3 and removes nothing
this library uses; its new client-side realm check matches every store's
challenge realm. typescript-eslint 8.72.1 rides along.
@vvillait88

Copy link
Copy Markdown
Contributor Author

Review (fresh context, read-only)

Verdict: approve. One correction to the PR body's wording, no defect.

1. mppx is bundled into dist too, not only viem (record fix, no code change). tsup externalizes only dependencies and peerDependencies, and mppx is a devDependency, so the literal import('mppx') sites (_mppx_receipt.ts, checkout.ts) get inlined. The dist/index.mjs.map on this branch lists 24 sources under node_modules/mppx/dist/ (Challenge, Credential, Receipt, PaymentRequest, Method, evm/, x402/, Store, Mcp, zod, and others). I compared each of those 24 files between the unpacked mppx 0.15.0 and 0.16.0 tarballs: all byte-identical. mppx/zod stays at zod 4.6.7 in the lock (that line did not change), and the bundled ox is the top-level 0.14.45 rather than viem's nested ox (0.14.57 to 0.14.59, not in any sourcemap). So the dist diff really is viem only, but by evidence about mppx rather than because mppx is absent. The runtime-resolved mppx (createMppxServer's dynamicImport('mppx/server'), the signer's import(moduleName)) is the merchant's own install.

2. Peer ranges. mppx is not a peer at all, so there is no range to move; viem is not a peer either. @solana/mpp >=0.7.0 and its own mppx >=0.5.5 peer admit 0.16.0. Nothing in src/ uses attestation, allowKeyAuthorization or trustedTempoProofRealms. runWithMppxFailureCapture keys on the string 'mppx: internal verification error', which server/Mppx.js still logs in 0.16.0.

3. mppx 0.16 changes that reach merchants on this library.

  • Proof EIP-712 domain: dist/tempo/internal/proof.js returns { name: 'MPP', version: '3', chainId } in both 0.15.0 and 0.16.0.
  • Server default realm when none is configured is still the request hostname, so the new client realm check is satisfied by default.
  • allowKeyAuthorization removal loosens fee-sponsor policy: a sponsored transaction may now carry a keyAuthorization (bounded by maxGas and maxTotalFee). Not configured here; worth knowing for any store that sponsors Tempo fees.
  • Tempo charge verification now compares split amounts as integers (BigInt(split.amount).toString()); strictly more permissive for leading-zero encodings.

4. Live realms. Unauthenticated POST probes, nothing paid: fullenrich.agentscore.com/company/lookup answers 402 with realm="fullenrich.agentscore.com" on both its tempo and solana challenges; agents.martinestate.com/purchase and agents.sayerandstone.com/purchase answer 402 with their own hostnames as realm. Minor, outside this PR: both wine and jewelry stores derive realm from new URL(APP_URL).host, which includes a port, while mppx's check compares against hostname. In production there is no port so it matches; against a local store on localhost:3003, a 0.16 client will refuse a zero-amount Tempo proof.

5. Version. 3.1.6 to 3.1.7; git grep 3.1.6 outside the lock returns nothing.

Gates I ran on the PR head: bun run typecheck exit 0; bun run test exit 0, 109 files passed (1 skipped), 1641 tests passed (4 skipped).

@vvillait88
vvillait88 merged commit 85a58be into main Oct 29, 2026
9 checks passed
@vvillait88
vvillait88 deleted the sweep-2026-10-29 branch October 29, 2026 03:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant