@aztec/cli-wallet
1) Start a local Ethereum node (Anvil) in one terminal:
Supply chain provenance
Status for the latest visible version.
Without SLSA provenance there is no cryptographic link between this tarball and the public source — the axios compromise (March 2026) relied on exactly this gap.
Maintainers
Accepted risks
Findings the reviewer chose to accept rather than block on.
| Source | Rule | Reason | Accepted by | When |
|---|---|---|---|---|
| dependencies | unvetted-dep:@aztec/bb.js | AI (dependencies): @aztec/bb.js is a same-org dependency pinned to the same version as the package itself, consistent with the Aztec monorepo release pattern. | ai | |
| npm-metadata | no-description | AI (npm-metadata): Monorepo sub-package publishing pattern; absence of description is consistent across @aztec/* packages and not a malware indicator. | ai | |
| phantom-deps | phantom-dep:tslib | AI (phantom-deps): tslib is a well-known implicit TypeScript runtime dependency; phantom-dep firing is a stable false positive for TypeScript packages. | ai | |
| phantom-deps | phantom-dep:source-map-support | AI (phantom-deps): source-map-support is referenced in config/tooling context; phantom-dep finding is a stable false positive for this package. | ai | |
| bogus-package | bogus-package | AI (bogus-package): @aztec/cli-wallet is a monorepo sub-package of the Aztec Protocol; sparse metadata (no description, no repo URL, no keywords) is typical for internal tooling packages in large monorepos. | ai | |
| phantom-deps | phantom-dep:@aztec/noir-contracts.js | AI (phantom-deps): Same-org monorepo dependency; indirect imports within the @aztec ecosystem are expected and not a concern. | ai | |
| phantom-deps | phantom-dep:@aztec/noir-noirc_abi | AI (phantom-deps): Same-org monorepo dependency; indirect imports within the @aztec ecosystem are expected and not a concern. | ai | |
| semgrep | semgrep:base64-decode | AI (semgrep): Base64 decoding in ecdsa.js is used to parse ECDSA public keys — standard cryptographic practice, not a malicious payload indicator. | ai |
Versions (showing 25 of 25)
| Version | Deps | Published |
|---|---|---|
| 4.3.1 | 17 / 10 | |
| 4.3.0 | 17 / 10 | |
| 4.2.1 | 17 / 10 | |
| 4.2.0 | 17 / 10 | |
| 4.1.3 | 17 / 10 | |
| 4.1.2 | 17 / 10 | |
| 4.1.1 | 17 / 10 | |
| 4.1.0 | 17 / 10 | |
| 4.0.4 | 17 / 10 | |
| 4.0.3 | 17 / 10 | |
| 4.0.2 | 17 / 10 | |
| 4.0.1 | 17 / 10 | |
| 3.0.3 | 17 / 10 | |
| 3.0.2 | 17 / 10 | |
| 3.0.1 | 17 / 10 | |
| 2.1.11 | 15 / 9 | |
| 2.1.9 | 15 / 9 | |
| 2.1.8 | 15 / 9 | |
| 2.1.7 | 15 / 9 | |
| 2.1.6 | 15 / 9 | |
| 2.1.5 | 15 / 9 | |
| 2.1.4 | 15 / 9 | |
| 2.1.3 | 15 / 9 | |
| 2.1.2 | 15 / 9 | |
| 2.0.4 | 15 / 9 |
v4.3.1
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v4.3.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v4.2.1
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v4.2.0
1 findingPackage was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.
v4.1.3
1 findingPackage was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.
v4.1.2
1 findingPackage was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.