default-recipient-or-owner

Specimen 89 of 96 · Other active opt-ins / Source structure and validation

Severity: medium
Confidence: high
Maturity: experimental
Selection: Opt-in
Policy intent: not required
Release: v0.1.1
Engine facts used: all-predicates runtime-operations state-writes constants completed-entries

Selection and scope#

Not selected by default. Select it with --detectors or the detectors list in nightshade.json. Either one replaces profile selection, so list every rule you want.

Shell

./.nightshade/node_modules/.bin/nightshade ./contracts --detectors default-recipient-or-owner
./.nightshade/node_modules/.bin/nightshade detector show default-recipient-or-owner

The first command runs only this rule; --detectors takes a comma-separated list. The second prints the rule's metadata from your installed version.

Severity is review priority. It does not express exploitability or impact. Confidence is detector metadata, not a probability. All built-in rules are experimental.

Compiler scope: the engine supports the pinned profiles 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, with ZKIR2 by default. Support for this rule can be narrower; the rule documentation below states any narrower scope.

Corpus checks#

Synthetic corpus checks for this rule in the 0.1.1 proof run. A check counts only with compiler acceptance and complete analysis.

Positive detected	Corrected quiet	Lookalike quiet	Other negative quiet	Incomplete
2/2	2/2	2/2	0/0	0

No deviations were recorded for this rule.

These are behavior checks on synthetic fixtures, not a precision or recall estimate. See evaluation.

Rule documentation#

From docs/detectors/default-recipient-or-owner.md at v0.1.1.

Availability: opt-in; severity medium, confidence high for the known active address. Destination intent and concrete feasibility require review.

Description, example and scenario#

Compact

sendUnshielded(color, 1, right<ContractAddress, UserAddress>(default<UserAddress>));

The selected recipient is an all-zero 32-byte address at a modeled successful output. A nonzero check on an inactive Either payload does not validate that recipient. The rule also checks the final owner write in the byte-authenticated, pinned OpenZeppelin Ownable module. It excludes that module's explicit renounceOwnership path and a zero owner overwritten before successful completion.

Recommendation#

Validate the active destination before use. Reserve zero destinations for an explicit, documented burn or authority-removal path. Ownership validation does not by itself establish caller authorization.

Evidence and known false positives#

Exact transaction output operands and owner writes retain their individual history, selected tag and invocation sites. Bounded immutable equality projection includes aggregate leaves and later atomic assertions; it never borrows constraints from another history, ledger revision or wildcard region. Direct authenticated owner assignments are included. Unknown tags/bytes are not inferred to be zero; inactive defaults, known zero-amount outputs, rejected histories, unrelated ledger sentinels and namesake application routines are quiet. Imported module trust uses pinned source hashes and dependency identities, rather than a filename or name.

Intentional burns, including shieldedBurnAddress, are known review matches. Custom ownership protocols, commitment-derived identities, default addresses with unknown tags, cross-invocation setup and arbitrary recipient encodings are outside the rule. Constructor output operations are reviewed; zero setup sentinels alone are not security evidence. Exact-observation exhaustion is entry/rule-scoped incomplete and preserves baseline analysis; a quiet incomplete rule is not clean.

Suppress a match#

If a match is intentional, suppress it on the line before with the exact rule ID and a reason of at least eight characters: