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.

The change log page showing a table of entries with when, category, action, actor, target and notes columns

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.
The category filter row with All, LEDGER, SETTINGS, RBAC, EXPORT, IMPORT, DOCUMENT and SIGNATURE options

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. Every time you open the change log we recompute the chain from the stored records and show you the result at the top of the page — the number of entries checked, or the exact entry where the chain stopped matching. Because the check reads the raw records rather than what the app believes about them, a change made directly in the database, outside the app, is caught the same way. That’s what we mean by tamper-evident: the goal isn’t to make tampering impossible, it’s to make it impossible to hide.

Where a change has recorded values — a corrected name, a fixed email — the fingerprint covers those too, so the What changed column is evidence rather than a note. Rewriting what a record says it used to be breaks the chain exactly the way deleting the record would.

It also runs nightly across every company, whether or not anyone opened the page — because a trail nobody is watching is the one worth altering. If a chain stops verifying, the people running Tenacap are paged that night rather than finding out whenever someone next happens to look.

One honest limit. The check covers the fields that go into each entry’s fingerprint — when it happened, who did it, what it was, what it touched, and the values it moved — but not the free-text note beside it.

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.

The Download CSV button in the change log header

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.