Verification guide
Understand what a record can prove.
A public ID starts the review. A file match, a network receipt, an issuer assertion, and an observed time answer different questions. Follow the evidence for each one.
Five distinct checks
Follow the claim to its source.
These checks are a review framework, not a claim that every public record already contains every piece of evidence.
The file
Does this copy match?
Evidence to inspect
The exact file and its recorded SHA-256 fingerprint. Compute the fingerprint of the copy you received and compare the two values.
What it supports
A match supports that the copy has the same bytes as the fingerprinted version.
What it leaves open
It does not show that the statements in the file are true or that its issuer was authorized.
The application link
How is this record connected to the anchor?
Evidence to inspect
The commitment method and the data connecting this record to it. A direct commitment can be checked against the recorded fingerprint; a batch commitment also needs the record-to-root mapping and an inclusion path.
What it supports
The right evidence connects a particular record to the value committed on the network.
What it leaves open
A public ID or an anchor reference alone does not establish that connection.
The network event
Is the receipt in a block?
Evidence to inspect
The referenced transaction, its committed data, and evidence that the transaction is included in a block. Confirm that the committed value is the one checked in the previous step.
What it supports
This checks the network event and its inclusion separately from Arkova’s record lookup.
What it leaves open
Transaction inclusion alone does not identify a document or establish its current status.
The issuer
Who had authority to issue it?
Evidence to inspect
Confirmation from the issuing organization or another authoritative source, including the person or system authorized for this kind of record.
What it supports
That source can support the reported issuer’s identity and authority.
What it leaves open
An issuer name in a public record is a reported field. A fingerprint and receipt do not authenticate that name.
The time
Which event does the time describe?
Evidence to inspect
The network-observed time for the anchor, alongside any separate source-system or signing evidence relevant to the document.
What it supports
The network time places the anchoring event in a network timeline.
What it leaves open
It does not by itself establish when a file was created, signed, or approved. A block timestamp is not an exact clock measurement or a qualified electronic timestamp.
Where the public sample stands
A reference is not a complete proof package.
The public lookup for ARK-DOC-HKUK9N reports a network receipt, checkpoint, and observed time. Its API marks proof availability as root_only: Arkova does not provide a stored per-document proof bundle for this sample.
This does not mean the record is invalid. An independent check of a particular file still needs that file, its recorded fingerprint, and evidence connecting the record to the network commitment. The exact evidence depends on whether the commitment was direct or batched.
No original file for this sample is provided here, so a visitor cannot complete the file-comparison step from this guide.
Snapshot and proof-availability description reviewed Oct 1, 2026; request a new lookup for reported status.
Inspect the sample’s network receipt
This is a comparison of public sources. It relies on Arkova’s public-ID mapping and the explorers’ view of the network. It is not a file comparison or a local full-node verification.
- Open the public record above and copy its SHA-256 fingerprint and network receipt.
- Open that receipt in mempool.space or Blockstream Explorer. Inspect the first transaction output’s OP_RETURN data.
- For this sample’s direct commitment, the bytes
41524b56spellARKV. The following 32 bytes match the recorded fingerprint shown below. This corroborates that fingerprint’s presence in the transaction; a batched record needs a different record-to-root check. - Compare the explorer’s block and timestamp with the record. The reviewed sources reported block 946,305 and April 23, 2026 at 13:31:04 UTC. These are observations from the sources, not proof of a document’s signing time.
Sample fingerprint · reviewed Oct 1, 2026
3c29e6e6d52a701707cfd85532c8a4a42080762ad6fba8ae5f1e63e4126f7845If a source is unavailable, a value differs, or the commitment format is unclear, leave that check unresolved and request the supporting evidence. A missing proof package does not alone show that the record is invalid. No original sample file is supplied by this guide, so it does not demonstrate a complete file-to-network or offline proof check.
For the separate transaction-to-block check and its assumptions, see the Bitcoin developer guide. The block-header reference explains network timestamp rules.
Put the guide to work
Start with what the record actually says.
Look up the sample for its reported details, then ask for the file and supporting evidence appropriate to the claim you need to assess.