Stamping

Stamping sends a file's hash to the calendar and gets a pending proof back. The file stays with you. When the UTC minute closes, the hash joins a Merkle tree with the other hashes of that minute, one ETC transaction puts the root on chain, and what you keep at the end is a standard .ots file.

The tick for that minute also records where the moment sits against about 35 other chains.

Byte layouts live in SPEC.md. The reasoning sits in docs/design.md.

Hashing on Your Machine

The Stamp page and the etchd CLI both hash your file locally and send only the digest. In the browser a Web Worker hashes large files, and if you keep the network panel open while it runs you will see the digest go out and the file stay on the device.

Your file is hashed on your device. Only the 32-byte SHA-256 digest goes to the calendar, and the file never leaves.

The Round and the Pending Proof

By default the browser and the CLI send a SHA-256 digest of 32 bytes, though the calendar accepts any digest from 1 to 64 bytes. It appends 16 random bytes of its own, hashes the result with SHA-256 and puts that hash into a Merkle tree with every digest that arrived in the same second. The tree's root, prefixed with the second as a 4-byte number, is the round commitment. The pending proof comes back at once. Its attestation names the calendar, https://a.etc.calendar.etchd.app.

Every digest that arrives in the same second gets 16 random bytes from the calendar and joins one Merkle tree. The second goes in front of the root, and you get a pending proof back at once.

The Etchd CLI needs three commands.

Stamp, upgrade, verify

etchd stamp report.pdf          # hashes locally, writes report.pdf.ots
etchd upgrade report.pdf.ots    # fetches the ETC attestation once the anchor tx is mined
etchd verify report.pdf.ots     # checks it against two or more ETC RPCs

Stock OpenTimestamps clients stamp and upgrade against the same calendar URI unmodified, but they do not check the ETC attestation and list it as unknown. That step needs etchd verify or the Verify page.

What You Send Us

A digest longer than 64 bytes gets a 400. The CLI hashes files with SHA-256 by default and can use keccak256 instead, and a BLAKE3 digest is stamped as the SHA-256 of that digest. We store and serve no user data.

Your digest is not kept either. The calendar adds its 16 random bytes before hashing your digest into the round, stores one row per second and offers no lookup by raw digest. Proofs are found by commitment, or by dropping the .ots file on the Verify page. Your .ots file holds the only copy of the path from your hash to the chain. We recommend keeping it next to the file.

If you want the data itself public, pin it to IPFS yourself and stamp the CID.