Invoance

Loading…

Your logs can be edited. Your ledger cannot.

The Event Ledger is an append-only, cryptographically signed record of business events. Every entry is hashed, signed with Ed25519, and permanently written. No modifications. No deletions. No exceptions.

Free up to 10,000 events · Paid plans from $49/month · No setup fees

What the Event Ledger is

A single POST to /v1/events creates a permanent, tamper-evident record. The ledger does not replace your operational logging — it runs alongside it as the audit layer your systems were never designed to be.

Append-only

Enforced at the database level via immutability triggers. UPDATE and DELETE are structurally impossible — not just disallowed by policy.

Cryptographically signed

Every entry is signed with Ed25519 using a tenant-bound key. The signature is verifiable by any third party without contacting Invoance.

Content-hashed

SHA-256 is applied to the canonical event payload before signing. Any alteration to the content produces a different hash — silently impossible.

Timestamp integrity

Timestamps are recorded at ingestion and are part of the signed payload. They cannot be backdated, adjusted, or overwritten.

Independently verifiable

Public verification endpoints require no API key. Anyone — an auditor, a regulator, a counterparty — can verify any record without your involvement.

What your current logs cannot prove

Operational logging tools are built for debugging and observability. They were never designed for legal proceedings — and that gap shows when regulators, auditors, or courts ask for proof that records have not been altered.

SOX Section 404
Missing: Immutability

An administrator with database access can alter or delete log entries. There is no technical control preventing it.

GDPR Article 5(1)(f)
Missing: Integrity proof

There is no independent mechanism to verify that records have not been altered after the fact.

FRE 902(14)
Missing: Third-party verification

Records produced from vendor-controlled systems require the vendor's testimony to establish authenticity.

Operational logging vs. event ledger

These are not competing tools. Operational logs are for engineers. The Event Ledger is for auditors, regulators, and legal proceedings. They serve different masters.

Operational logs
Invoance Event Ledger
Immutability
No — admin can edit
Yes — enforced at DB level
Cryptographic proof
No
Yes — Ed25519 per event
Independent verification
No — vendor-controlled
Yes — public key, no auth required
Timestamp integrity
Adjustable
Signed at ingestion
Designed for audits
No — built for debugging
Yes — built for legal defensibility
FRE 902(14)
Manual attestation required
Structurally compliant
When you need it
Regulatory audit

SEC, FCA, or OCC requests two years of transaction records.

Weeks reconstructing context from mutable logs. Admissibility challenged.
Cryptographic proof bundle produced in minutes. Chain of custody intact.
Legal dispute

Counterparty claims a record was altered after the fact.

You have logs. They have lawyers. Logs are not evidence.
Ed25519 signature proves the record has not changed since anchoring.
Security investigation

Breach requires proof of who accessed what and when.

Logs may have been tampered with. Forensic value is contested.
Append-only chain of events. Every access anchored. Nothing editable.
Compliance certification

SOC 2, ISO 27001, or HIPAA requires audit trail integrity.

Custom audit infrastructure. Months of engineering. Recurring cost.
Single API integration. Audit trail included. Certifiable immediately.
Who uses it
Compliance officersNeed audit-grade records that survive regulatory scrutiny without relying on engineering to reconstruct context.
Security teamsNeed forensic-quality event records for breach investigation, insider threat analysis, and access audits.
Legal teamsNeed records that satisfy FRE 902(14) and do not require vendor testimony to establish authenticity.
Engineering teamsNeed to satisfy audit requirements without rebuilding core infrastructure or adding mutable audit tables.
Fintech and regulated SaaSNeed immutable records of financial events, approvals, and policy decisions as a baseline regulatory requirement.
One endpoint. No workflow changes.

The Event Ledger runs in parallel to your existing systems. You do not reroute existing logs. You do not change approval workflows. You POST events you want anchored. Everything else continues unchanged.

POST/v1/events
{
  "event_type":      "payment.approved",
  "event_time":      "2026-02-25T14:22:01Z",
  "payload": {
    "payment_id":    "pay_9f3a",
    "amount":        14200,
    "approved_by":   "user_7b1c",
    "decision":      "approved"
  },
}

// Response
{
  "event_id":    "evt_4c8d2f",
  "hash":        "9f3a...c21e",
  "signature":   "ed25519:7b1c...a4f9",
  "anchored_at": "2026-02-25T14:22:01Z",
  "verify_url":  "https://invoance.com/verify/evt_4c8d2f"
}

That verify_url is publicly accessible — no auth required. Send it to your auditor. Paste it in a legal filing. It resolves to a cryptographic proof, not a marketing page.

The Event Ledger uses the same cryptographic primitives as Invoance document verification — SHA-256, Ed25519, and append-only Postgres — extended for activity events, access logs, and business operations.