How Event Ledger creates permanent, signed records
The Event Ledger accepts any structured business event and returns a permanent, cryptographically signed, independently verifiable record. From a single API call to permanent proof.
What you send
Every event is a JSON payload with four required fields: the event type, the actor (who triggered it), a human-readable description, and arbitrary metadata that your business cares about.
{
"event_type": "payment.completed",
"actor": "user_8kx92mf",
"description": "Invoice #4021 payment confirmed",
"metadata": {
"invoice_id": "inv_4021",
"amount_cents": 245000,
"currency": "USD",
"method": "wire_transfer"
}
}A dot-notation string identifying the event category. Examples: payment.completed, order.shipped, user.deleted, contract.signed.
The identifier (user ID, system name, or role) that triggered the event. Proves who performed the action.
A human-readable explanation of what happened. Used when presenting the event to auditors, customers, or regulators.
Arbitrary JSON. Include whatever context your business needs: order IDs, amounts, timestamps, references, or custom fields.
What happens on ingestion
When Invoance receives your event, a deterministic 5-step cryptographic flow begins. Each step is atomic and irreversible.
The event payload is received and an ingestion timestamp is recorded in UTC with nanosecond precision. This timestamp marks when Invoance accepted the event.
A SHA-256 hash is computed over the canonical JSON representation of the event payload. The hash binds the proof to the exact content submitted.
The hash (combined with timestamp and event metadata) is signed using your organization's Ed25519 private key, held securely by Invoance. The signature proves the record came from you.
The complete record (payload, hash, signature, timestamp) is written to Postgres with an INSERT-only constraint. No UPDATE, no DELETE, no override possible at the database level.
A verification URL is generated and returned to you. This URL allows anyone to retrieve and independently verify the event without authentication.
What you receive
After the 5-step flow completes, Invoance returns a response containing the event ID, all hashes, the signature, and a public verification URL.
{
"id": "evt_a1b2c3d4",
"event_type": "payment.completed",
"actor": "user_8kx92mf",
"sha256": "e3b0c44298fc1c149afbf4c8996fb924...",
"signature": "d4f5e6a7b8c9d0e1f2a3b4c5d6e7f8...",
"timestamp": "2025-03-15T14:32:07.123456Z",
"verification_url": "https://www.invoance.com/proof/event/evt_a1b2c3d4",
"status": "anchored"
}Unique identifier for this event (evt_...). Use this to retrieve the event later.
The event type you submitted, returned for confirmation.
The actor you submitted, confirming who triggered the event.
The SHA-256 hash of your original payload. Any change to the payload invalidates this hash.
The Ed25519 signature, verifiable against your organization's public key.
UTC timestamp at nanosecond precision, recorded at ingestion and embedded in the signature.
Public URL where anyone can retrieve and verify this event without authentication.
Current state of the event (anchored, archived, etc.). Anchored events are immutable.
How verification works
Verification is deterministic and requires no trust in Invoance. Anyone with the event data and your organization's public key can independently verify that the record is authentic and unchanged.
Fetch the event via public verification URL or API. This returns the payload, hashes, timestamp, and signature.
Hash the original event payload using SHA-256. If the result matches the returned hash, the payload is unchanged.
Use the Ed25519 signature and your organization's public key to verify the signature. A valid signature proves the record came from you.
The timestamp is part of the signed payload. If the signature is valid, the timestamp cannot have been backdated or adjusted.
Technical guarantees
These guarantees are structural properties of the Event Ledger, enforced by cryptography and database design. They hold for every organization, every event, regardless of plan or usage.
No admin, API endpoint, or override can modify a record. The database enforces this at the structural level, events can only be added, never updated or deleted.
Any change to the original payload, no matter how small, produces a completely different SHA-256 hash, instantly invalidating the proof.
The Ed25519 signature cryptographically binds the record to your organization's private key. You cannot deny that your organization signed the record.
The timestamp is recorded at the moment of ingestion and included in the signed payload. It cannot be backdated, adjusted, or overwritten.
Any party can verify the record offline using only the public key and Ed25519 signature. No Invoance server required. No network call necessary.
The database constraint is not a policy or application rule. It is a structural property enforced by Postgres. No override exists.
Compliance mapping
Event Ledger's technical controls align with major compliance frameworks. Your auditor maps these controls to your specific compliance context.
Integrity controls (hash verification), monitoring (append-only logs), review procedures (independent verification URLs).
Integrity and authentication mechanisms for PHI, audit controls and accountability for data access and modification.
Event logging (every event is timestamped and signed), records of information processing (compliance and audit trails).
Integrity and confidentiality of personal data, records of processing activities (Event Ledger as proof of processing).
Invoance provides the technical control. Your auditor or compliance officer maps it to your specific audit scope and regulatory context.
Ready to anchor your events?
Start with one event. Scale from there. The same cryptographic guarantees apply whether you're anchoring 10 events a month or 10 million.
How Event Ledger Works, Invoance
Technical walkthrough of how Invoance Event Ledger creates permanent, cryptographically signed records for business events using SHA-256 hashing, Ed25519 signing, and append-only storage. Every event is immutable, timestamped, and independently verifiable.