External anchoring
External anchoring is optional. When enabled, the gateway's background anchor
manager submits a closed batch and its Merkle root to configured providers.
minimum_required controls how many provider successes are required for the
anchor operation. Anchoring is asynchronous and provider outages do not alter
the already-confirmed home attestation.
The current provider implementations are:
| Provider | Current operation |
|---|---|
| Internet Archive | Sends a deterministic data URL containing network, batch, root, period, and count to the Save API. |
| Trillian/Tessera | Adds a JSON batch entry to the configured log and records returned tree/index/inclusion data. |
| DNS TXT | Requests a TXT record named _witness-<batch>.<domain> containing the batch ID, root, network, period, and count. |
| Ethereum/blockchain | Sends a zero-value transaction to itself with the raw 32-byte Merkle root as input data and waits for a receipt. |
Each successful provider produces an ExternalAnchorProof containing a
provider type, local creation timestamp, provider-specific JSON, and sometimes
the anchored bytes. The gateway persists proofs and exposes them through
/v1/anchors/:hash and proof bundles.
Internet Archive requests use the gateway's hardened HTTP client and resolver.
Trillian and DNS currently use unrestricted reqwest clients. Ethereum checks
the RPC URL with URL preflight validation during provider initialization, but
its subsequent RPC traffic does not use the hardened client. Ethereum anchoring
also requires a signing wallet, so operators must protect those credentials and
account for gas.
Implemented behavior
Anchors commit batch metadata/root, not the original document. They are independent durability signals layered after home threshold signing and batch closure. Providers can be enabled independently, and failures return provider errors rather than fabricating a proof.
Assumptions
The external service's own availability, retention, DNS semantics, log policy, or blockchain finality are trusted according to the operator's threat model. An Ethereum receipt is evidence of a mined successful transaction, not a universal finality guarantee.
Non-goals
Anchoring does not turn Witness into a blockchain consensus system, replace the home witness threshold, reveal document content, or prove authorship. It also does not make every returned provider record independently verified by the current offline proof-bundle verifier.
TODO — maintainer review
Review each provider's outbound transport and SSRF behavior as an operational risk, especially the unrestricted Trillian/DNS clients and Ethereum's preflight-only URL check. Also review proof and finality semantics, especially DNS propagation, Internet Archive Save API behavior, Trillian response validation, and Ethereum confirmation depth. Add explicit provider verification before calling anchors “verified” rather than “present.”