Security, with the limits in view.

Value and chain validation

Eight ledger exploit regressions pass, including thin-air minting, out-of-range values, input authorization and payload tampering. Thirty-eight chain-rule tests cover emission, fork choice by work, checkpoints, untrusted suffix validation and rejection without state mutation.

These tests exercise specific failures. They do not prove every possible attack on the cryptography has been excluded.

Safer storage and restarts

Operating-system locks refuse a second writer to the same data directory. Storage tests cover binary/JSON handling, migrations, foreign validation records and persistence after a reorganization.

The lock protects against accidental concurrent writers. It is not seed encryption or a defence against malware.

Miner and wallet resilience

Expired transactions leave the mempool. A poisoned transaction is filtered rather than preventing a block template. Wallet tests cover restoration, reserved outputs and reconciliation after a discarded block.

Pending-send retry support exists in Core and the browser wallet. Submission is still not confirmation.

Swap recovery is better defined

Tests cover persisted intent before broadcast, handshake restart, stale packets, unknown confirmation depth and refusing cancellation after a potentially published redeem.

The mainnet gate remains closed. A counterparty that never refunds Bitcoin can still leave NIGHT permanently locked. There is no independent timed NIGHT refund.

Independent review

No independent audit is established by this work. The cryptographic construction, cross-curve proof, transaction authorization and swap composition still need external specialist review.

Browser keys and shared origin

The web wallet stores an exported seed-containing state in localStorage. Script execution on the same origin can reach it; the public website and wallet share that origin. CSP reduces exposure but cannot make a compromised first-party deployment safe.

Separating the wallet origin and designing protected-at-rest storage are follow-up work, not features shipped by this review.

Light-node and transport trust

The browser does not independently validate the full chain. Its node can misrepresent payments, height or confirmation depth. The Worker has one configured upstream, reached over HTTP.

HTTPS protects browser-to-website traffic, not that upstream hop. The proxy can observe requests and transaction submissions. Upstream diversity and TLS remain priorities.

Proof of work and checkpoints

Cumulative work decides forks within the client's rules, including a 500-block rewind bound and compiled checkpoints. A deep conflicting history may be refused rather than automatically resolved.

Checkpoint-anchored replay can skip expensive validation of a historical prefix. This is a trust/performance trade-off, not universal verification of every historical proof on every startup.

Mixed does not mean erased

Amounts and recipient addresses are hidden by the protocol's construction. Block aggregation does not erase the graph; cut-through is not applied. Timing, first-hop observation and low transaction activity still matter.

Tor can fall back to clearnet. Neither the website nor this review promises that a user is untraceable.

Unsigned builds and local secrets

Release checksums help compare bytes, not authenticate a compromised release account. No trusted publisher-signing or notarization guarantee is established here. File permissions do not protect keys from a compromised logged-in account.

Keep recovery words offline and protect the device. A view key is sensitive financial history even though it cannot spend.