[Snyk] Security upgrade bip85 from 0.0.3 to 1.0.0

[revan-zhang]

Snyk has created this PR to fix 1 vulnerabilities in the npm dependencies of this project.

Snyk changed the following file(s):

• libs/combined/package.json

Vulnerabilities that will be fixed with an upgrade:

	Issue	Score
	Use of a Cryptographic Primitive with a Risky Implementation SNYK-JS-ELLIPTIC-14908844	540

---

Important

• Check the changes in this PR to ensure they won't cause issues with your project.
• Max score is 1000. Note that the real score may have changed since the PR was raised.
• This PR was automatically created by Snyk using the credentials of a real user.

---

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

---

Learn how to fix vulnerabilities with free interactive lessons:

🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

---

---

Note

Medium Risk
Upgrades a crypto-related dependency with a major version jump, which could introduce API/behavior changes affecting the bundled bip39-libs.js build or downstream consumers.

Overview
Updates the libs/combined bundled dependency set by upgrading bip85 from 0.0.3 to 1.0.0 to address a reported vulnerability in its crypto dependency chain.

^{Written by Cursor Bugbot for commit 1027ce8. This will update automatically on new commits. Configure here.}

[revan-zhang]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[devin-ai-integration]

Devin Review found 1 potential issue.

View 2 additional findings in Devin Review.

[devin-ai-integration]

🔴 package-lock.json not updated to match bip85 version bump to 1.0.0

The package.json bumps bip85 from 0.0.3 to 1.0.0, but libs/combined/package-lock.json still pins bip85 at version 0.0.3 (see libs/combined/package-lock.json entries under both dependencies and packages). This means npm ci (which respects the lockfile) will still install 0.0.3, making the version bump ineffective. Running npm install would update the lockfile, but the lockfile should be committed as part of this PR to ensure deterministic builds.

Prompt for agents

Run `npm install` (or `npm update bip85`) inside the `libs/combined/` directory to regenerate `libs/combined/package-lock.json` with bip85 version 1.0.0, then commit the updated lockfile alongside the package.json change. Also verify that the bip85 1.0.0 API is compatible with the usage in src/js/index.js (specifically BIP85.fromBase58, deriveBIP39, deriveWIF, deriveXPRV, deriveHex methods), since this is a major version bump that may include breaking changes.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

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

[cursor]

Lock file not updated, will break npm ci

High Severity

The package.json now specifies bip85 version 1.0.0, but libs/combined/package-lock.json still references version 0.0.3 throughout (both in the packages and dependencies sections). This mismatch will cause npm ci to fail, since it requires the lock file to be in sync with package.json. If npm install is used instead, it may update the lock file — but only if version 1.0.0 actually exists on npm.

 

[cursor]

Major version bump may break bip85 API usage

High Severity

Upgrading bip85 from 0.0.3 to 1.0.0 is a semver-major bump, and the Snyk metadata itself flags "isBreakingChange":true. The codebase calls specific APIs — BIP85.fromBase58(), .deriveBIP39(language, length, index).toMnemonic(), .deriveWIF(index).toWIF(), .deriveXPRV(index).toXPRV(), and .deriveHex(bytes, index).toEntropy() in src/js/index.js — whose signatures or return types may have changed in v1.0.0, silently producing incorrect cryptographic output or runtime errors.