01
Chained history
The event stores the hash of the record before it, so every accepted fact holds its place in a tamper-evident chain.
previous_event_hash: 8c1f…22e0EVENT / 01APPEND-ONLY EVENT INFRASTRUCTURE
The events someone will dispute should not live in a log you can edit.
Payments, consent, approvals, and handoffs get challenged by customers, auditors, and partners. The Event Ledger records each one the moment it happens, hash-linked to the record before it, timestamped, and signed with Ed25519, so the record can defend itself.
Your application stays the system of action. The Event Ledger keeps the signed, ordered history beside it, with nothing to migrate and no pipeline to rewrite.
Hash-chained event history Append-only event rows Offline signature verification
app.invoance.com/ledger
Event LedgerLive · Append-only
PrevEventHashSignatureTime
0010ba…dfb5ba00454f…Signed09:14:22
inventory.adjusted
SKU BR-2214 count corrected to 412
b9c940…0010ba00f864…Signed09:14:05
payout.completed
Weekly payout batch settled
55cff6…b9c94000148b…Signed09:13:41
refund.issued
Refund of $96.50 approved on ord_66c1
9c0f9e…55cff6009154…Signed09:13:12
deploy.pushed
api v2.31.0 deployed to production
5ed724…9c0f9e00aaa5…Signed09:12:58
contract.signed
MSA countersigned by Meridian Ltd
Rows are added, never rewritten. Each carries its own Ed25519 signature, verifiable offline.
CHAINED TO 8c1f…22e0
PAYLOAD HASH 9f21…d40a
SIGNATURE VALID
01CanonicalizeNormalize the event payload deterministically
02ChainLink the event to the hash of the record before it
03SignReturn the timestamped Ed25519 receipt
02WHY APPLICATION LOGS FAIL
Mutable logs can tell a story. They cannot prove the history stayed intact.
An ordinary log can be updated, deleted, backfilled, or exported without any cryptographic evidence of what changed. That weakness appears precisely when the event matters outside your engineering team.
“I never approved that payment.”
Your application log says they did. Because your team controls that log, the customer, card network, or court still has to take your word for it.
CRITICAL EVENTpayment.approved
Customer cust_482 approved invoice INV-2841 at 14:32 UTC.
Share a signed receipt instead of assembling screenshots and exports.
03THE DIFFERENCE
Application logs explain what happened. The Event Ledger proves the record stayed intact.
The Event Ledger does not replace your logs, your warehouse, or anything else you run. It preserves the small set of business facts whose integrity may matter outside your team.
ORDINARY APPLICATION LOG
INVOANCE EVENT LEDGER
Who controls the history?
The same team being asked to prove it
The issuer creates it; cryptography exposes later changes
Can a record be rewritten?
Anyone with enough access, leaving no trace
Append-only storage blocks updates and deletes
Can an outsider verify it?
Only by trusting your export
Yes, through a proof link or offline SDK
Does it replace your logs?
Logs are all you have when challenged
No. It runs beside them for the events that matter
04ANATOMY OF A LEDGER EVENT
Every event leaves with its own verification material.
The Event Ledger adds an ordered position, deterministic payload fingerprint, and issuer signature to the business event your application already produced.
02
Payload fingerprint
The canonical event payload is hashed with SHA-256. Change one field later and the fingerprint no longer matches.
payload_hash: 9f21…d40a03
Issuer signature
The payload hash, event identity, and ingestion time are signed with the issuer's Ed25519 key and returned with the record.
signature: ed25519:5d39…ae0805WRITE FROM YOUR EXISTING STACK
One event write. No log-pipeline rewrite.
Call the Event Ledger after the critical action succeeds in your application. Store the returned event ID and ingestion time beside the record you already own.
Nine integration options Eight SDKs plus raw HTTP.
Idempotent event writes Safe retries do not create duplicate ledger entries.
Selective ingestion Write critical business events, not every debug line.
CREATE SIGNED EVENT
POST /v1/eventsfrom invoance import InvoanceClient
client = InvoanceClient()
event = await client.events.ingest(
event_type="order.shipped",
payload={"order_id": "ord_8f2a", "carrier": "fedex"},
)
print(event.event_id, event.ingested_at)06WHAT BELONGS IN THE LEDGER
Write the events whose history must survive a challenge.
You do not need to sign every debug line. Anchor the facts a customer, partner, reviewer, or regulator may ask you to prove later.
MONEY
Payments, refunds, and approvals
payment.approved · refund.issued · payout.completedCONSENT
Terms, permissions, and decisions
terms.accepted · consent.granted · access.changedOPERATIONS
Orders, deliveries, and handoffs
order.shipped · delivery.confirmed · custody.transferredSYSTEM
Deployments and configuration
release.deployed · key.rotated · feature.enabled07THE OPERATIONAL RESULT
When history is questioned, the event already carries its proof.
Resolve disputes faster
Move the conversation from competing screenshots to one independently verifiable record.
Less manual evidence workAnswer reviews with confidence
Give security, compliance, and legal teams evidence that does not depend on dashboard access.
Portable audit evidenceProtect critical handoffs
Preserve approvals, custody transfers, and operational milestones when two parties may disagree later.
Clear chain of eventsMake trust visible
Put proof links in your product so customers can check important events without opening a support ticket.
Trust built into UX08EVENT LEDGER QUESTIONS
Add the ledger without rebuilding the application.
Does this replace our logs?
No. Keep your logs for operations and debugging. Send only the business events whose integrity needs to survive outside your own systems.
Do verifiers need an Invoance account?
No. A proof link can be checked publicly, and supported SDKs can verify exported records offline.
What if the event is sensitive?
You decide which payload fields to send. The public proof surface exposes verification material, not your private application context.
Can someone alter the history later?
The ledger is append-only. A changed payload no longer matches its SHA-256 hash or Ed25519 signature.
READYWRITE THE FIRST EVENT
Put one critical business event in the ledger today.
Start with a payment, consent change, approval, or handoff. Keep your existing system and add a signed, append-only record beside it.