Independent evidence around a proof
A Verifyum proof stands on its Solana transaction and its signed metadata. The Witness Layer adds more places where the same evidence turns up, so a reader does not have to trust any single system, including ours.
How it works
Every finalized proof becomes a leaf in an hourly Merkle tree. The tree produces one root, and only that root travels to the external witnesses. 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.
01
Contributes: the primary timestamp. 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.
02
Contributes: an Ed25519 signature over the public metadata, checked against a published key registry.
Why it matters: it ties the metadata document to Verifyum, so a modified copy is detectable. This is the one record that does depend on us, which is exactly why the others exist.
03
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, which is the strongest durability guarantee available. It is slow, so it complements Solana rather than replacing it.
04
Contributes: each hourly checkpoint is committed to a public repository, bound to an immutable commit ID.
Why it matters: it is trivially readable by a human, hosted by a third party, and a rewritten history would be visible to anyone watching the repository.
05
Contributes: the public checkpoint page is captured by the Wayback Machine with the archive's own timestamp.
Why it matters: a well-known independent archive holds a dated copy, in a form that a non-technical reader can inspect in a browser.
06
Contributes: one certificate per day is issued for a hostname that encodes the daily checkpoint root, and it enters append-only CT logs.
Why it matters: CT logs are operated by browser vendors and CAs, monitored constantly, and cryptographically append-only. Verifyum verifies the inclusion proof itself before treating the entry as confirmed.
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://verifyum.com/witness/checkpoints/{hourly|daily}/{batch-id}.json
GET https://verifyum.com/witness/receipts/{hourly|daily}/{batch-id}.jsonThe first returns the Merkle path from your proof to a checkpoint. The second returns the exact checkpoint bytes the witnesses received. The third reports what each channel has confirmed so far, with artifact digests and provider references you can check against GitHub, the Internet Archive and the CT logs.
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 that Verifyum published a batch checkpoint. 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.