Frequently Asked Questions
Answers to common questions about the RelTime Protocol, zero-knowledge hashing, and enterprise scaling.
1. General, Privacy & Verification
Does RelTime read, store, or host my enterprise documents?
No. RelTime operates on a strict Zero-Knowledge basis. When you upload or submit a document, your local client or server converts the file into a cryptographic SHA-256 hash. We never see the binary data of your original document—we only receive and anchor the hash.
What happens if I lose my original file?
Because we do not store your files, record keeping is entirely your responsibility. If you lose the original binary file, you will never be able to regenerate the exact hash to match against our JSON/HTML certificates. RelTime acts as a Cryptographic Anchor, but you must keep the original document safe.
How do I verify a document in the future?
To verify a document, you take your preserved original file and run it through a standard SHA-256 algorithm to generate its hash.
For Universal Users (Tier 2): You compare your file's hash against the client_hash stored in the JSON certificate. If they match, you can immediately verify that hash against the public Merkle Root on the Bitcoin Timechain.
For Enterprise & Agents (Tiers 3/4): Because the absolute microsecond of arrival is critical, your Timechain settlement uses a Temporal Anchor. You must mathematically combine your file hash with the VDF state provided in your receipt to recalculate the T_index, and then verify that T_index against the Timechain.
Alternatively, simply drag and drop the exact file back into our Universal Anchor interface. Our system will automatically resolve the correct pathway and immediately display:
[ HISTORICAL ANCHOR VERIFIED ]SETTLED AT BITCOIN HEIGHT: (block number)
2. The Verifiable Delay Function (VDF)
What is the Thermodynamic Proof ($T_{index}$)?
The Thermodynamic Proof ($T_{index}$) is a cryptographic hash that perfectly locks your document's identity to a precise point in physical time. It is calculated by hashing the current live state of our VDF engine (VDF_Current_Hash) together with your document's hash (Client_ZK_Hash).
Does my server need a fast CPU to use the API?
No. The VDF engine runs centrally on RelTime's infrastructure. Your hardware does not perform the sequential hashing. Your hardware only needs to compute the initial one-time SHA-256 hash of your document, which takes milliseconds on any modern device.
How many VDF ticks occur in a second?
Because our centralized VDF engine runs in an un-throttled, isolated core, it performs millions of hashes per second (typically 2 to 20 million depending on hardware). This generates extreme temporal density, allowing us to sequence documents arriving microseconds apart.
3. Enterprise Scaling & Batching
What happens when multiple enterprise clients anchor documents at the exact same time?
When payloads arrive simultaneously, they each receive a unique $T_{index}$ from the VDF engine, giving them perfect sub-second ordering relative to each other. All hashes collected within a ~10-minute window are aggregated into a single Merkle Tree. We then take the resulting singular Merkle Root and anchor it into the Bitcoin Timechain. This allows infinite scale without creating network congestion or incurring massive fees.