Independent evidence around a proof
A Verifyum proof stands on its Solana transaction. The Witness Layer adds more places the same evidence turns up, run by different operators in different jurisdictions. They are not all equal, and this page says which is which: four records anyone can check without us, four that are our own, and one channel that is not evidence at all.
How it works
Every finalized proof becomes a leaf in an hourly Merkle tree. The tree produces one root, and only the checkpoint carrying that root travels to the external witnesses. An hour with no new finalized proofs produces no checkpoint. Anyone can prove their own proof belongs to the tree, while nobody can read the other members from the root. Once a day the hourly checkpoints are aggregated into one daily checkpoint.
Automatic monitoring
No channel is presented as live without automatic monitoring behind the claim. Below is the active state of each witness channel, monitored continuously against public receipts. A machine-readable status feed is published at /witness/status.json.
Primary evidence
Everything below it is corroboration. A delayed or missing supplementary record never weakens the proof, and the number of records is not a quality score.
Contributes: the timestamp itself. Your commitment is written into a finalized Memo transaction.
Why it matters: a large public network records the time independently of Verifyum, and anyone can read the transaction from any RPC endpoint without asking us.
Its limit: retrieving deep history generally runs through an archival provider rather than an ordinary node, so we do not claim the lookup path is free of third parties.
Independent corroboration
These are operated by others, and each can be verified without Verifyum existing. They are the records that still mean something in a dispute, because a dispute is precisely where our own word is what is being questioned. The code that recomputes these checks is public at github.com/aisenseapi/verifyum-verify.
Contributes: the hourly checkpoint is stamped through public calendar servers and later anchored in a Bitcoin block.
Why it matters: Bitcoin's history is replicated by thousands of independent nodes, the strongest durability guarantee available. It is slow, so it complements Solana rather than replacing it.
Contributes: the daily checkpoint is timestamped by Sectigo (Europe) SL, whose qualified timestamping service is listed as granted on Spain's EU Trusted List, over RFC 3161, which sends only the hash. Verifyum refuses a token that does not carry the ETSI statement that it is a qualified timestamp.
Why it matters: this is the one record carrying a statutory presumption. Under eIDAS Article 41(2) the time and integrity of the checkpoint root are presumed correct across the EEA, and the burden falls on whoever disputes it.
Its limit: the presumption covers the root only. The step from the root to your file is shown by the Merkle path like any other technical fact, so a user proof is never itself a qualified timestamp.
Contributes: the daily checkpoint enters an append-only transparency log whose tree head is cosigned by at least two of the three pinned witnesses, run by Glasklar, Mullvad and Tillitis.
Why it matters: this receipt verifies offline years later even if the log has disappeared. The stored leaf, inclusion proof, cosigned tree head and trust policy are sufficient on their own, and the log by design cannot know which user or file any entry concerns.
Contributes: each daily checkpoint gets one certificate, issued for a hostname that encodes its root, and it enters append-only CT logs.
Why it matters: CT logs are operated by browser vendors and certificate authorities, monitored constantly, and cryptographically append-only. Verifyum verifies the inclusion proof itself before treating an entry as confirmed.
Our own records
We list these separately on purpose. Two of them are Verifyum vouching for Verifyum, and two prove what was stored rather than when. They add durability and convenience, and they would carry no weight against us in a dispute. Saying so ourselves is more honest than waiting for someone to point it out.
Contributes: an Ed25519 signature over the public metadata, checked against a published key registry.
Why it is here: it ties the metadata document to Verifyum, so a modified copy is detectable. It is our own attestation, which is exactly why the independent records above exist.
Contributes: each hourly checkpoint is committed to a public repository, bound to an immutable commit ID.
Why it is here: it is trivially readable by a human and hosted by a third party. The repository is ours, so we could in principle rewrite it, which is why Software Heritage mirrors it.
Contributes: the checkpoint repository is archived by Software Heritage, run by Inria under a UNESCO agreement.
Why it is here: the GitHub log above is ours; this custody is not. It is custody, not time: an archive identifier proves what was stored, never when.
Contributes: the public checkpoint page is captured by the Wayback Machine with the archive's own timestamp.
Why it is here: a well-known archive holds a dated copy in a form a non-technical reader can inspect in a browser. Like any capture, it shows what was archived rather than when the file existed.
Not evidence
Finalized proofs are announced as they happen, in a Telegram channel and in an Atom feed. This is information, not proof. The post's timestamp dates the announcement, not your file, and a missing, delayed or deleted post says nothing about a proof. It is deliberately absent from the printed receipt, so no permanent document depends on a platform outliving it.
Inspect it yourself
Start from a proof and follow the chain. No account or key is needed at any step.
GET https://api.verifyum.com/v2/proofs/{proof-id}/witnesses
GET https://api.verifyum.com/v2/proofs/{proof-id}/witness-chain
GET https://verifyum.com/witness/checkpoints/{hourly|daily}/{batch-id}.json
GET https://verifyum.com/witness/receipts/{hourly|daily}/{batch-id}.jsonThe first returns the path from your proof to its hourly checkpoint. The second proves that exact hourly checkpoint belongs to the daily checkpoint and names both receipt documents. The remaining routes return exact checkpoint bytes and what each channel has confirmed so far. A daily bridge may return 404 until the next daily checkpoint. It contains only your proof's paths, never a member list.
Channel states
A channel reports pending, confirmed, unavailable or failed. Bitcoin anchoring takes hours by design, and a daily certificate waits for log incorporation. A pending or missing witness never invalidates the Solana proof.
Privacy
External services see the checkpoint document: a Merkle root, the period it covers, when it was made, how many proofs it contains and the previous checkpoint's hash. They cannot derive the members from the root, and they never receive your file, its hash, the nonce or your proof ID.
Honest limits
Extra witnesses make the record harder to erase or backdate. They do not change what a proof means, and the number of channels is not a quality score.