Evidence & limitations
Keep a Risk Check Receipt
Save the evidence, time and policy behind one observation.
What the receipt records
A Risk Check Receipt is a stored observation with a public permalink. It keeps the report's four panel results and the evidence needed to understand them.
- The network, full contract address, deployed-code result and available token metadata.
- Owner, EIP-1967 proxy slots and ERC-165 interface flags read at the same block.
- A unique observation ID and observation time in UTC.
- Observed block, hash and source retrieval timestamps when available.
- Token classification, check applicability and outcomes, with reasons and source references.
- The four panel statuses and their explanations.
- Project source matches, conflicts, published address claims and content hashes when read.
- The largest indexed holders and their share of the indexed supply when the holder source responded.
- Explorer records, exact-address market pairs, discovered links and each discovery source outcome when attempted.
- Unknowns, expiry, receipt schema, policy version and separate stock-token and project coverage versions.
- A one-line summary and the fixed list of questions no check assesses.
Read the observation
Check each source’s timestamp. Contract reads are pinned to the recorded block. Explorer, market, website, GitHub, registry and directory sources have their own retrieval times. An explorer record can lag the chain. A market retrieval time does not establish when a quoted price changed or a trade occurred.
New observations use receipt schema v3 and policy 2.1.0. Schema v1 and v2 receipts remain readable with their original evidence and explanations. Later fields are not inferred for earlier receipts. Oracle sweep receipts mark explorer and market discovery as not attempted; individual token checks run those lookups.
A content hash records which response body was checked. It is not a publisher signature. The receipt preserves extracted evidence and the hash, rather than a full archived copy of each source.
Recheck without overwriting
Recheck creates a new observation. The original receipt keeps its recorded evidence, policy and timestamps. New conditions or policy changes do not rewrite that history.
An expired notice describes the age of the receipt. It does not change the statuses that were recorded.
What the receipt does not attest
MVP receipts are unsigned. A permalink is not a cryptographic signature. The receipt does not certify issuer reserves, legal eligibility, liquidity or the safety of a token.
Use its JSON representation to inspect the structured observation. Expiry and rechecks explains when to request a newer one.