Security policy

This project handles blockchain signing, transaction construction and memo helpers. Please report suspected security issues responsibly.

Supported version

Security review targets the active main branch and the latest published npm version when applicable. Do not hand-maintain a version number here; the repository version is defined by package.json and the published version is defined by the npm registry.

What to report

Please report issues such as:

private-key exposure or unsafe key handling in SDK code;
transaction serialization or signing errors;
asset amount precision or rounding errors that affect signed transactions;
memo encryption/decryption vulnerabilities beyond known legacy-format limitations;
JSON-RPC response handling issues that can mislead applications;
package distribution, build artifact or dependency supply-chain risks;
browser bundle issues that materially affect key safety.

Do not include real private keys, seed phrases or account secrets in reports.

Known architectural limitations

Some risks are protocol or application-boundary limitations rather than direct SDK bugs. They are still important, but they may require documentation, application controls or future protocol-compatible designs rather than immediate SDK changes.

Known categories include:

public RPC endpoints are untrusted unless the application chooses and secures them;
Nexus Layer 2 data is indexed/query data, not Layer 1 consensus truth;
browser signing is high risk without wallet/user-controlled signing flows;
legacy encrypted memo format should not be treated as modern authenticated encryption;
password-derived keys from legacy login semantics are not a modern password KDF.

See architecture/SECURITY_ARCHITECTURE.md for the project security architecture.

Reporting channel

If the hosting platform provides a private security advisory or confidential issue workflow for this repository, use that first.

If no private workflow is available, contact the maintainers through the repository's normal project channels and request a private security contact before sharing exploit details.

Do not open a public issue containing exploit details, live private keys or instructions that could immediately harm users.

Maintainer handling expectations

Maintainers should:

acknowledge receipt when possible;
classify whether the report is an implementation bug, architectural weakness, accepted protocol limitation, application concern or operational recommendation;
reproduce with tests or a minimal proof where safe;
decide whether a fix, documentation update, release advisory or no-code clarification is appropriate;
avoid publishing exploit details until users have a reasonable mitigation path.

Release guidance

Before publishing a security-sensitive release, maintainers should run the side-effect-free release preflight:

npm run release:check

For npm publication, also perform dependency/security audit and package-content review in an environment where audit tooling is available. release:check includes runtime CSP scanning and a packed-package consumer smoke test, but it does not replace maintainer review of generated artifacts or release provenance.

3.2 KiB Raw Permalink Blame History