Why Verifyum Keeps the Original File Private

The usual proof flow begins with an upload. That is a bad fit for contracts, unpublished work, source archives and internal records. The proof service receives the most sensitive item before it has proved anything. Verifyum was built around a smaller exchange.

The browser creates the private input

When a user selects a file, browser code reads its bytes and computes SHA-256 locally. It records the byte length and adds a random nonce. Those values form a versioned private manifest.

The manifest is canonicalized and hashed with a Verifyum-specific prefix. The result is a commitment. A commitment can be public without exposing the file hash, the nonce, the filename or the file itself.

Portable means the proof cannot depend on one database

A useful file proof has to survive a missing account, a closed company and a database that no longer answers. Verifyum's protocol keeps the private manifest with the user. Public proof metadata is designed to contain the commitment and the information needed to inspect a Solana transaction.

Full verification starts with the selected original file. The verifier hashes it again, checks its size, rebuilds the commitment and compares each result with the proof package. It also checks the finalized Solana transaction, its signer and its exact memo.

A blockchain time is not the file's birthday

A finalized transaction can show that a specific commitment existed by the recorded block time. It cannot show when the original file was created. It also cannot establish authorship, ownership or whether the contents are true.

That limit belongs in the product description because the distinction matters. Verifyum checks byte identity and the chain of evidence around a commitment. Other claims need other evidence.

Where the public service stands today

Public proof creation is live at Verifyum. The browser hashes the file, creates the private manifest, calculates the commitment and downloads the draft. The original file, filename, raw hash, nonce and private manifest are not uploaded.

Solana Mainnet anchoring is active. A public browser proof finalized through the credential-free production flow on 30 August 2026. The health endpoint reports the current network and anchoring state.

Witnesses see a checkpoint, not the file

Finalized proofs are grouped into hourly and daily Merkle checkpoints. Nine records surround each finalized proof.

The Solana transaction is the primary evidence. Deep Solana history generally requires an archival provider. The Sigsum digest is cosigned by Glasklar, Mullvad and Tillitis with a quorum of two out of three. The qualified timestamp uses RFC 3161. Its eIDAS Article 41(2) presumption covers the daily checkpoint root alone. A Verifyum user proof is not a qualified electronic timestamp. Verifyum is not a qualified trust service. Software Heritage and Internet Archive show what was stored. They do not establish when the original file existed.

Each external service receives only an aggregate checkpoint root. It never receives the original file, raw file hash, nonce, private manifest or proof ID. A public Merkle path lets someone who already knows a proof ID confirm that it belongs to a checkpoint.

Channel states are pending, confirmed, unavailable and failed. Merkle membership shows inclusion in a Verifyum checkpoint. A separate receipt shows whether an external channel confirmed it. A pending or missing witness does not invalidate the Solana proof or Verifyum signature. The number of channels is not a quality score. Read how the Witness Layer works.

Every finalized proof is also announced on Telegram and in the Atom feed. These are announcement channels and are excluded from the nine evidence records. Their timestamps date the announcement. They say nothing about the original file date.

Save the public link as QR or PDF

After finalization, the public proof link can be downloaded as a QR-code PNG or printed and saved as an A4 PDF receipt. These are convenient copies of the public proof. They do not replace the private draft.

Verifyum sends only the canonical public proof URL to POST https://aisenseapi.com/services/v1/qrcode_encode. The endpoint returns a Base64 PNG. The browser validates the PNG signature and size before using it. A QR failure does not affect the proof. The receipt then shows the public URL as text. The PDF receipt is assembled from public proof metadata and rendered locally by the browser.

The private draft and the later public proof are separate in the current flow. Keep the original file and private draft together, and also save the public proof link.

No account, crypto wallet or payment method is needed. Verifyum is currently free, and AI SENSE AS covers the network fee. A hard ceiling allows at most 10 new anchor reservations per rolling hour per IP. Lower safety limits may apply.

Built and operated by AI SENSE AS

Verifyum is an AI SENSE product. It applies the same rule we use for public APIs and machine tools: make the contract narrow, show the exact output and keep sensitive data out of the service when the job can be done locally.