Security interfaces often compress a complicated check into a simple result: connected, verified, valid or trusted. The result may be accurate, but its wording can imply more than the underlying evidence proves.

Verification becomes useful when its boundary is explicit. What object was checked? Which system performed the check? What data did that system rely on? When did the check occur? Which assumptions remain outside it?

Detected is not verified

A wallet application may detect a connected hardware device. This proves that communication was established with something presenting the expected interface. It does not by itself prove that the device displays the intended receiving address, holds the expected keys, runs approved firmware or belongs to the current wallet policy.

Each of those claims requires different evidence. Combining them into one broad “device trusted” state makes failures harder to locate and creates confidence that may outlive the evidence.

Address verification proves a relationship

Displaying a receiving address on a trusted hardware device can establish that the device derives that address under the wallet information it has received. The value of the check depends on the display being authentic and on the operator comparing the complete address.

It does not necessarily prove that every signer in a multisignature policy has independently confirmed the same configuration. It does not prove that a copied address used later is unchanged. It does not prove that wallet metadata needed for future recovery has been preserved.

A strong check can still answer a narrow question.

A node verifies consensus, not every surrounding assumption

Using a personally controlled Bitcoin node can remove dependence on a third party for blockchain data and transaction broadcast. The node verifies consensus rules and the chain it accepts according to its configuration.

The node does not prove that a wallet descriptor is correct, that a hardware device is genuine, that a backup can be restored or that the operator has selected the intended transaction. A node strengthens an important boundary. It does not dissolve the others.

Multisig adds evidence requirements

Multisignature can distribute signing authority and tolerate some key loss, depending on the policy. It also creates information that must remain available: the threshold, participant keys, derivation information, script type and wallet configuration required to reconstruct the policy.

Finding several seed backups does not prove that the multisignature wallet can be recovered. The relationship between those keys is part of the recovery problem. A verification process should therefore distinguish key-material availability from wallet-policy availability and from successful reconstruction.

Use evidence states, not permanent badges

A verification result belongs to a point in time. Software changes, devices are replaced and configurations drift. A permanent badge can silently convert historical evidence into a current claim.

Four states are more honest:

  • Current: checked within the defined validity period against the relevant system.
  • Stale: previously checked, but the validity period or a material change requires a new check.
  • Unknown: no reliable evidence supports the claim.
  • Unavailable: the evidence source cannot presently be reached or used.

These states do not tell the operator what decision to make. They make the evidence available for a decision and expose where judgement is still required.

Write the claim before choosing the indicator

For any security status, complete the sentence: “We have evidence that…” If the sentence cannot be finished precisely, the status is too broad.

“Verified” might mean that a complete receiving address was confirmed on a specific device at a recorded time. “Current” might mean that the wallet policy was compared across all signers after the last configuration change. “Unavailable” might mean that the node providing independent blockchain data could not be reached.

Precision does not make security harder to understand. It prevents simple language from becoming misleading language.

21 Fruits principle
Verification should state what was checked, how it was checked, when it was checked and what remains outside the claim.