// How it works

From release to thermodynamic record.

An anchor is a cryptographic commitment that ties a software artifact to a specific Bitcoin transaction at a specific block height. Below is the full lifecycle — six stages, from the moment an artifact is sealed for release to the moment anyone can verify it against Bitcoin directly.


// The anchoring lifecycle

Six stages, one anchor.

An artifact passing through the Hashstone lifecycle — released, hashed, batched, anchored, accumulated, verified. Step through it, or let it run.

Stage 01 · vendor trust domain

Release
Hash
Batch
Anchor
Accumulate
Verify
Click any stage to jump · hover to pause

// The guarantee strengthens with time

Six tiers, indexed to physical work.

A guarantee isn't binary — it deepens as Bitcoin accumulates work beneath the anchor. Hashstone reports one of six tiers, each tied to a meaningful operational time scale on the network. The ladder is readable without Bitcoin context: a higher tier means more accumulated physical work stands between the anchor and any attempt to rewrite it.

Tier Confirmation depth Approximate time Energy below anchorapprox. What it means
Minimal0 – 1< 10 min~3 GWhFirst inclusion. The anchor is in the mempool or a single block.
Low2 – 5~10 min – 1 hr~6 GWhBelow Bitcoin's settled-convention threshold.
Moderate6 – 35~1 – 6 hr~17 GWhAt or beyond Bitcoin's conventional settlement depth.
High36 – 143~6 hr – 1 day~100 GWhSubstantial accumulated work beneath the anchor.
Very High144 – 999~1 day – 1 week~400 GWhDay-scale commitment — roughly seven minutes of the entire world's electricity.
Extreme1,000+~1 week+~2.9 TWhWeek-scale physical commitment.

Thresholds correspond to operational time scales — roughly an hour, six hours, a day, a week — rather than arbitrary numbers. The verification engine reports the tier alongside the underlying confirmation depth, so the raw number is always available beneath the label.

On the energy figures. "Energy below anchor" approximates the physical work an attacker would need to re-expend to rewrite the anchor — confirmation depth multiplied by the average energy of one Bitcoin block (~2.85 GWh, derived from a network draw of roughly 17 GW). These are order-of-magnitude estimates, not exact measurements: Bitcoin's energy use is itself estimated and moves with price and hashrate. Network figures follow the Cambridge Bitcoin Electricity Consumption Index, whose 2025 estimates span roughly 138–175 TWh per year; the global-electricity comparison uses IEA Global Energy Review 2025 figures. Both are revised over time. Hashstone reports the underlying confirmation depth so the guarantee never rests on the estimate alone.


// What you're actually trusting

If Hashstone disappears, the anchors remain.

Hashstone writes the anchor and gets out of the way. The thing doing the work isn't a Hashstone server — it's the combination of Bitcoin's proof-of-work, the open HSP/1.0 anchor format, and the Bitcoin network itself. Hashstone employs that primitive on behalf of its customers; it is not the primitive.

That distinction is the whole point. An integrity primitive that depends on its publisher to vouch for itself isn't a primitive — it's a vendor.

Verification never contacts Hashstone. The client re-hashes the artifact, fetches the Bitcoin transaction by ID, validates the Merkle proof against the OP_RETURN data, and checks confirmation depth — querying Bitcoin directly.

So the guarantee survives the company. If Hashstone shut down tomorrow, every anchor already written would remain verifiable, and anyone could implement HSP/1.0 against Bitcoin and participate in the same primitive. The loop closes against physics, not against us.