Key takeaways
- A document anchor needs a ledger that is public, cheap and predictable per write, final within seconds, and likely to still be readable in a decade.
- Private ledgers fail the first test; proof-of-work chains struggle with the second and third. Hedera's Consensus Service was built for exactly this kind of timestamped message.
- LedgerSign pays the fee. Customers and signers never hold tokens, and the anchor format is frozen and self-describing so it can be read without us.
What does a document anchor need from a ledger?
Anchoring a document means writing a small, timestamped record that anyone can read later. That is a narrow job, and it puts specific demands on the ledger:
- Public and independently readable. If verification requires the vendor's permission or infrastructure, the anchor proves nothing the vendor's own database did not already claim.
- Predictable, low cost per write. Every completed document is anchored. A fee that swings with network congestion turns a fixed product cost into a variable one.
- Fast finality. The transaction id goes on the Certificate of Completion. Waiting minutes or hours for confirmation delays the certificate.
- A stable, documented API. Third parties must be able to fetch and decode the anchor without special tooling.
- Longevity and accountable governance. Documents are kept for years. The ledger has to be around, and readable, for at least that long.
- No token exposure for customers. A bank or law firm should not need to hold cryptocurrency to sign a lease.
Why not a private or permissioned ledger?
Because it defeats the purpose. A ledger operated by LedgerSign, or by a consortium LedgerSign belongs to, is only as independent as its operators. A verifier would have to trust that the operators did not rewrite history, which is the same trust a vendor audit log already asks for. The value of anchoring is that the record sits somewhere the vendor cannot edit, so the ledger has to be public and run by parties with no stake in any particular document.
Why not Bitcoin or Ethereum?
Both are public and both would work in principle. Both also carry costs for this particular job. Bitcoin confirms blocks roughly every ten minutes and treats settlement as final only after several more; a certificate would wait an hour for a transaction id. Ethereum is faster but prices transactions in gas that fluctuates with demand, so the cost of anchoring a document is not known until the moment it happens. Neither has a first-class primitive for publishing a timestamped message; the hash has to be smuggled into a transaction field or a smart contract, which adds complexity to every verifier.
None of this makes those networks bad. It makes them a poor fit for writing one small record per document, thousands of times, at a cost that has to be predictable enough to include in a monthly plan.
What is the Hedera Consensus Service?
The Hedera Consensus Service lets an application create a topic and submit messages to it. The network orders each message, assigns a consensus timestamp, and makes it available through mirror nodes and public explorers. It is, in other words, a purpose-built way to publish timestamped records, which is the whole of what a document anchor is.
Three properties made it the choice:
- Finality in seconds. Hedera's consensus algorithm reaches final agreement quickly, so the transaction id is available almost immediately after completion and goes straight onto the certificate.
- Fees fixed in U.S. dollars. A consensus message costs a fraction of a cent, and the fee schedule is denominated in dollars rather than in the network token, so anchoring cost does not move with the token price.
- Public mirror nodes with a REST API. Any verifier can fetch a transaction and its message with two HTTP requests, which is what the verify tool does in the browser.
Who runs Hedera?
The network is governed by the Hedera Council, a group of large enterprises and institutions from different industries and regions that operate the initial consensus nodes and vote on network policy, with term limits for members. The network's core code is developed in the open as Hiero, a project under the Linux Foundation's Decentralized Trust umbrella, and LedgerSign submits anchors through the open-source Hiero SDK. For a ledger that has to stay readable for the life of a loan file, named, accountable operators and open code both count.
What does an anchor cost, and who pays?
LedgerSign pays. Each anchor is submitted from LedgerSign's own network account, and the cost is part of the Business, Pro, and Enterprise plans. Customers never buy, hold, or see HBAR, and signers are never asked to do anything blockchain-related. The only artifact that reaches them is the transaction id on the certificate. Plan details are on the pricing page.
What would make us reconsider?
A change to the fee model that made per-message cost unpredictable, a governance change that concentrated control, or sustained availability problems would each prompt a review. Three design decisions limit the blast radius if that day comes:
- Signing never depends on the ledger. If Hedera is unreachable at completion, the document still completes and the anchor is submitted when the network is back.
- The anchor format is frozen and versioned. Every message carries a version number and plain JSON field names, so a reader in ten years can decode it without LedgerSign's code.
- Verification needs only the file, the certificate, and a public explorer. Anchors already written stay verifiable whatever LedgerSign does next.
How can I inspect an anchor myself?
Take any LedgerSign Certificate of Completion, open HashScan, and search for the transaction id printed on page 1. The message on that transaction contains the document's SHA-256 hash. Compare it with the hash of your file, or let the verify tool do the lookup. The full procedure is in how to verify a blockchain-signed document, and the mechanism behind it in how document hashing and blockchain anchoring work.