Skip to content

Anchoring

Blockchain anchoring is the practice of committing a cryptographic hash of off-chain data to a blockchain, creating a timestamped, tamper-evident record that the data existed in a specific state at a specific point in time. The data never touches the chain — only its 32-byte fingerprint does. This idea predates Bitcoin by nearly two decades: Stuart Haber and W. Scott Stornetta proposed cryptographic timestamping in 1991, and Satoshi cited their work three times in the Bitcoin whitepaper.

TL;DR

  • Anchoring embeds a hash of off-chain data into a blockchain transaction — proving the data existed before a specific block, without revealing the data itself.
  • Aggregation services batch thousands of hashes into a Merkle Tree, then anchor the single root on-chain. One Bitcoin transaction can timestamp unlimited documents.
  • Bitcoin uses OP_RETURN outputs (~$0.02-0.30 per anchor). Ethereum uses calldata or event logs (~$0.50-5.00). Hedera HCS uses native topic messages (~$0.0008).
  • Anchoring proves existence at a time — not authorship, not authenticity, not that the data is true.
  • The concept was invented in 1991 by Haber and Stornetta. Their company Surety has published a hash chain in the New York Times classified section every week since 1995 — the world's longest-running hash chain.
  • Real legal weight: a French court in March 2025 gave "full probative weight" to Bitcoin-anchored timestamps as copyright evidence. China's Supreme People's Court formalized blockchain evidence admissibility in 2018.

What Is Anchoring?

You hash your data locally. You submit the hash to a blockchain. The blockchain's consensus mechanism guarantees that hash was included at a known block height with a known timestamp. Anyone with the original data can re-hash it and verify it matches the on-chain record.

The blockchain knows nothing about the data itself. It stores a 32-byte hash. The proof is that this particular hash existed before this particular block was mined.

flowchart LR
    subgraph Off-Chain
        D["Document / Data"]
        H["SHA-256 Hash<br/>(32 bytes)"]
    end
    subgraph Aggregation
        M["Merkle Tree<br/>(many hashes)"]
        R["Merkle Root<br/>(32 bytes)"]
    end
    subgraph On-Chain
        TX["Blockchain Transaction"]
        B["Block Header<br/>(timestamp + block hash)"]
    end

    D --> H
    H --> M
    M --> R
    R --> TX
    TX --> B

Figure 1: Anchoring flow. Data is hashed locally, aggregated into a Merkle tree with other hashes, and the single root is committed to a blockchain transaction. The block header provides the timestamp.

How It Works

Step by Step

  1. Hash the data off-chain (SHA-256, Keccak-256, etc.). The data never leaves your system.
  2. Submit the hash to an aggregation service (or directly to the chain).
  3. The service batches many hashes into a Merkle Tree and submits the single Merkle Root to a blockchain.
  4. The transaction is included in a block. The block's timestamp and hash become the proof.
  5. To verify: re-hash the original data, walk the Merkle Proof to reconstruct the root, confirm the root exists in the specified transaction, confirm the transaction exists in the specified block.

No trust in the timestamping service is required for verification — only trust in the blockchain itself.

Bitcoin: OP_RETURN

OP_RETURN is a Bitcoin Script opcode that marks a transaction output as provably unspendable. It allows arbitrary data to be embedded in a transaction without polluting the UTXO set — nodes can safely prune OP_RETURN outputs because they know the funds are unspendable.

ATTRIBUTE DETAIL
Data limit 80 bytes (legacy), effectively unlimited post-Bitcoin Core 30 (Oct 2025)
Typical payload 32-byte SHA-256 hash
Transaction size ~230-250 vB
Cost at 1 sat/vB ~$0.02-0.03
Cost at 10 sat/vB ~$0.20-0.30
Confirmation time ~10 min (1 block), ~60 min (6 confirmations)

Before OP_RETURN, people embedded data in fake P2PKH outputs that looked like real transaction outputs but were actually unspendable. This polluted the UTXO set because nodes could not distinguish them. OP_RETURN solved this by making unspenability explicit.

Ethereum: Calldata and Event Logs

On Ethereum, the simplest approach is sending a transaction with the hash in the calldata field.

METHOD GAS COST NOTES
Calldata (32-byte hash) ~21,500 gas Base tx (21,000) + calldata (512 gas for 32 non-zero bytes)
Event log (LOG0) ~22,000+ gas Base tx + contract execution + 375 base + 8 gas/byte
Storage (SSTORE) ~43,000+ gas Base tx + 22,100 gas per new storage slot

Event logs are stored in transaction receipts, not contract storage. They are readable off-chain via node APIs but not accessible from within smart contracts — making them a natural fit for anchoring where on-chain readback is unnecessary.

Note

EIP-7623 (Pectra upgrade, May 2025) increased calldata costs from 4/16 to 10/40 gas per zero/non-zero byte for data-heavy transactions. For a 32-byte hash this raises calldata cost to ~1,280 gas — still well under $1 at moderate gas prices.

Hedera Consensus Service (HCS)

Hedera takes a different approach. HCS is a native topic-based messaging system purpose-built for ordered, timestamped message submission — not an OP_RETURN workaround.

  1. Create a topic via TopicCreateTransaction.
  2. Compute the Merkle Root of your data batch locally.
  3. Submit the root as a message to the topic via TopicMessageSubmitTransaction.
  4. Hedera's hashgraph consensus (asynchronous BFT) timestamps the message within seconds.
  5. Verify via the public Mirror Node REST API.

Cost: $0.0008 per message (as of January 2026 — the first pricing change since Hedera's 2019 launch). Messages are limited to 1 KB, transactions to 6 KB (the SDK handles chunking). Finality is deterministic within 3-5 seconds.

Anchoring Services

Comparison

SERVICE CHAIN LAUNCHED COST MODEL
OpenTimestamps Bitcoin 2016 Free Open source, calendar servers
Chainpoint Bitcoin 2015 Free (protocol) Open protocol, Lightning-based fees
OriginStamp Bitcoin, Ethereum 2013 Commercial API SaaS platform
Guardtime KSI Independent 2008 Enterprise Hash-only, no asymmetric crypto
Hedera HCS Hedera 2019 $0.0008/msg Native protocol feature
Factom / Accumulate Bitcoin, Ethereum 2015 / 2022 ~$0.15-0.25 Dedicated anchoring protocol

OpenTimestamps

Created by Peter Todd (earliest commits June 2012, publicly announced 2016). Open source, free, Bitcoin-anchored.

The process:

  1. Client hashes the file (SHA-256), appends a random 128-bit nonce for privacy, hashes again.
  2. Submits to aggregation servers (a.pool.opentimestamps.org, b.pool.opentimestamps.org).
  3. Aggregation servers batch all hashes received in a 1-second interval into a Merkle tree.
  4. Calendar servers embed the root in a Bitcoin OP_RETURN transaction (at most one tx per block — 144/day max).
  5. The user receives an .ots file containing the cryptographic path from their hash through the aggregation tree to the Bitcoin block header.

The .ots format is a binary file starting with magic bytes encoding "OpenTimestamps" + "Proof" + version, followed by a tree of commitment operations (sha256, ripemd160, append, prepend) with attestation leaves.

Calendar server trust is limited: the worst a calendar can do is go offline. It cannot forge timestamps — Bitcoin provides the proof. Clients default to submitting to both calendars for redundancy.

In 2017, Peter Todd timestamped approximately 750 million files from the Internet Archive using a single Merkle tree anchored in one Bitcoin transaction.

OpenTimestamps also integrates with Git — timestamps are appended to PGP-signed commit signatures, proving a commit existed before a signing key was potentially revoked.

Guardtime KSI

Developed in 2008 for the Government of Estonia, KSI (Keyless Signature Infrastructure) takes a fundamentally different approach: it uses only hash-function cryptography. No public/private keys, no key management, no key expiration. Signatures are "keyless."

This makes KSI quantum-resistant by design — because it relies solely on hash functions, not asymmetric cryptography. Deployed across Estonian government health, justice, and business registries, plus enterprise telecoms, aerospace, defense, and financial services.

Use Cases

Anchoring has real legal weight in multiple jurisdictions:

  • France (March 2025): The Tribunal judiciaire de Marseille gave "full probative weight" to Bitcoin-anchored timestamps as copyright evidence. Fashion sketches were timestamped via a blockchain service in 2021, and the court accepted the timestamps as part of the evidence establishing ownership.
  • China (June 2018): The Hangzhou Internet Court became the first court worldwide to accept blockchain-based evidence. China's Supreme People's Court formalized this in September 2018, confirming that evidence authenticated by timestamps, hash verification, and blockchain is admissible.
  • United States: Arizona (2018), Washington (2019), and Illinois (2020) enacted legislation establishing that records on a blockchain cannot be denied legal effect solely because they were stored on a blockchain.
  • EU eIDAS: Regulation 910/2014 defines "qualified electronic time stamps" as a legal framework. Blockchain timestamps are not yet recognized as "qualified" (which requires a Qualified Trust Service Provider), but academic research proposes combining blockchain timestamps with eIDAS services.

Supply Chain and Audit Trails

Anchoring product metadata and chain-of-custody events creates tamper-evident records. Each checkpoint (origin, processing, shipping, delivery) is hashed and anchored. Tampering with any record invalidates the hash chain. Guardtime KSI has been deployed in this capacity across Estonian government registries since 2008.

L2 Rollup State Anchoring

Both Optimistic and ZK rollups anchor their state to Ethereum L1 — the same principle applied at protocol scale:

  • The rollup sequencer batches L2 transactions and computes a new state Merkle Root.
  • That root is posted to an L1 contract (as calldata pre-EIP-4844, as blobs post-EIP-4844).
  • For ZK rollups, a validity proof accompanies the root. For optimistic rollups, the root is presumed valid unless challenged within a ~7-day dispute window.

This is document timestamping at protocol scale: one root on L1 commits to an entire batch of L2 state transitions. EIP-4844 (Dencun upgrade, March 2024) reduced L2 anchoring costs by over 90% by introducing blob data with a separate fee market.

Polygon PoS uses a similar checkpoint system — approximately every 30 minutes, a Merkle root of ~10,000 Polygon block headers is submitted to Ethereum with 2/3+ validator signatures.

Risks & What Can Go Wrong

Anchoring Does Not Prove What You Think

WHAT ANCHORING PROVES WHAT IT DOES NOT PROVE
This hash existed before block N Who created the data
The data has not changed since anchoring That the data is true or accurate
A specific commitment was made at a specific time That the data was not created earlier

This is the most common misunderstanding. A timestamp proves existence at a time. It does not prove authorship, authenticity, or originality. If two people independently hash the same document, both get valid timestamps.

Data Availability

The blockchain stores a hash, not the data. If the original document is lost, the timestamp proof is worthless — you cannot reconstruct data from its hash. Anchoring shifts the data preservation burden entirely onto the user.

Calendar Server Dependency

Until an OpenTimestamps proof is "upgraded" with the full Bitcoin attestation, it depends on the calendar server's promise to eventually anchor to Bitcoin. The server cannot forge timestamps (only Bitcoin provides the proof), but it could go offline, leaving users with incomplete .ots files. Mitigation: submit to multiple calendars; proofs can be completed independently.

Timestamp Granularity

Blockchain timestamps are block-level, not second-level:

CHAIN BLOCK TIME TIMESTAMP ACCURACY
Bitcoin ~10 min Within ~2 hours (nodes reject future timestamps >2 hrs)
Ethereum ~12 sec Per-slot granularity (~12 sec)
Hedera 3-5 sec Consensus timestamp (median of node observations)

You cannot prove a document existed at 14:32:07 UTC. You can prove it existed before a specific block was mined at approximately that time.

Reorganization Risk

On Bitcoin, a timestamp in a recent block could theoretically be reversed by a chain reorganization. Six confirmations (~1 hour) provides strong probabilistic finality. On Ethereum post-Merge, finality is deterministic after ~13 minutes (2 epochs).

Historical Context

The concept of cryptographic timestamping predates Bitcoin by 18 years.

In 1991, Stuart Haber and W. Scott Stornetta published "How to Time-Stamp a Digital Document" — proposing a system where document hashes are linked into a chain maintained by a Time-Stamp Service, with periodic "wide publication" of the chain state to make tampering detectable. Their 1993 follow-up introduced Merkle trees for batching efficiency.

Satoshi Nakamoto cited three Haber/Stornetta papers as references 3, 4, and 5 of the Bitcoin whitepaper — making them the most-cited authors in the document (3 of 8 total references). Bitcoin essentially decentralized their trusted Time-Stamp Service using Proof of Work and consensus.

Haber and Stornetta commercialized their work through Surety, which launched the "AbsoluteProof" service in 1995. To create a widely witnessed public record, Surety has published the hash chain's interval hash in the New York Times classified section every week since 1995. Over 30 years of continuous operation — the world's longest-running hash chain, predating blockchain by 14 years.

YEAR EVENT
1991 Haber/Stornetta publish "How to Time-Stamp a Digital Document"
1993 Follow-up paper introduces Merkle tree batching
1995 Surety launches AbsoluteProof; begins New York Times publications
2001 RFC 3161 standardizes Time-Stamp Protocol
2008 Guardtime KSI deployed for Estonian government
2009 Bitcoin launches (Satoshi cites Haber/Stornetta)
2013 OriginStamp becomes operational
2014 Bitcoin Core 0.9.0 introduces standardized OP_RETURN (40-byte limit)
2015 Chainpoint/Tierion and Factom launch
2016 OpenTimestamps publicly announced
2017 OpenTimestamps timestamps 750M Internet Archive files
2019 Hedera Consensus Service goes live
2022 Factom transitions to Accumulate Network
2025 Bitcoin Core 30 effectively removes OP_RETURN size limit
2025 French court accepts Bitcoin timestamps as copyright evidence

References

Changelog

DATE AUTHOR NOTES
2026-03-18 Artificial. Generated by robots. Gas: 80 tok
2026-03-19 Denizen. Reviewed, edited, and curated by humans.