Pinning financial forecasts on Ethereum: what we tried in 2023, and what we'd do now.
Our 2023 piece used the Ethereum mainnet to pin SHA-256 hashes of quarterly forecasting parameters as a tamper-evidence layer. The use case held; the chain choice didn't. Here's the honest update.
In 2023 we wrote up a real-world use of public blockchain that we have since deprecated in favour of cheaper, less symbolic, equally effective alternatives. The original piece (Team-Notes #60) described pinning SHA-256 hashes of a Singapore commercial-real-estate company’s quarterly financial-forecasting parameters and reports onto Ethereum mainnet via Nethereum and zero-value transactions. The aim was tamper-evidence: a finance director could later verify the forecast hadn’t been altered after publication.
The use case is still live. The chain choice was wrong. Here is the rewrite, with our honest hindsight.
What we got right
- Hashes, not data. Nothing sensitive ever went on-chain. Only SHA-256 of
(settings || timestamp). This part of the design we’d keep verbatim. - The use case itself is real. “I need to prove this number wasn’t edited” is a normal request from finance directors and audit teams. Tamper-evidence pinning is the right shape of solution.
What we got wrong
1. Ethereum mainnet was a bad choice
We picked Ethereum because it had the most credibility in 2022–2023. Three problems:
- Gas prices are real and unpredictable. A pinning operation that cost ~USD 2 in early 2023 cost USD 12 by mid-2024 during one fee spike, with the client’s quarterly cycle landing in the spike. We were paying real money for an audit-trail line.
- Settlement latency is irrelevant for this use case. We waited for confirmations on a transaction that was only ever going to be read again at audit time, weeks or months later.
- “Public blockchain” sounded like security; it was really just durability with a fee. The chain doesn’t validate the forecast. It only proves the hash existed at a block height.
2. Verification was clunky
The 2023 article retrieved the transaction by block number / index and parsed the input data. It works. It also requires either an Ethereum node or a third-party provider for every verification — a friction the auditor felt every quarter.
What we’d do now
In 2024 we migrated this client to a much simpler design. Two layers:
Layer 1: A trusted timestamp authority
Use RFC 3161 trusted timestamps from a reputable timestamping authority (FreeTSA, DigiCert, or a paid provider). The TSA returns a signed timestamp token over a hash you provide. Verification is offline once you have the TSA’s certificate. There is no chain.
// pseudocode
var hash = SHA256.HashData(SerializeForecast(forecast));
var token = await tsa.RequestTimestampAsync(hash);
File.WriteAllBytes("forecast-q3-2026.tsr", token);To verify: take the original forecast, recompute the hash, run the TSA’s verifier against the saved .tsr file. Done.
For most “prove the report wasn’t edited after publication” needs, this is sufficient and dramatically cheaper.
Layer 2 (optional): A merkle root pinned somewhere boring
If the client wants the additional optical credibility of a public anchor, we batch the quarter’s hashes into a merkle tree and pin only the root somewhere we don’t pay gas for — for example, an OpenTimestamps anchor (which itself uses Bitcoin in batches, with negligible cost). The TSA covers verification; the merkle root is the optional paranoia layer.
When public chain pinning is still right
Two cases we’ve seen since:
- Cross-organizational consortium use cases where the parties don’t trust a single TSA. Public chain becomes the neutral arbiter. This is rare.
- Regulator-led pilots where the regulator has named a specific chain. We don’t argue.
For everything else: TSA is enough.
A word on the agent-era
Could an LLM-driven agent verify a forecast hash on demand for an auditor? Trivially yes, and we have built such a verification helper. It’s a deterministic operation wrapped in a chat UI; the agent’s only job is to make the tool friendlier to a non-technical user. That is, in our experience, the most honest way to use an agent in this kind of audit-adjacent work — as a UI shim over deterministic logic, not as the trust root.
What we cut from the original
- The recommendation of Ethereum mainnet. Wrong call, in retrospect.
- The implied permanence of “blockchain” as a security primitive. It is durability + neutrality, not security.
What carries over unchanged
The instinct: never put confidential data on-chain. Hash and pin only. That part of the 2023 design was right; we just picked the wrong place to pin.
— wGrow studio · migrated from Team-Notes #60