Architecture

Etchd runs on one Cloudflare account as two Workers, a few Durable Objects, D1, R2, KV and a set of Workflows. What it produces lands in Ethereum Classic and Bitcoin blocks and in daily files that other people keep.

Your digest, the chain heads and the witness captures reach the Anchor through their own Durable Objects. Once a minute the Anchor seals a tick into R2 and sends one transaction to Ethereum Classic, signed by a separate Worker that holds the key. Workflows take the hourly roll-up to Bitcoin and each day's CAR to IPFS and the mirrors.

What Runs Where

The etchd Worker takes all public traffic. Stock OpenTimestamps clients call its calendar endpoints, the explorer reads its JSON API under /v1, and the explorer itself ships from it as static assets. It keeps no state.

State sits in Durable Objects. Each one exists once, worldwide, with its own SQLite store, and because the Anchor is the only code that picks the anchor key's next nonce and runs as one instance, two ticks can't end up sharing a nonce even when an alarm fires late or a request retries.

The Aggregator gathers digests into one-second rounds and makes no network calls of its own, and a slow RPC node has no way to hold up your reply. Six Beacon Groups poll the chains' RPC nodes on their own alarms and keep a head once enough nodes agree on it. The Scheduler fetches the witness sources. The Feed streams ticks.

The key lives in a second Worker, etchd-signer, reached through a service binding. It signs a transaction only if it goes to the anchor contract with zero value and pays exactly 1 gwei, up to 0.05 ETC a day. A bug in the public API can't make it sign anything else.

D1 holds the indexes, with the beacon rows in a database of their own for each year, since a D1 database stops at 10 GB. R2 holds the bodies, meaning tick bodies, evidence, anchor records and the daily exports in etchd and the witness responses in etchd-witness-raw. KV holds settings.

Slow jobs run as Workflows. They retry each step and survive restarts, which suits the Bitcoin bridge, since it keeps upgrading an hour's roll-up for up to 30 days, and the daily export, which builds a CAR from R2 in many small steps. A cron fires once a minute to wake idle objects and start these jobs. It doesn't close ticks. The Anchor's own alarm does that.

The Life of a Stamp

Your browser or the CLI hashes the file and sends the digest (Stamping). The Aggregator adds 16 random bytes, puts it in that second's round and answers at once with a pending proof.

A second after the UTC minute ends, the Anchor collects the minute's rounds, the latest chain heads and the new captures and hashes them into a tick root (Ticks). It writes the tick body to R2. Then it asks the signer for a transaction and sends it to four ETC RPC endpoints (The ETC Anchor). Once a block includes it, etchd upgrade gets the full path, built by the Worker from the body in R2.

What Is Public

Whatever the anchors commit to can be read through the API and in the daily CAR (What We Publish). Your file stays on your machine. Your raw digest isn't stored either, because the calendar keeps one row per second with the nonced round inside it. The anchor key stays in the signer's secrets.

What Depends on Cloudflare

Live stamping does. So do the explorer and the API, and if the account stopped they would stop with it (Trust Model).

The anchors would outlast it. A proof with its ETC attestation verifies against ETC nodes you pick, and after the hourly roll-up it gains a Bitcoin attestation. History survives in the daily CARs, pinned on IPFS through Filebase and copied by anyone running etchd mirror, which checks each day against the CAR's own bytes before storing it. An archive.org copy joins them once that upload is switched on.

You can run the same stack on your own account with your own key (Self Hosting). Why we picked each Cloudflare product, and what we turned down, is in docs/design.md.