[vvillait88]

Summary

Release 3.1.4, from the 2026-10-22 maintenance sweep.

• @agent-score/sdk: ^2.9.2 to ^2.9.3, the SDK release from this sweep. Varun asked for every package to be bumped and tagged in this sweep, so this publishes even though the library's own code is unchanged.

• mppx: 0.13.5 to 0.15.0. Merchants install mppx themselves. This bump runs the verifier suite against the release the storefronts take in the same sweep.

  • The Tempo proof's EIP-712 domain is unchanged at version 3.
  • mppx is neither a dependency nor a declared peer, so each merchant's own mppx pin decides what runs.
  • The library's verifier paths, checked against 0.15.0:
    • src/payment/mppx_server.ts uses Mppx.create, tempo.charge, tempo.session and compose. mppx_stripe.ts loads mppx/server.
    • The receipt helpers use Credential.fromRequest, Credential.extractPaymentScheme and Receipt.
  • The 0.15.0 realm requirement applies only to standalone verifyCredential and validateCredential, which nothing here calls.
  • The compose dispatch change does not change the target, because each method has one handler.
  • The 64 KiB cap returns null from extractPaymentScheme, which is already handled.

• viem: 2.57.7 to 2.57.8, exact dev pin and override.

  • 2.57.10 exact-pins ox 0.14.57, which is inside the 24h release-age soak.
  • Its changes are Tempo configurable accounts only.

• Dev only: jose 6.2.13, knip 6.42.1 and typescript-eslint 8.72.0.

• packageManager: bun@1.4.4.

• Checked and current: the @x402 set at 2.28.0.

• Held back: TypeScript 7. typescript-eslint still peers typescript <6.1.0.

Worked with Varun.

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

Unchanged. Every peer range is untouched. The runtime dependency moves to @agent-score/sdk ^2.9.3.

Test plan

• bun run lint, typecheck, knip, test (1637 passed, 4 skipped) and build all pass. The suite now runs against mppx 0.15.0 and viem 2.57.8.
• osv-scanner on bun.lock: no issues found.
• Live settle: across Base, Tempo and Solana against FullEnrich, run once the store takes this set in the same sweep. Its result will be recorded on pay's release PR.

Checklist

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

[vvillait88]

Review of 8d025e6 (read-only). No blocking findings. One correction to the body is worth making before merge, because the body is the public record of why this move is safe.

Manifest

• dependencies is only @agent-score/sdk ^2.9.3.
• mppx 0.15.0, viem 2.57.8 and jose ^6.2.13 are in devDependencies, and the viem override is 2.57.8.
• peerDependencies and peerDependenciesMeta have no diff lines.
• Every other lock change traces to knip 6.42.1 (oxc-parser 0.154.0 with its bindings, unbash 6.0.1, the nested rolldown/@oxc-project/types entry removed) or to typescript-eslint 8.72.0. mppx and viem keep their ox pins (0.14.45 and 0.14.56).

Correction: the body undercounts the mppx API surface

The body says the only mppx APIs this library calls directly are Credential.fromRequest, Credential.extractPaymentScheme, Receipt.serialize and Receipt.deserialize. Grepping src/ at the head for every mppx import turns up more:

• src/payment/mppx_server.ts dynamically imports mppx/server. It then calls Mppx.create({ methods, secretKey }), tempo.charge(...) and tempo.session(...), and composeMppxRequest calls mppx.compose(...).
• src/stripe-multichain/mppx_stripe.ts also loads mppx/server.
• src/signer.ts and src/stripe-multichain/pay_to_address.ts use Credential (fromRequest, extractPaymentScheme).
• src/_mppx_receipt.ts and src/checkout.ts use Receipt.

So 0.15.0's verifier changes do run through commerce's code when a merchant has 0.15.0 installed. The reason they cannot change behavior through this release is that mppx is not a declared dependency or peer: the merchant's own mppx pin decides, and 3.1.4 ships no mppx at all. Suggested wording: "commerce wires the mppx server (Mppx.create, tempo.charge, tempo.session, compose) and reads Credential/Receipt; mppx is installed by the merchant, so this release changes no merchant's mppx; the suite runs against 0.15.0."

What 0.15.0 changes on those paths, read from the dist diff

• Realm. The new requirement sits inside the standalone verifyCredential / validateCredential path in server/Mppx.js. It fails when no realm is configured and no capturedRequest is passed. src/ has zero calls to either. The route handlers that compose and the per-method handlers build pass a captured request, so they are not affected. The local storefront checkouts have zero calls too.
• Compose dispatch. A handler without a static scope now matches on the meta merged with the route scope, and dispatch compares only the configured binding fields. commerce composes one handler per method and intent, so the dispatch target does not change. This fixes the multi-handler cases.
• Compose 200 result. The 200 result now also carries challenge. commerce tells the outcomes apart on status (checkout_compute_first.ts) and on 'withReceipt' in raw (_mppx_receipt.ts), never on 'challenge' in, so the new field is harmless.
• Failure capture. runWithMppxFailureCapture keys on the literal 'mppx: internal verification error', which is still present once in 0.15.0's server/Mppx.js. Typed failure codes keep working.
• Expiry. The Tempo server charge now runs Expires.assert right before the sponsored broadcast and after the proof replay check, and Expires moves from < to <=. A credential at or past its expiry now gets a 402 instead of settling. That changes behavior only at the boundary, and in the safe direction.
• 64 KiB cap. The cap applies to extractPaymentScheme as well as fromRequest (via deserialize). Above 64 KiB, extractPaymentScheme returns null, which pay_to_address.ts already treats as "no Payment credential".
• Sponsor policy. The fee payer now throws if a sponsor policy's maxValidityWindowSeconds is not an integer of at least 15. commerce sets no sponsor policy, so this reaches only a merchant that configures one directly.
• The Tempo zero-amount proof domain is byte-identical (dist/tempo/internal/proof.js, version 3).

Pre-existing nit (not this PR)

The createMppxServer docstring says "mppx is an OPTIONAL peer dependency", but package.json declares no mppx peer. Either declare it as an optional peer or reword the docstring.

Release and checks

• 3.1.4 is unpublished: npm view @agent-score/commerce@3.1.4 returns E404, the latest is 3.1.3, and the latest tag is v3.1.3.
• gh pr checks 159: 9 rows, all pass. They are Analyze x3, CodeQL, Dependency Scan, ci, and node-compat 22/24/26.
• osv-scanner 2.7.0 on the lock:
  • Base a5441c5: 842 packages, no issues.
  • Head 8d025e6: 841 packages, no issues.

[vvillait88]

Body corrected: it now lists the server-side mppx calls (Mppx.create, tempo.charge, tempo.session, compose) and gives the real reason the release is safe, which is that mppx is not a declared dependency or peer, so each merchant's pin decides.