What Is an Audited Trade Log?
An audited trade log is one where entries can only ever be added, never edited or removed, and where any reader can verify that for themselves without trusting the operator. Most trading journals fail this on the first clause and all of them on the second.
Ordinary journals are the wrong shape
A normal trading journal — a spreadsheet, a notes app, most commercial journal software — is a mutable document. Rows can be corrected, reclassified, or deleted, and that is a feature: you want to fix a typo in a fill price.
The trouble is that a document which can be corrected can also be curated, and from the outside the two are indistinguishable. Any journal used as evidence has to give up editing, and most never do, because they were designed as personal tools rather than as evidence.
What "audited" should mean
Not "an accountant looked at it". In this context it means the log has structural properties that make certain changes impossible to hide:
- Append-only. New entries are added; existing ones are never rewritten. A correction is a new entry that supersedes an old one, and both remain visible.
- Tamper-evident. Any modification to history is detectable, not merely prohibited by policy.
- Externally anchored. The evidence of integrity lives somewhere the log's operator cannot rewrite.
- Independently verifiable. A reader can perform the check themselves.
The last two are what separate a real audit trail from a database with an is_deleted
column. If the operator can rewrite both the data and the audit trail, the audit trail is decoration.
How the hash chain works
Each entry is hashed — a fixed-length fingerprint that changes completely if any byte of the input changes. Hashes are combined pairwise up a tree until one root hash remains. That root is written to an external ledger, in kappi's case Hedera.
To check the log, a reader recomputes the tree from the published entries and compares the root against the anchored value. If they match, the entries are exactly what they were when the root was written. If a single character changed, the roots differ.
Crucially this also catches insertion. A trade quietly added later, backdated to look contemporaneous, changes the tree and fails the check — which is what makes the log complete rather than merely unedited. Completeness is the property that matters, since selective omission is the common failure, not forgery.
Why external anchoring is the load-bearing part
A hash chain stored entirely inside the same system it protects proves very little: whoever can rewrite the entries can recompute the chain. The chain only becomes evidence when its root is published somewhere the operator cannot alter and cannot backdate.
This is the part to interrogate in any "blockchain-verified" trading claim. Ask where the root is written, how often, and whether you can fetch it yourself. If the answer is that the platform stores it internally, the property being claimed does not exist.
What it still cannot do
An audited log proves the record's integrity, not the truthfulness of what was entered. If a trader commits a trade they never placed with a broker, the log faithfully records a claim that was made before the fact — which is exactly what it says it does, and which is genuinely useful, but it is not execution verification.
Nor does the log itself stop someone running several accounts and publicising the best. What raises the cost of that is the name on the record rather than the cryptography — records are shared as an @name, and the recommended one is the handle you already answer to in public, which is not something anyone holds a hundred of. Why a public identity does not fork covers it. The log's own guarantee is per-record completeness: real and unusual, and worth stating precisely rather than overselling.
Broker-import journals prove what you did after the fact, from data you control. kappi timestamps what you said you would do, before you knew how it would turn out, on a record you cannot edit.
Where does this construction come from?
Not from cryptocurrency. Haber and Stornetta described hash-linked document timestamping in the Journal of Cryptology in 1991, specifically to make a date unforgeable by the party issuing it[1], and the IETF standardised a signed-hash timestamp protocol in 2001 as RFC 3161.[2] An append-only trade log is a direct application of work that predates the entire blockchain industry by nearly two decades — which is worth knowing when a platform presents hash anchoring as novel.
kappi is a trade recorder: you commit a trade before the fact, it is sealed on your device for a time-capsuled delay you choose, and published afterwards on a Merkle-anchored log a reader can check without kappi's cooperation. $15/month, no free tier.
Sources
Frequently asked questions
What makes a trade log 'append-only'?
Entries can only be added, never rewritten or removed. A correction becomes a new entry that supersedes the old one, and both stay visible in the history.
How does hash anchoring prove nothing was changed?
Entries are hashed into a tree and the root hash is published externally. Any edit, insertion or deletion changes the root, and the earlier root is already public, so the change is detectable.
Why does the anchor need to be external?
A hash chain stored in the same system it protects offers no guarantee, because whoever can alter the data can recompute the chain. It only becomes evidence when the root is published where the operator cannot rewrite it.
Does an audited log prove the trades were really executed?
No. It proves the record is complete and unaltered since it was committed. Execution at a broker is a separate question that an audit trail does not address.