Reference

Limitations and FAQ

Release v0.1.1View Markdown

Does a quiet scan mean my contract is safe?#

No. Nightshade is a bounded, experimental source analyzer. A complete result means the selected, supported analysis finished. It does not establish compiler validity, transaction feasibility, cryptographic security or whole-contract security. Use it alongside compiler checks, tests and human review.

Review diagnostics, status, coverage.baselineStatus and coverage.rules. Unsupported syntax or effects, unresolved imports and exhausted budgets produce gaps. A root without entrypoints does not provide execution coverage. An incomplete scan is never equivalent to a clean scan, including when an explicit CI warning policy lets rule-only gaps pass.

Which compiler versions are supported?#

Pinned bounded profiles are 0.28.0, 0.29.0, 0.30.0, 0.31.1, 0.33.0-rc.2, 0.34.0, 0.35.0-rc.1 and 0.35.0. ZKIR2 is the default. ZKIR3 requires explicit selection and is qualified only with 0.34.0. Unlisted versions are unsupported. Pin the profile used by your build; do not change versions merely to clear a diagnostic.

See the exact compiler, language and runtime matrix. Rule-specific support can be narrower than engine support.

What can analysis miss?#

Path and value tracking are bounded. Abstract paths can overapproximate real execution, so a reported path may be infeasible. Collection relationships, native operations and dynamic calls have restricted coverage. Analysis does not establish arbitrary cross-transaction histories, witness implementation behavior, ledger acceptance or deployed runtime compatibility.

Default checks do not infer a complete authorization policy from cross-circuit use of ledger values. A credential-changing circuit can go unreported, including by inconsistent-access-control. Declare the required authorization policy and review all credential changes explicitly.

Intentional disclosure, public-data validation and deliberately rejected transactions can match rules. Severity describes review priority; it does not establish exploitability or impact. Each rule document explains the evidence and benign matches.

What has been measured?#

I reran the released 0.1.1 CLI on a fixed set of 300 contract roots from 144 repositories. 258 of 300 roots finished baseline analysis and 237 of 300 finished every selected rule. The 27 roots the compiler rejected stay in the denominator, and there were 0 process failures. The assembled inputs are not redistributed, so only aggregate counts are published.

Completion and finding counts do not measure accuracy. There is no independently established release-wide precision or recall estimate. An earlier precision sample was labeled with model assistance, not by independent auditors, and is not a general accuracy estimate. Synthetic positive, corrected and lookalike tests check defined behavior, not ecosystem-wide recall. The evaluation page has the full tables, every miss and how to reproduce the runs.

Does Nightshade run my contract or send it anywhere?#

Normal scans use local sources and imports. They do not execute contracts, require a compiler or fetch dependencies. Installation needs network access. Explicit compiler validation and trusted detector modules execute host code only when selected. The V8 heap setting is not an RSS cap or OS sandbox.

Can I use macOS or another native platform?#

The release package targets Linux x86-64/glibc with Node 22 or 24 and libstdc++ providing GLIBCXX_3.4.31 or newer (Ubuntu 24.04 or Debian 13). On macOS, use the Linux Docker image described in getting started. Other native targets need their own parser build and platform validation.

Where should I report a problem?#

Use GitHub issues for ordinary bugs and reproducible feature gaps. Follow the security policy and private vulnerability reporting for security issues. Include the compiler profile, Nightshade version, scan settings, diagnostics and a minimal example you can share.