chore!: require Node.js >=22 for JS packages and >=24 for dashmate

[lklimek]

Basic explanation

Raises the minimum Node.js version to >=22 for the JavaScript and WASM packages, and to >=24 for dashmate. Developer environments, Docker images and documentation are aligned with those two floors.

Issue being fixed or feature implemented

Split from #5307 at the author's request. Node 18 reached EOL on 2025-04-30 and Node 20 on 2026-04-30; Node 22 and Node 24 remain supported. Official Node.js release schedule.

The rust-dashcore migration uses secp256k1 0.33, rand 0.9 and getrandom 0.3 in its signing path. The WASM entropy backend calls globalThis.crypto.getRandomValues() without the older CommonJS crypto fallback. Node 22 provides global WebCrypto by default, so no compatibility shim is needed. Node.js documentation.

Policy applied here:

• Developer-facing packages, tests and examples: Node >= 22.
• Dashmate (production tool): Node >= 24, the newest LTS line that works today. Operator documentation follows dashmate.

Node 26 was evaluated for dashmate and rejected for now. On Node >= 26.0.0 the cbor package (through nofilter 3.1.0, including the latest cbor 10.0.12) fails every decode with Insufficient data, which breaks gRPC error handling in @dashevo/dapi-client. It works on Node 22, 24 and 25. dapi, js-dapi-client, js-grpc-common and wallet-lib depend on cbor, so they need a different CBOR library before Node 26 can be supported. Node 26 also only becomes LTS on 2026-10-28, and node:26-alpine ships neither Yarn nor Corepack.

What was done?

Node >= 22

• Set engines.node to >=22 in @dashevo/wasm-sdk, @dashevo/wasm-dpp2, @dashevo/evo-sdk, legacy @dashevo/wasm-dpp, dash, @dashevo/dapi-client, @dashevo/wallet-lib, wasm-drive-verify, @dashevo/dapi, the platform test suite, the bench suite and qa-contract.
• Bump @types/node from 20 to 22 in the WASM packages and both SDKs.
• Align the SDK, DPP, wasm-sdk and qa-contract READMEs and the Evo SDK book pages.
• Move the Dockerfile's dependency-build and test-suite stages to node:22-alpine, retaining the existing Alpine version.

Node >= 24

• Set engines.node to >=24 in dashmate and update the operator installation guide.
• Run the dashmate helper image on node:24-alpine.
• Install Node 24 in the devcontainer and in scripts/setup-ai-agent-environment.sh, because both start the local network through dashmate.
• Replace the stale "Node 20–22" guard in the Swift integration test runner with the Node 24 floor.

CI is unchanged: it already runs and packages dashmate on Node 24.14.1.

Stacked on #5307 to keep the runtime policy change separately reviewable. Land this change together with the migration; it addresses the Node runtime review blocker.

How Has This Been Tested?

• On Node 22.23.1, a standalone smoke test loaded the production legacy WASM-DPP package and signed an ECDSA credit-transfer transition without the test bootstrap or a WebCrypto shim. Reused the WASM/JS build from chore(platform)!: update rust-dashcore (incl secp256k1 0.33) #5307's identical source.
• On Node 24.21.0: dashmate CLI starts, dashmate unit tests pass (857), @dashevo/dapi-client unit tests pass (323), and a clean yarn install --inline-builds succeeds. Dashmate also runs on Node 24 with native modules built on Node 22, which is how the helper image is assembled.
• On Node 26.10.0: dashmate unit tests pass (857) but 8 @dashevo/dapi-client unit tests fail in createGrpcTransportError with the cbor error above; reproduced in isolation on node:26.0.0-alpine and node:26-alpine, not on node:24-alpine or node:25-alpine.
• @types/node bump: tsc --noEmit output for the five affected packages is identical before and after. js-dash-sdk type-checks cleanly; the other packages could not be fully type-checked locally without their WASM builds.
• yarn.lock and .pnp.cjs change only the @types/node entries. Confirmed that the node:22-alpine3.23 and node:24-alpine3.23 images exist and ship Yarn.
• Full Docker builds, browser tests and the complete SDK suites were not run.

Breaking Changes

• Node.js versions below 22 are no longer supported by @dashevo/wasm-sdk, @dashevo/wasm-dpp2, @dashevo/evo-sdk, @dashevo/wasm-dpp, dash, @dashevo/dapi-client, @dashevo/wallet-lib and wasm-drive-verify.
• Dashmate installed from npm requires Node.js 24 or newer. Dashmate release packages bundle their own Node runtime and are not affected.

Browser requirements and Rust APIs are unchanged by this PR.

Checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added "!" to the title and described breaking changes
• I have validated the relevant runtime behavior

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Repository: dashpay/platform/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: c0bfd6af-1552-4321-8f70-f933713bc4cf

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

✅ Final review complete — no blockers (commit 826a101) · triage: normal

[github-actions]

📖 Book Preview built successfully.

Download the preview from the workflow artifacts.
To view locally: download the artifact, unzip, and open index.html.

Updated at 2026-10-06T15:53:29.465Z

[thepastaclaw]

Final validation — Phase 1 + Phase 2

Verified the supplied findings against head 258fe74 and consolidated both reviewers’ reports into one confirmed documentation issue. No blocking findings remain in the supplied evidence. Validation was static only; JS builds, Docker builds, and Rust workspace tests were still running in the supplied CI snapshot from 2026-10-06T14:50:44Z.

🟡 1 suggestion(s)

1 finding(s) not shown inline (the lines are not part of this PR's diff)

🟡 Suggestion: Align the Evo SDK overview with the new Node minimum
book/src/evo-sdk/overview.md:6

The overview still advertises Node.js ≥18.18, but this PR raises @dashevo/evo-sdk to engines.node >=22 and updates the getting-started and environment chapters to match. Readers entering through the overview are therefore told that Node 18 and 20 remain supported, contradicting the new runtime policy. Update this line to ≥22 so the introductory compatibility guidance matches the package manifest and the rest of the book.

Node.js (≥ 22) and modern browsers.

_{source: muse-spark-1.3-contributor (phase1-reviewer: general); gpt-6.1-sol (phase2-reviewer: general)}

Review provenance

Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: normal by gpt-6.1-sol (effort low) — The change raises supported runtime floors across packages, Docker images, developer environments and test tooling, requiring cross-cutting compatibility review but not modifying critical implementation surfaces.
• Phase 1 reviewers: muse-spark-1.3-contributor — general (completed, effort xhigh); agent phase1-reviewer
• Phase 1 model: muse-spark-1.3-contributor — not quota-gated; passed over gemini-3.8-flash-high (antigravity below 15% reserve: weekly 15% left, 5h 100% left), glm-5.3-flash (not used above high effort; tier asks max)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort high); agent phase2-reviewer

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `book/src/evo-sdk/overview.md`:
- [SUGGESTION] book/src/evo-sdk/overview.md:6: Align the Evo SDK overview with the new Node minimum
  The overview still advertises Node.js ≥18.18, but this PR raises `@dashevo/evo-sdk` to `engines.node >=22` and updates the getting-started and environment chapters to match. Readers entering through the overview are therefore told that Node 18 and 20 remain supported, contradicting the new runtime policy. Update this line to ≥22 so the introductory compatibility guidance matches the package manifest and the rest of the book.

[thepastaclaw]

Re-review — Final validation — Phase 1 + Phase 2

The complete diff implements the Node 22 package floor and Node 24 dashmate floor without changing protocol behavior; one monorepo setup prerequisite remains inconsistent with those requirements. The prior Evo SDK overview finding is fixed at the exact head. Verification was static only: all checks in the supplied CI snapshot succeeded, but that snapshot does not establish full JavaScript runtime or Docker-build coverage.

🟡 1 suggestion(s)

1 finding(s) not shown inline (the lines are not part of this PR's diff)

🟡 Suggestion: Update the monorepo setup guide to require Node 24
book/src/getting-started.md:8

The monorepo prerequisites still advertise Node.js v20+, while this PR raises the affected JavaScript packages to Node 22 and dashmate to Node 24. This page instructs readers to run yarn setup and yarn start: setup invokes dashmate through the configuration scripts, and start invokes dashmate directly through the root workspace script. Consequently, the documented local-development workflow requires Node 24, not merely the SDK's Node 22 minimum. Update this prerequisite to match the workflow; the adjacent Docker v20.10+ requirement is unrelated and should remain unchanged.

- [Node.js](https://nodejs.org/) v24+ (required by dashmate for the local network)

_{source: muse-spark-1.3-contributor (phase1-reviewer: general); gpt-6.1-sol (phase2-reviewer: general)}

Review provenance

Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: normal by gpt-6.1-sol (effort low) — The diff makes a cross-cutting runtime compatibility change across package engines, Docker images, developer tooling and dependency metadata, but does not change critical implementation surfaces.
• Phase 1 reviewers: muse-spark-1.3-contributor — general (completed, effort xhigh); agent phase1-reviewer
• Phase 1 model: muse-spark-1.3-contributor — not quota-gated; passed over gemini-3.8-flash-high (antigravity below 15% reserve: weekly 15% left, 5h 100% left), glm-5.3-flash (not used above high effort; tier asks max)
• Fresh final gate: an independent Phase-2 review ran after iterative findings were reconciled
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort high); agent phase2-reviewer

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `book/src/getting-started.md`:
- [SUGGESTION] book/src/getting-started.md:8: Update the monorepo setup guide to require Node 24
  The monorepo prerequisites still advertise Node.js v20+, while this PR raises the affected JavaScript packages to Node 22 and dashmate to Node 24. This page instructs readers to run `yarn setup` and `yarn start`: setup invokes dashmate through the configuration scripts, and start invokes dashmate directly through the root workspace script. Consequently, the documented local-development workflow requires Node 24, not merely the SDK's Node 22 minimum. Update this prerequisite to match the workflow; the adjacent Docker v20.10+ requirement is unrelated and should remain unchanged.

[lklimek]

/self-reviewed

[lklimek]

/self-reviewed

[thepastaclaw]

Re-review — Final validation — Phase 1 + Phase 2

Reviewed the complete diff at head 826a101. Both prior documentation findings are fixed; one non-blocking issue remains where the integration runner newly accepts the known-incompatible Node 26 runtime. Validation was static-only: the supplied CI snapshot is successful but does not establish complete JavaScript-suite or Docker-build coverage.

🟡 1 suggestion(s)

Review provenance

Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: normal by gpt-6.1-sol (effort low) — The runtime-floor changes span package compatibility, Docker stages, developer setup and test tooling, requiring cross-cutting validation but changing no critical implementation surface.
• Phase 1 reviewers: muse-spark-1.3-contributor — general (completed, effort xhigh); agent phase1-reviewer
• Phase 1 model: muse-spark-1.3-contributor — not quota-gated; passed over gemini-3.8-flash-high (antigravity below 15% reserve: weekly 15% left, 5h 100% left), glm-5.3-flash (not used above high effort; tier asks max)
• Fresh final gate: an independent Phase-2 review ran after iterative findings were reconciled
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort high); agent phase2-reviewer

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/swift-sdk/run_integration_tests.sh`:
- [SUGGESTION] packages/swift-sdk/run_integration_tests.sh:19: Keep the preflight rejection of the known-incompatible Node 26 runtime
  Replacing the bounded check with only a minimum newly admits Node 26, despite the PR's reported reproduction showing that this runtime breaks CBOR decoding. The current lockfile still resolves cbor 8.1.0 and nofilter 3.1.0, and the runner invokes host-side dashmate with --wait-for-readiness, whose readiness task uses @dashevo/dapi-client. That client's createGrpcTransportError decodes drive-error-data-bin and stack-bin metadata before GrpcTransport classifies the error or retries, so an affected response can instead escape as an unclassified "Insufficient data" exception after bootstrap and devnet startup have begun. Retain an upper bound excluding Node 26 and later until compatibility is established. This is a developer-tooling preflight issue, not a consensus blocker.

[thepastaclaw]

🟡 Suggestion: Keep the preflight rejection of the known-incompatible Node 26 runtime

Replacing the bounded check with only a minimum newly admits Node 26, despite the PR's reported reproduction showing that this runtime breaks CBOR decoding. The current lockfile still resolves cbor 8.1.0 and nofilter 3.1.0, and the runner invokes host-side dashmate with --wait-for-readiness, whose readiness task uses @dashevo/dapi-client. That client's createGrpcTransportError decodes drive-error-data-bin and stack-bin metadata before GrpcTransport classifies the error or retries, so an affected response can instead escape as an unclassified "Insufficient data" exception after bootstrap and devnet startup have begun. Retain an upper bound excluding Node 26 and later until compatibility is established. This is a developer-tooling preflight issue, not a consensus blocker.

Suggested change

	if [ "$node_major" -lt 24 ]; then
	if [ "$node_major" -lt 24 ] || [ "$node_major" -ge 26 ]; then

_{source: gpt-6.1-sol (phase2-reviewer: general)}