Adds new @metamask/x402 package

[jeffsmale90]

📝 Description

In this PR I propose a new package @metamask/x402 that implements ERC-7710 payment utilities for both client and server.

By moving this into a separate package, rather than exposing it via a package level export such as @metamask/smart-accounts-kit/x402, we don't add the x402 dependencies for every @metamask/smart-accounts-kit consumer.

In the client, where the x402Erc7710Client is instantiated, a delegationProvider is specified. Ideally, the caller would be able to instantiate a DelegationProvider from the smart accounts kit that would abstract most of this complexity away, but I haven't implemented that layer yet. I would love to be able to do something like this:

new x402Erc7710Client({
    delegationProvider: new RedelegatingProvider({ account, parentPermissionContext })
});

And the RedelegatingProvider would create a delegation specific to the PaymentRequirements redelegating the authority from parentPermissionContext.

---

Note

Medium Risk
Mostly additive, but it introduces a new workspace package plus new @x402/*/transitive dependencies (e.g., newer viem, zod) via yarn.lock, which could impact monorepo installs/builds if dependency resolution changes.

Overview
Adds a new workspace package, @metamask/smart-accounts-kit-x402, providing x402 adapters for ERC-7710: a client (x402Erc7710Client) that builds delegation-based payment payloads (with validation/normalization and optional fallback handling), a server helper (x402Erc7710Server) that injects assetTransferMethod: "erc7710" and validates/normalizes facilitatorAddresses, and an ExactEvmScheme wrapper (x402ExactEvmErc7710ServerScheme) that conditionally applies the ERC-7710 enhancements.

Wires up package scaffolding (README, dual-license files, tsup/tsconfig, eslint naming exceptions for x402*, Vitest coverage tests) and updates .github/CODEOWNERS and yarn.lock to include the new workspace and its dependencies.

^{Reviewed by Cursor Bugbot for commit f3a5070. Bugbot is set up for automated code reviews on this repo. Configure here.}

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​x402/​core@​2.12.0
	@​x402/​evm@​2.12.0

View full report

[socket-security]

Warning

MetaMask internal reviewing guidelines:

• Do not ignore-all
• Each alert has instructions on how to review if you don't know what it means. If lost, ask your Security Liaison or the supply-chain group
• Copy-paste ignore lines for specific packages or a group of one kind with a note on what research you did to deem it safe.
  @SocketSecurity ignore npm/PACKAGE@VERSION

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Potential code anomaly (AI signal): npm ox is 100.0% likely to have a medium risk anomaly Notes: This module implements parallel WebAssembly computation using Node worker_threads and browser Web Workers, including dynamic worker script execution (Node eval:true and browser Blob URL). It communicates only via postMessage and does not show network exfiltration, credential theft, or persistence within this snippet. The main risks are supply-chain/execution boundary concerns from dynamic worker code and potential CPU/DoS impact if the mining parameters are attacker-influenced. Overall: likely intended for compute work, but should be reviewed and guarded with strict input controls and hardened worker creation. Confidence: 1.00 Severity: 0.60 From: ? → npm/@x402/evm@2.12.0 → npm/ox@0.14.20 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/ox@0.14.20. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Potential code anomaly (AI signal): npm ox is 100.0% likely to have a medium risk anomaly Notes: This fragment is primarily a CPU-intensive proof-of-work/salt-mining implementation using worker-thread parallelism plus an async fallback. It includes input validation, structured error propagation, and abort handling, and it does not show classic malware behaviors (no network/file/process/persistence or dynamic execution in the snippet). The dominant security concern is potential resource-exhaustion/DoS if untrusted callers can control workerCount/count/chunkSize, and secondary concern is leakage of progress/rate metrics into application callbacks/logging. Overall: likely intended PoW functionality but potentially abuse-prone in the wrong threat model. Confidence: 1.00 Severity: 0.60 From: ? → npm/@x402/evm@2.12.0 → npm/ox@0.14.20 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/ox@0.14.20. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Potential code anomaly (AI signal): npm ox is 100.0% likely to have a medium risk anomaly Notes: This dependency is a worker-based “salt mining”/proof-of-work compute engine that loads an embedded WebAssembly payload and runs a CPU-intensive loop in Node worker_threads or browser Web Workers, communicating progress and results via postMessage. There is no direct evidence in this fragment of network exfiltration, credential access, persistence, or system modification. The main security concerns are (1) dynamic worker code execution (Node worker eval:true and browser Blob URL execution) and (2) cryptomining-like resource consumption that can be abused for CPU exhaustion. The embedded WASM module itself should be reviewed to confirm it contains only the expected computation and no hidden side effects. Confidence: 1.00 Severity: 0.60 From: ? → npm/@x402/evm@2.12.0 → npm/ox@0.14.20 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/ox@0.14.20. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Potential code anomaly (AI signal): npm ox is 100.0% likely to have a medium risk anomaly Notes: This dependency is a cross-platform worker harness that executes embedded WebAssembly to perform a “salt mining” computation and returns progress/results to the caller via message passing. In this file, there is no clear evidence of classic malware behaviors such as network exfiltration, credential theft, or filesystem/system sabotage. The most notable supply-chain/security concerns are dynamic code execution patterns (Node Worker with eval:true and browser Blob URL worker scripts) and the potential for CPU-intensive abuse (computational mining-like workload) if invoked in an unauthorized context or with adversarial parameters. Overall: moderate security risk driven by execution surface and availability impact rather than direct data-stealing. Confidence: 1.00 Severity: 0.60 From: ? → npm/@x402/evm@2.12.0 → npm/ox@0.14.20 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/ox@0.14.20. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Potential code anomaly (AI signal): npm viem is 100.0% likely to have a medium risk anomaly Notes: The code implements a cross-chain deposit flow with proper validations, artifact reads, and on-chain interactions. There is no evidence of hidden backdoors, data exfiltration, or malware. The main security considerations relate to token approval logic and correct configuration of flags to avoid granting excessive allowances. Overall, the module appears legitimate for a bridge deposit flow, with moderate risk primarily around configuration of approvals and correct handling of gas/fees. Confidence: 1.00 Severity: 0.60 From: ? → npm/@x402/evm@2.12.0 → npm/viem@2.49.2 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/viem@2.49.2. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Potential code anomaly (AI signal): npm ws is 100.0% likely to have a medium risk anomaly Notes: The code implements a standard EventTarget-like mixin for wrapping event listeners and dispatching events to user callbacks. There are no suspicious patterns such as dynamic code execution, hardcoded secrets, or network activity. The risk is contingent on what the consumer does inside their handlers; the snippet itself does not introduce malware or data leakage mechanisms beyond normal event dispatch. Overall security risk is low in isolation. Confidence: 1.00 Severity: 0.60 From: ? → npm/@x402/evm@2.12.0 → npm/ws@8.18.3 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/ws@8.18.3. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Potential code anomaly (AI signal): npm zod is 100.0% likely to have a medium risk anomaly Notes: No explicit network exfiltration, reverse shell, or credential theft is present in this fragment. However, the code assembles and compiles arbitrary code via the Function constructor and invokes passed-in functions immediately (twice). That behavior constitutes a strong dangerous primitive (arbitrary code execution) which can be abused if any inputs (strings or args) are attacker-controlled. Treat this module as risky in threat models where inputs are not fully trusted; review call sites and sanitize/validate inputs or avoid dynamic evaluation. Confidence: 1.00 Severity: 0.60 From: ? → npm/@x402/core@2.12.0 → npm/@x402/evm@2.12.0 → npm/zod@3.25.76 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/zod@3.25.76. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

Ignoring alerts on:

• @x402/evm@2.12.0

View full report

[jeffsmale90]

@SocketSecurity ignore npm/@x402/evm@2.12.0

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 66cc06a. Configure here.}

[mj-kiwi]

I think we need to fix the cursor raised issues

[mj-kiwi]

Should we put the license content here? Other packages do the same.

[mj-kiwi]

Should we put the license content here? Other packages do the same.

[mj-kiwi]

The Hex type for address fields here will cause loss of type safety.

[jeffsmale90]

I've updated to Address type (which is functionally equivalent to Hex)

[mj-kiwi]

LGTM

[TateLyman]

Ran a local package-level pass on the new @metamask/smart-accounts-kit-x402 workspace. The unit tests, lint, and build pass locally:

corepack yarn workspace @metamask/smart-accounts-kit-x402 test
corepack yarn workspace @metamask/smart-accounts-kit-x402 lint
corepack yarn workspace @metamask/smart-accounts-kit-x402 build

One integration issue looks worth fixing before publishing the package: x402ExactEvmErc7710ServerScheme only calls x402Erc7710Server.enhancePaymentRequirements when baseRequirements.extra.assetTransferMethod === "erc7710" after ExactEvmScheme runs.

For the normal Base USDC shape, ExactEvmScheme preserves extra: {} / does not add assetTransferMethod, so the ERC-7710 wrapper returns unchanged requirements and never publishes the ERC-7710 marker or facilitatorAddresses.

Minimal repro after yarn workspace @metamask/smart-accounts-kit-x402 build:

import { x402ExactEvmErc7710ServerScheme } from './packages/smart-accounts-kit-x402/dist/index.mjs';

const scheme = new x402ExactEvmErc7710ServerScheme();
const result = await scheme.enhancePaymentRequirements(
  {
    scheme: 'exact',
    network: 'eip155:8453',
    asset: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913',
    amount: '10000',
    payTo: '0x1111111111111111111111111111111111111111',
    maxTimeoutSeconds: 300,
    extra: {},
  },
  {
    x402Version: 2,
    scheme: 'exact',
    network: 'eip155:8453',
    extra: { facilitatorAddresses: ['0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'] },
  },
  [],
);

console.log(result.extra);
// actual: {}
// expected for this wrapper: { assetTransferMethod: 'erc7710', facilitatorAddresses: [...] }

The current tests miss this because x402ExactEvmErc7710ServerScheme.test.ts mocks ExactEvmScheme.prototype.enhancePaymentRequirements to return extra: { assetTransferMethod: 'erc7710' }, which skips the real default-path behavior.

Patch shape: either make this wrapper always apply the ERC-7710 server enhancer after the base exact scheme runs, or gate on an explicit supportedKind.extra.assetTransferMethod === 'erc7710' / constructor option instead of requiring the incoming payment requirements to already carry the value the wrapper is supposed to add. I’d also add a no-mock test for the Base USDC default path so this does not regress.

Smaller packaging note: npm pack --dry-run shows the package would publish 73-byte / 35-byte license placeholders (LICENSE.APACHE2, LICENSE.MIT0) instead of the full license texts used by the other packages in this repo.

[TateLyman]

One post-merge heads-up since this shipped in @metamask/x402@0.1.0 / release 32.0.0: the default Base USDC path still appears to return unchanged requirements from x402ExactEvmErc7710ServerScheme, so the wrapper does not publish assetTransferMethod: 'erc7710' or facilitatorAddresses unless the incoming requirements already have the marker the wrapper is meant to add.

Fresh npm repro against the published package:

TMPDIR=$(mktemp -d)
cd "$TMPDIR"
npm init -y >/dev/null
npm i @metamask/x402@0.1.0 @x402/core@2.12.0 @x402/evm@2.12.0
node --input-type=module <<'NODE'
import { x402ExactEvmErc7710ServerScheme } from '@metamask/x402';

const scheme = new x402ExactEvmErc7710ServerScheme();
const result = await scheme.enhancePaymentRequirements(
  {
    scheme: 'exact',
    network: 'eip155:8453',
    asset: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913',
    amount: '10000',
    payTo: '0x1111111111111111111111111111111111111111',
    maxTimeoutSeconds: 300,
    extra: {},
  },
  {
    x402Version: 2,
    scheme: 'exact',
    network: 'eip155:8453',
    extra: { facilitatorAddresses: ['0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'] },
  },
  [],
);
console.log(JSON.stringify(result.extra ?? {}, null, 2));
NODE

Observed output:

{}

Expected for the ERC-7710 wrapper path would be something like:

{
  "assetTransferMethod": "erc7710",
  "facilitatorAddresses": ["0xaAaAaAaaAaAaAaaAaAAAAAAAAaaaAaAaAaaAaaAa"]
}

The current unit test still mocks ExactEvmScheme.prototype.enhancePaymentRequirements to return extra.assetTransferMethod = 'erc7710', so it does not cover the published default exact/Base path. I would add a no-mock regression test around this repro before a patch release.