Rule

redundant-self-shielded-receive

Exact self-addressed canonical returned coin is subsequently passed to receiveShielded.

Release v0.1.1View Markdown

Specimen 22 of 96 · Audit-default ordinary rules

Severity
info
Confidence
high
Maturity
experimental
Selection
Audit default
Policy intent
not required
Release
v0.1.1
Engine facts used
runtime-operations selected-invocation-observations canonical-mint-observations completed-entries

Selection and scope#

Selected by the default audit profile, so an ordinary scan runs it.

Shell
./.nightshade/node_modules/.bin/nightshade ./contracts --detectors redundant-self-shielded-receive
./.nightshade/node_modules/.bin/nightshade detector show redundant-self-shielded-receive

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 detectedCorrected quietLookalike quietOther negative quietIncomplete
2/22/22/20/00

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/redundant-self-shielded-receive.md at v0.1.1.

Availability: default-on; severity info, confidence high for the supported source fact.

This rule reviews an exact returned coin from canonical mintShieldedToken, or sendShielded / sendImmediateShielded .sent, subsequently passed to canonical receiveShielded on one original modeled successful history. It requires a recipient with is_left == false whose right ContractAddress.bytes has the exact immutable identity of an observed kernel.self().bytes.

Compact
const coin = mintShieldedToken(default<Bytes<32>>, 1, default<Bytes<32>>,
  right<ZswapCoinPublicKey, ContractAddress>(kernel.self()));
receiveShielded(coin);

The owned pinned standard library automatically invokes its receive claim for this recipient. Review removing the explicit receive of the same returned coin. Keeping an explicit call for API symmetry or source readability can be intentional; this rule reports the duplicate call sequence, not a second coin output or a security defect. This is a call-sequence fact: ledger rejection, security impact, application intent, attack and transaction feasibility are not established.

The helper compares represented coin components using immutable identities, constants and opaque mint-observation snapshots. Aliases and unchanged projections retain evidence; names, provenance unions and later predicate equalities do not identify coins. User namesakes are excluded by canonical identity. Change outputs, external recipients, independent recomputations, unknown recipient tags and predicate-linked recipient addresses are outside the supported shape. Mutually exclusive histories never donate a producer to a receipt. Later rejecting continuations contribute no successful history.

Missing selected invocation or mint snapshot evidence and exhausted query allowances produce explicit rule-incomplete diagnostics. Reachable canonical kernel.checkpoint() entries are explicitly incomplete because the ordinary committed prefix observations lack exact returned invocation snapshots. The rule does not infer atomicity or discard checkpoint boundaries to claim completeness.

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:

Compact
// nightshade-disable-next-line redundant-self-shielded-receive -- Reason this match is intentional

Diagnostics cannot be suppressed, and an unmatched directive for a selected rule makes analysis incomplete. See configuration for fingerprint suppressions and baselines.

References#