Verifying

A pending proof becomes a full one once its tick's anchor transaction is mined on Ethereum Classic, and from then on checking it means reading one transaction from ETC RPCs, or from your own node, and comparing it with the proof.

Confirmations

The upgraded proof ends in an EtcTxAttestation. Its three numbers name the chain id, the block height and the position of the transaction in that block. The calendar serves it as soon as the anchor transaction is in a block, usually a minute or two after you stamp, and etchd upgrade --wait returns then.

Proof of work never makes a block final. Each new block on top makes a reorg that removes the anchor less likely, and how many confirmations are enough is for whoever checks the proof to decide. etchd verify accepts one by default and prints the count. A verifier that wants more asks for it, and until the anchor is that deep the command reports confirming and exits 2.

etchd verify report.pdf.ots --min-confirmations 400

Verifying

To verify, etchd verify reads the transaction at that height and position from at least two ETC RPCs that report chain id 61, and once they agree on the block hash it compares the transaction input with the 40 bytes the proof computes. By default it asks three RPCs, rpc.classix.dev, etc.etcdesktop.com and etc.drpc.org, set in packages/core/src/verify.ts. --etc-rpc points it at your own node.

The calendar itself reads ETC through a different list of four, rpc.classix.dev, etc.etcdesktop.com, 0xrpc.io/etc and etc.drpc.org, and needs two of them to agree. That list is ETC_RPCS in packages/worker/wrangler.jsonc.

Checking the Sender

The verifier also reads the sender of that transaction and looks it up in the calendar's list of signer keys at /v1/signers, and reports the key's epoch and whether the block falls inside that key's window.

For a plain stamp the sender makes no difference, since your digest existed before the block whoever sent the bytes. Beacon and witness records differ. A tick that commits to a Bitcoin head or a Certificate Transparency tree head says that the Etchd calendar saw that head and sealed it. Someone else could build a tick body of their own and post its root to the contract. Its proof of existence would check out. Only the sender tells them apart. We recommend counting a beacon or witness claim as ours only when the anchor came from a listed key inside its window.

etchd verify report.pdf.ots --signers https://etchd.app/v1/signers --require-known-signer

# or check against a copy of the list that you keep
curl -s https://etchd.app/v1/signers > signers.json
etchd verify report.pdf.ots --signers signers.json --require-known-signer

--require-known-signer applies the Signer Epochs rules from SPEC.md, implemented in packages/core/src/signers.ts, and with it an anchor from a key outside the list exits 3 while an unreachable calendar exits 4.

Reorgs

A timestamp only claims existence before a block, and a reorg can delay a proof but cannot forge one as long as the calendar anchors again. The Anchor re-checks each batch at 12 and 400 confirmations, and a daily audit re-reads every anchor past 400 from the last 30 days plus 200 random older ones. A moved anchor counts as an incident. The calendar records it and puts the affected ticks into a new transaction, and until that one is mined it answers a proof request with 404.

A proof upgraded before the reorg then points at a position holding a different transaction, or none. etchd verify says the anchor is no longer there and exits 6, and running etchd upgrade again swaps in the new anchor. The calendar sees a reorg when the tx would reach 12 confirmations, so for a few minutes after a shallow reorg it can still hand out the old anchor. Its Bitcoin branch stays valid the whole time, because tick roots never change.

$ etchd verify hello.txt.ots
ETC block 21470113 tx 3 mismatch, transaction input does not equal the proof message
The anchor tx is no longer at ETC block 21470113 tx 3. It was reorged out, or the proof is wrong. Run etchd upgrade hello.txt.ots to fetch the calendar's new anchor.
If upgrade changes nothing, the calendar has not seen the reorg yet. Try again in a few minutes.
reorged  hello.txt.ots

$ etchd upgrade hello.txt.ots
anchored, bitcoin pending  hello.txt.ots  upgraded