# default-recipient-or-owner

> A successful value output or pinned Ownable update uses a known default active address.

Canonical: https://nightshade.dicksonwu.xyz/rules/default-recipient-or-owner.html
Release: Nightshade 0.1.1 (v0.1.1)

| Field | Value |
| --- | --- |
| Rule ID | `default-recipient-or-owner` |
| Severity | medium |
| Confidence | high |
| Maturity | experimental |
| Selection | Opt-in |
| Policy intent | not required |
| Default enabled | no |
| Category | Other active opt-ins / Source structure and validation |
| Engine facts used | all-predicates, runtime-operations, state-writes, constants, completed-entries |
| Release | v0.1.1 |

## 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.

```sh
./.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](https://nightshade.dicksonwu.xyz/evaluation.md#synthetic-corpus).

## Rule documentation

From https://github.com/DicksonWu654/nightshade/blob/v0.1.1/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:

```compact
// nightshade-disable-next-line default-recipient-or-owner -- Reason this match is intentional
```

Diagnostics cannot be suppressed, and an unmatched directive for a selected rule makes analysis incomplete. See [configuration](https://nightshade.dicksonwu.xyz/configuration.md#suppress-an-intentional-match) for fingerprint suppressions and baselines.

## References

- [Rule source document at v0.1.1](https://github.com/DicksonWu654/nightshade/blob/v0.1.1/docs/detectors/default-recipient-or-owner.md)
- [Catalog entry in rules.json](https://nightshade.dicksonwu.xyz/rules.json)
- [All rules](https://nightshade.dicksonwu.xyz/rules.md#source-structure-and-validation)
- [Limitations](https://nightshade.dicksonwu.xyz/limitations.md)