# 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`](./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:

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

## Release guidance

Before publishing a security-sensitive release, maintainers should run at least:

```bash
npm run lint
npm run typecheck
npm test
npm run docs:check
npm pack --dry-run
```

For npm publication, also perform dependency/security audit and package-content review in an environment where audit tooling is available.