Workers

The gateway uses background tasks so admission does not need to hold an HTTP request open while witnesses are contacted. Work is represented in SQLite and can be reclaimed after a process restart or an expired lease.

Attestation reconciler

The reconciler repeatedly asks storage for one due pending or retryable job. A claim contains an opaque random 32-byte lease token, an expiry, and the canonical attestation tuple. The default lease is 30 seconds; witness requests default to a 10-second timeout and the idle loop sleeps for one second.

pending/retryable
        |
        | claim if due and lease absent/expired
        v
 +----------------+
 | leased attempt |
 +-------+--------+
         |
   +-----+----------------------+
   |                            |
 threshold reached       timeout / bad quorum
   |                            |
   v                            v
 final verify              retryable + backoff
   |                            |
   v                            +----> later claim
 confirmed

The worker fans out to witnesses in parallel. It stops collecting once the threshold is reached and cancels outstanding requests. Every accepted response must match the expected witness ID, be unique, and verify under the configured public key. The final aggregate is verified again before completion.

Completion checks the lease token, expiry, hash, timestamp, network ID, and sequence. A stale worker therefore cannot replace a result completed by a later worker. Signature rows are replaced atomically with the verified result.

Transient quorum failures use exponential retry scheduling capped at 300 seconds. Configuration invariant failures, such as an invalid key or duplicate canonical witness key, are terminal failures rather than endless retries.

The reservation timestamp is immutable: retries sign the tuple captured when the job was reserved; they do not refresh its timestamp. Witnesses reject a request once that timestamp is outside their max_clock_skew window (300 seconds by default). Consequently, a sufficiently long witness outage can make an otherwise valid reservation impossible to complete after service returns. This is a terminal failure in effect for that reservation, even though the generic quorum path records witness failures as retryable rather than replacing the tuple with a new timestamp.

Batch manager

The batch manager periodically selects confirmed, unbatched attestations in deterministic (sequence, hash) order. It does not use a timestamp watermark, so a job that confirms after a long retry remains eligible. It stores the batch and its Merkle membership transactionally.

The current implementation starts the periodic batch manager only when federation is enabled and batch_period is non-zero. On each close it also issues an RFC 9162 STH over the complete closed-batch log. STH signing uses the same witness endpoint and threshold verifier as ordinary attestations. If STH signing fails, the batch remains stored; a later close can issue a later STH.

Anchor manager

After a batch is closed, the anchor manager starts provider requests in the background and in parallel. It persists successful ExternalAnchorProof records only when the configured minimum_required number of providers succeed. Anchoring does not change the already-confirmed attestation and is not required for its threshold signature.

Provider failures are logged as failures; they are not converted into proof records. The supported providers and their operations are listed in the anchoring model. The hardened outbound client applies to Internet Archive, while Trillian and DNS use unrestricted reqwest; Ethereum has URL preflight validation only. Provider transport therefore remains an operational risk that requires review.

Federation client

The federation client also runs after batch closure. It submits the batch to configured peer gateways. Each peer can produce a signed attestation over the batch Merkle root in the peer's own network. Requests are asynchronous and bearer-authenticated. Cross-anchor verification requires the peer's public verification configuration.

Federation and external anchoring are durability layers after home-network confirmation. Neither worker is a consensus or rollback-prevention mechanism by itself.