Besë Asset Management

Verify

How to check this record

Everything below can be done by a stranger with a copy of the data directory and no cooperation from us.

Why it matters here

A track record quoting a broker's equity endpoint is attested by the broker whether or not you trust the arithmetic. Besë's NAV is constructed from fills, so the chain and the open calculation are not a nice extra — they are the whole of the evidence. That is why the metric code is public.

1. Self-hashing

Each record commits to its own content.

Every file in snapshots/ carries a hash: the SHA-256 of the record's canonical JSON with the hash field removed. Change any published number and this fails.

import hashlib, json, pathlib

def canonical(payload):
    return json.dumps(payload, sort_keys=True, indent=2,
                      ensure_ascii=False, allow_nan=False,
                      default=str) + "\n"

rec  = json.loads(pathlib.Path("books/bese_nominal_100k/snapshots/2026-08-14.json")
                  .read_text(encoding="utf-8"))
body = {k: v for k, v in rec.items() if k != "hash"}
assert hashlib.sha256(canonical(body).encode()).hexdigest() == rec["hash"]

2. Chaining

No session can be silently dropped, or invented.

Each snapshot's prev_hash is the hash of the previous session; the first is 64 zeroes. A timestamp proves a file existed; only the chain proves the series is complete — so a losing day cannot be quietly removed later without breaking every record after it.

Verification walks the snapshot directory rather than trusting CHAIN.jsonl to list its own contents, and each snapshot's filename must match the session date inside it, which must in turn follow the one before. Together these mean a session cannot be removed, reordered or invented: not the most recent ones, which is where a bad run would sit, and not an older one dropped in under a chosen date.

From the project root: python3 -m bese.verify

3. Coverage

Every published file is covered, not just the snapshots.

A hash chain over the session records protects the session records. It does not, by itself, protect nav.csv, trades.csv, the metric files, the archive manifest or the corrections file — and those are what a reader actually reads. So each snapshot also pins their SHA-256 digests, and meta.json is pinned too, excluding the two fields derived from the chain itself.

So altering a figure in nav.csv, or removing rows from trades.csv, fails verification. The same command also checks that the copy served by this website is byte-identical to the copy in the repository.

4. Recomputation

The numbers follow from the inputs.

nav.csv is the whole equity curve. Every published metric is computed from it by bese.metrics.compute_core_metrics, which is published in this repository. Recompute and compare.

import csv
nav = list(csv.DictReader(open("books/bese_nominal_100k/nav.csv")))
print(float(nav[-1]["equity"]) / float(nav[0]["equity"]) - 1)

5. Dating

The records were not back-dated.

Each snapshot carries an OpenTimestamps proof beside it, anchoring its hash into a Bitcoin block.

pip install opentimestamps-client
ots info   books/bese_nominal_100k/snapshots/2026-08-14.json.ots      # read the proof, offline
ots verify books/bese_nominal_100k/snapshots/2026-08-14.json.ots      # check it against Bitcoin

A fresh proof commits to a calendar server and is incomplete until the aggregating Bitcoin transaction confirms, normally within a few hours. ots upgrade completes it; the publisher does this on every run. Incomplete means “not yet confirmed”, not “invalid”.

ots verify checks the proof against the block chain itself, so it needs a Bitcoin Core node (a pruned one is fine, and it costs nothing but a one-off sync). That is the design working as intended rather than an obstacle: the whole point is that checking this record asks you to trust no third party. If you would rather not run one, ots info reads the proof offline, and the verifier at opentimestamps.org will check it in your browser — at the cost of trusting that site and its block explorers.

What a timestamp proves is narrow and worth stating exactly: the file existed at or before that block. It does not prove the file did not exist earlier — which is the right way round, because the claim being defended is that a session's record was fixed on the day and not rewritten afterwards to suit what happened next. The chain stops deletion, the timestamp stops back-dating, and neither is sufficient alone.

The trades themselves are timestamped by someone else. Every entry and exit instant was written by the exchange and the firm, to the millisecond, in UTC. That is third-party attestation of when a trade happened, and nothing here improves on it.

6. The exports

Fixed in time, without being published.

The NAV is constructed from raw broker and firm exports, so those files are load-bearing evidence — but the firm's completed-trade export carries its account identifier, and a track record is a document strangers are invited to read closely, so the raw files are not published. archive_manifest.json is the compromise: it records the SHA-256 of every raw export the published record was built from. The files stay private, and if the record is ever challenged any one of them can be produced and shown to be the file held on the day. A hash costs nothing and forecloses “you edited the source”.

The chain

6 records. Head 62436b6e0e00bbd59c28…
SessionHashPreviousBytes on disk
2026-08-04a77eee990666d34c…0000000000000000…fc44b35125f478d1…
2026-08-070d7321e9acc9aea4…a77eee990666d34c…b7cd0aaadcb390ae…
2026-08-104dceca3d1a4c5ac6…0d7321e9acc9aea4…ca4aae3ecc84883a…
2026-08-1199d9faedf1dc61ae…4dceca3d1a4c5ac6…d0ac863da5584091…
2026-08-13abb7ef995a9bad58…99d9faedf1dc61ae…71c4b2e8d274883d…
2026-08-1462436b6e0e00bbd5…abb7ef995a9bad58…ee974ac07afeb927…

What it proves

And what it does not.

It proves no published number has been edited after the fact; no session has been quietly dropped; the metrics follow from the equity curve by open code; and the equity curve follows from archived broker records by open code.

It does not prove the trading was skilful, that the same strategy would survive a different market, or that no other unpublished account exists. Git history can be rewritten by whoever controls the repository — which is why the hash chain is used alongside branch protection and external timestamps rather than instead of them. Whether those two are in force is stated above rather than assumed here.

Where the data is

Public, and open to challenge.

Everything above — the record, the site that renders it, and the code that computes every number — is in bese-am/track-record. It is public. The main branch is protected against force-push and deletion, so the append-only history cannot be rewritten without leaving a trace.

Publication runs on the trading machine itself. GitHub Actions is not involved in producing this data and holds no broker credential.

Found something wrong? If a check fails, a number does not reconcile, or something here is unclear, please say so. Open an issue and tag @kkacajj. A track record nobody can question is not one worth publishing.

Nominal capital, not assets under management. $100,000 is a stated normalisation base. It is not client money, and no prop firm's advertised account size is treated as capital under management.

Past performance is not indicative of future results. Nothing here is investment advice, an offer, or a solicitation. Futures trading carries substantial risk of loss. See disclosures.

Published 16 August 2026, 00:53 UTC · every figure computed by bese.metrics, not by the browser.