How we made our trading-signal track record tamper-evident with a SHA-256 hash chain

EzathDEV — Sun, 14 Jun 2026 10:51:18 +0000

A trading-signal service has an obvious trust problem: anyone can screenshot their winners and quietly delete their losers. "We're up 240% this year" is unfalsifiable marketing. We wanted our published track record to be something a skeptical stranger could verify rather than take on faith — so we built it as an append-only, hash-chained log. Here's the design and why it works.

The threat model

The thing we're defending against is us — the operator editing history after the fact:

Deleting a losing trade after it closes.
Back-dating a winner we "would have" called.
Quietly changing an entry or exit price once the real one looks bad.

A plain database table defends against none of that, because the operator owns the database. So the integrity guarantee has to live in something the operator can't silently rewrite.

The hash chain

Every signal, when it's published, becomes a record:

{
  "seq": 1184,
  "symbol": "BTCUSDT",
  "side": "long",
  "entry": 64120.0,
  "stop": 62800.0,
  "target": 67000.0,
  "published_at": "2026-06-12T09:31:00Z",
  "prev_hash": "9f2c...",
  "hash": "1a7e..."
}

The hash of each record is SHA-256(prev_hash + canonical_json(payload)). Because every record commits to the one before it, you can't change record 1000 without recomputing 1001, 1002, ... all the way to the head. It's the same primitive a blockchain uses, minus the distributed consensus we don't need.

def append(record, prev_hash):
    payload = canonical_json(record)        # sorted keys, no whitespace
    record["prev_hash"] = prev_hash
    digest = sha256((prev_hash + payload).encode()).hexdigest()
    record["hash"] = digest
    return record

Making it externally checkable

A hash chain only the operator can see is just a fancy internal log. Two things make it actually falsifiable by an outsider:

The whole chain is public. Anyone can fetch every record and recompute the chain themselves — pull the JSON, recompute each hash, assert it matches the next record's prev_hash.
The head is committed at the time of the call. Each signal is timestamped and pushed to subscribers the moment it opens, before the outcome is known. The entry, stop and target are locked in before price moves — so you can't retro-fit a winner.

If we ever edited a past trade, the recomputed chain would diverge from any copy someone saved earlier, and the tamper would be obvious.

What it does and doesn't prove

It does not prove we're profitable — a hash chain will faithfully record a terrible strategy. What it proves is narrower and, I'd argue, more important for trust: the record you're looking at is the same record we committed to at the time, losses included. No survivorship editing.

One gotcha worth flagging if you build something similar: float formatting in the canonical form. 64120.0 vs 64120 vs 6.412e4 all hash differently, so you have to pin a single serialization (we normalize to fixed decimals before hashing) or the chain breaks for innocent reasons.

The live, recomputable version is here: ezath.com/track-record — the verify button runs the recomputation client-side, so you're not trusting our word for the result.

Happy to dig into the canonicalization edge cases in the comments.

DEV Community: EzathDEV

How we made our trading-signal track record tamper-evident with a SHA-256 hash chain

The threat model

The hash chain

Making it externally checkable

What it does and doesn't prove