chore: bump @ethereumjs/tx to v5

[cryptodev-2s]

Top of stack #315, on #320. Last of the PR#2 bumps.

Dep	From	To
@ethereumjs/tx	^4.2.0	^5.4.0

This is not breaking, but only because of a one word change

The bump compiles with no source change at all, which is the trap. @ethereumjs/tx@5 reuses the name TxData for something entirely different:

// v4
interface TxData { nonce?, gasPrice?, gasLimit?, to?, value?, data?, v?, r?, s? }

// v5
interface TxData {
  [TransactionType.Legacy]: LegacyTxData;
  [TransactionType.AccessListEIP2930]: AccessListEIP2930TxData;
  ...
}

v4's meaning is now called LegacyTxData. keyring.ts declares signTransaction as returning Promise<TxData>, so bumping alone would silently change that public type from "a signed legacy transaction" into "an object carrying every transaction type at once", and still build clean.

Typechecking a v4 era consumer against the unpatched build confirms it:

Type '{ nonce, gasPrice, gasLimit, to, value, data, v, r, s }' is missing the following
properties from type 'TxData': [TransactionType.Legacy], [TransactionType.AccessListEIP2930], ...

Mapping TxData to LegacyTxData restores the original contract exactly, and that same consumer typechecks again.

TypedTxData would also accept it, but it is a union, so callers would have to narrow the result. LegacyTxData keeps the API identical to v4.

Note Keyring is already deprecated in favour of @metamask/keyring-utils, so the blast radius is small either way.

---

Note

Medium Risk
Touches transaction-signing types from a major dependency bump; the explicit LegacyTxData fix avoids a silent type break for consumers of deprecated Keyring.

Overview
Upgrades @ethereumjs/tx from ^4.2.0 to ^5.4.0 (with lockfile updates for transitive @ethereumjs/* and crypto deps) and documents the change in the changelog.

Because v5 redefined TxData as a per-transaction-type map, the deprecated Keyring.signTransaction return type is updated from Promise<TxData> to Promise<LegacyTxData> so the public API still means a signed legacy transaction object—the same shape as before. Keyring implementers do not need code changes.

^{Reviewed by Cursor Bugbot for commit d1ea1a7. 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
	@​ethereumjs/​tx@​4.2.0 ⏵ 5.4.0	+1			-1

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		Network access: npm @ethereumjs/util in module globalThis["fetch"] Module: globalThis["fetch"] Location: Package overview From: package.json → npm/@ethereumjs/tx@5.4.0 → npm/@ethereumjs/util@9.1.0 ℹ Read more on: This package | This alert | What is network access? 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: Packages should remove all network access that is functionally unnecessary. Consumers should audit network access to ensure legitimate use. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@ethereumjs/util@9.1.0. 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.

View full report