Change log & audit trail
Every change to your company — a share issued, a setting flipped, a teammate’s role changed, an export taken — is recorded as its own entry: who did it, when, and what it touched. The whole stream is hash-chained, so a single altered record breaks the chain and shows. This is the page you open when someone asks ‘who changed this, and when?’
A cap table is only as trustworthy as the record of how it got that way. Behind every figure on your cap table is a ledger of the events that produced it — and alongside that ledger sits the change log: a plain, human-readable trail of who changed what, when, and why. You don’t have to switch it on or configure anything. Tenacap has been writing entries since your first action; this page is where you read them.
Open the change log
From your cap table, open Change log in the header. It loads the company’s entries newest-first, 100 at a time, with Older and Newer controls to page through history.
Reading an entry
Each row answers the same six questions, so the table reads left to right like a sentence:
- When — the timestamp, shown in UTC so it’s unambiguous across time zones.
- Category — the kind of change (ledger, settings, access, and so on — see below).
- Action — what happened, for example a share issuance or a role change.
- Actor — the person who did it, resolved to their email address where we have it.
- Target — what the change touched, such as a transaction or a stakeholder.
- Notes — any reason recorded with the change. Corrections in particular always carry a reason.
Filtering by category
Above the table is a row of filters. Click any category to narrow the view to just those entries; click All to come back. The categories are:
- Ledger — cap-table transactions: shares issued, options exercised, SAFEs converted, rounds closed, reversals.
- Settings — changes to company settings.
- RBAC — access changes: who was added, removed, or had their role changed.
- Export — every time data was taken out, including open-schema exports and diligence packs.
- Import — data brought in, for example a cap-table import.
- Document — documents generated or attached.
- Signature — e-signature events on those documents.
Why it’s tamper-evident
Each entry is linked to the one before it by a cryptographic hash — a fingerprint computed from the entry’s contents plus the previous entry’s fingerprint. Chained this way, the entries form an unbroken sequence: change any single past entry and its fingerprint no longer matches, breaking the chain from that point onward. You can’t rewrite one line of history without leaving a visible gap.
This isn’t just a display trick. A scheduled integrity check recomputes the chain from the raw records and raises an alert on any mismatch — so even a change made directly in the database, outside the app, would be caught. That’s what we mean by tamper-evident: the goal isn’t to make tampering impossible, it’s to make it impossible to hide.
Exporting for diligence
Use Download CSV to take the current view out as a spreadsheet. The export respects whatever category filter you have on, and — importantly — it includes each entry’s chain hash, so an auditor or counsel can independently verify the trail rather than take it on faith.
When you’re assembling a data room, the change log also ships inside the diligence pack — the one-click zip that bundles your cap-table export, compliance reports, and an audit-log excerpt with a checksum manifest. See Export & open schema for the full picture, and Compliance & tax for what rides alongside it.
Who can see it
The change log is read-only and scoped to the company you’re in. Viewing it needs the Editor role or higher — a Viewer can see the cap table but not the full audit trail behind it. Nobody, at any role, can edit or delete an entry from the app: the record is append-only by design.