# Trust Model

That your hash existed before an ETC block rests on the chain, and two RPCs that agree on the block hash, or your own node, will confirm it. Etchd has to be trusted to stay up and to report honestly the second your hash arrived.

The chains alone show that your digest existed before the anchor block and an hourly Bitcoin block, and that the tick came after the UTXO and EVM heads in it. The second, the records Etchd saw and the service staying up rest on Etchd and Cloudflare.

| Claim | Who you trust |
| --- | --- |
| Your digest existed before the anchor block | ETC. Two RPCs that agree on the block hash, or your own node |
| It existed before an hourly roll-up reached Bitcoin | Bitcoin, through the OpenTimestamps calendars that carried the roll-up |
| It arrived in a given second | Etchd. The second is a claim inside the proof that nobody else can check |
| A tick was built after the chain heads it names | The headers, for UTXO and EVM chains, which you can check offline. Our RPC quorum and the sources we name, for the others |
| Etchd saw a head or captured a source | Etchd, and the signer list that ties the anchor to our key |
| The calendar keeps stamping | Etchd and Cloudflare |

## The Anchor Key

We limit what the anchor key can do. It lives only in a separate signer Worker, reached through a service binding, which signs anchor transactions and nothing else. Each one goes to the anchor contract with zero value and pays exactly 1 gwei, and the signer stops after 0.05 ETC in one UTC day.

A stolen key can burn the gas balance and send transactions that look like ours, but old proofs are out of its reach, since they rest on bytes already in ETC blocks.

A watchdog runs from the minute cron and compares the key's nonce on chain with the calendar's own count, and when the chain is ahead, someone else has signed with our key and anchoring halts. Rotation still works. On resume, the ticks the leaked key held move onto the new key, and the old epoch ends at its last tick that was still anchored. From then on the [signer list](https://etchd.app/docs/signers) marks the old key's later transactions as outside its window.

The other risk under every proof is a [reorg](https://etchd.app/docs/verifying#reorgs), which the calendar answers by anchoring the affected ticks again.

## One Vendor

The calendar runs on Cloudflare Workers, Durable Objects, R2 and D1, all on one Cloudflare account, and if that account stopped, live stamping would stop with it. Proofs already on chain would still verify against ETC, and the history would survive in the daily CAR bundles and in every [mirror](https://etchd.app/docs/mirrors) that holds them.

Only one calendar, `a`, runs today. Clients that want redundancy can stamp to several OpenTimestamps calendars at once, and the Bitcoin bridge puts a second chain under every hour.

## What We Do Not Know

The full threat model is in [docs/threat-model.md](https://github.com/classix-dev/etchd/blob/main/docs/threat-model.md), and the two gaps below are open items in [DEPLOY.md](https://github.com/classix-dev/etchd/blob/main/DEPLOY.md#open-items). Some platform behaviour is still unchecked on the production account, such as how the Workflows behind the Bitcoin bridge, the reorg audit and the daily export are billed and limited, and the export path for days over 5 MiB has not run anywhere yet.