How We Run OpenTimestamps at 10 Million Signatures Per Day
· Mahdi Kazempour, Founder, Original Pictures
Definition: Running OpenTimestamps at scale means aggregating large volumes of manifest hashes into Merkle trees and committing only the roots to Bitcoin, so per-signature anchoring cost and on-chain footprint stay negligible.
TL;DR: You do not put ten million hashes on-chain. You fold them into Merkle trees, commit the roots, and hand each manifest a compact proof from its leaf to the anchored root. The per-signature cost falls below a millionth of a cent, and verification stays a single public-chain check.
The naive approach does not scale
Anchoring each hash in its own transaction would be slow and absurdly expensive at volume. The whole point of OpenTimestamps is aggregation: many hashes become leaves of a Merkle tree, and only the root is committed. Ten million daily signatures collapse to a handful of on-chain commitments.
Merkle tree design
We batch hashes into trees on a fixed cadence, balancing latency against batch size. A larger batch amortizes the on-chain cost further but makes a manifest wait longer for its anchor; a shorter window anchors faster at slightly higher cost. Each manifest keeps the sibling hashes along its path to the root, which is its proof.
Fee economics
Because only roots hit the chain, Bitcoin fees are spread across the entire batch. At ten million signatures a day the per-signature anchoring cost is below a millionth of a cent, dominated by the fixed cost of a few transactions rather than by volume. That is what makes anchoring free at every pricing tier.
Proof distribution and verification
Each manifest carries a small .ots proof. Verification walks the proof from the manifest hash to the committed root and checks the root against the Bitcoin block, with ots verify. No service call to us, no token, no trust in our uptime. The proof is self-contained and public-chain-checkable forever.
FAQ
What if Bitcoin fees spike?
Only roots are committed, so a fee spike affects a few transactions, not millions. Batch sizing absorbs volatility without changing per-signature economics materially.
Does a user need us to verify?
No. The proof plus a public block explorer is sufficient. That independence is the reason for anchoring in the first place.
Where Original Pictures stands today
Original Pictures ships three things today: a Sign API, a Verify API, and the SDKs that wrap them. One POST /v1/sign attaches a C2PA-format manifest, an invisible TrustMark watermark, and an OpenTimestamps anchor. The open-source verifier checks any of it without calling us.
Two things are on the near roadmap, and we name them as roadmap, not as shipped: C2PA Conformance Program recognition (target Q3 2026, until then our manifests use the published C2PA v2.2 format and any C2PA-aware validator can read them, but third-party validators will show our signer as not-yet-listed), and a consumer capture app (Q3 2026). We do not sell a capture SDK, and we do not claim Trust-List membership we do not yet hold.
Bottom line: Aggregate hashes into Merkle trees, commit roots, distribute compact proofs. That is how anchoring stays free per signature and verifiable forever without depending on us.
Related
Original Pictures is progressing through the C2PA Conformance Program; our signing certificate is not yet on the official C2PA Trust List. Target: Q3 2026. We will not describe ourselves as "C2PA-certified" until it is true.
Original Pictures provides content-provenance infrastructure. It does not by itself constitute legal compliance with the EU AI Act or any other regime; compliance depends on how you deploy it, your disclosures, and your governance. Figures are drawn from public reporting, verify against primary sources before citing in regulated materials. Nothing here is legal advice.
Last verified 2026-05-25. Author: Mahdi Kazempour, Founder, Original Pictures.