LTIsland InsightLTIsland Insight

Signal Attestation Ledger

After each trading day's close, every signal generated that day (including signals never adopted) is first published as a zero-plaintext "commitment" using SHA-256 + a random nonce — anyone can see how many signals occurred that day, but not which instruments they refer to. Only once the tracking window has fully elapsed (the signal can no longer be an open position) is the plaintext disclosed for independent recomputation. Both the commitment and disclosure data live in full in the public repo ltisland-ledger.

An honest note on the "date" column below: this date is recorded locally at the moment the commitment is generated, and a local clock can be adjusted at will — the date itself proves nothing. The actual independently-checkable time anchor is the moment GitHub's servers actually received that push — anyone can independently confirm this from the commit history of the public repo above, with no need to trust our word. Some commitment records additionally carry a third-party RFC3161 timestamp token (issued by DigiCert or Sectigo, independently verifiable with the standard openssl tool, requiring no trust in any software we provide); if that request failed at the time, it is honestly marked as missing rather than faked.

How to verify it yourself, without trusting us

Method 1: run our verification script

Pure Python standard library, no dependency on any private system — clone the repo and run directly:

git clone https://github.com/lt17850984-prog/ltisland-ledger.git
cd ltisland-ledger
python3 verify.py 2026-07-13

This recomputes the Merkle root of all signals for that day, compares it against the published merkle_root field, and — where disclosure data exists — recomputes each signal's hash to confirm nothing was altered after the fact.

Method 2: compute it by hand, without trusting our script

  1. Open ingest/commits/<date>.json and take the hashes array (a sorted SHA-256 list) and the merkle_root.
  2. Rebuild it per the standard binary Merkle tree rule: pair up hashes and compute SHA256(left hash text + right hash text), duplicating the last item when the count is odd, working up one layer at a time until a single value remains.
  3. Compare the resulting value against merkle_root.
  4. If ingest/reveals/<date>.json exists for that date: for each disclosed record, take the seven fields {code, type, layer, direction, signal_time, signal_close, nonce}, assemble them into compact JSON in alphabetical key order (no extra whitespace), compute the SHA-256, and confirm it equals that record's hash field — and that this hash appears in that day's commit file's hashes list.

Only when both conditions hold does the "disclosed content" match the "originally committed content" exactly, with nothing swapped or backfilled after the fact.