Audit Trail

Immutable and append-only

Aegis keeps an immutable audit trail. Records are append-only — operational events are added, never edited or deleted in place. That means the history you read is the history that happened; there is no way to quietly rewrite the past.

This mirrors how Aegis handles balances: a double-entry ledger where balances are derived from immutable sums rather than mutable running totals. The audit trail applies the same principle to operational events.

Exactly-once via the transactional outbox

The hard part of any audit log is making sure an event is recorded exactly once — never dropped when something fails, never duplicated on a retry. Aegis solves this with a transactional outbox:

1. The business change and its audit event are written in the same database transaction. Either both commit or neither does.
2. A relay reads committed outbox rows and publishes them onward.
3. Delivery is idempotent, so a retry re-uses the same event rather than creating a second one.

Because the event shares the transaction with the change it describes, you can never have an action without its audit record — or an audit record for an action that rolled back.

What gets recorded

Operational events across the platform are captured, including security-sensitive ones such as connecting or revoking an exchange key, changing the primary wallet, and enabling automation — the same actions gated by step-up signatures.

Why it matters

• Accountability — every operational change is attributable and time-ordered.
• Inspectability — the trail can be reviewed after the fact to reconstruct exactly what happened.
• Integrity — append-only storage plus exactly-once delivery means the record is trustworthy, not best-effort.

The audit trail complements the encryption and isolation controls in API key encryption: those keep data safe, while the audit trail keeps an honest account of everything done with it.