Why capture the envelope hash at enqueue time rather than at send time?

Capturing the hash at enqueue time decouples the proof from delivery timing and retries. If a delivery attempt fails and is retried later, the retried notification carries the identical envelope hash captured when the notification was first queued - proving every attempt, regardless of how many retries occurred or how much time elapsed, attests to the same specific ledger-chain version of the event, rather than a value that could silently drift if re-derived at each send attempt.

How is this different from just signing the webhook payload?

Signing proves the payload was produced by the claimed sender and has not been altered in transit. It does not, on its own, tie the payload to a pre-existing, independently maintained hash chain that exists for a separate purpose - the event ledger's own tamper-evident record. Embedding the ledger's envelope hash inside the webhook payload lets a recipient - or a later auditor with access to the ledger - confirm the notification corresponds to a specific, verifiable link in that chain, not merely that the bytes were unaltered in transit.

Ledger-Hash-Bound Webhook Notifications

Q: What problem does binding a webhook to a ledger hash solve?

Standard webhook systems can prove a notification came from the claimed sender (typically via HMAC signing of the wire transmission) but say nothing about whether the notification's content matches a specific, independently verifiable version of the underlying event as recorded in the system of record. If a dispute later arises over exactly what a party was told and when, an HMAC only proves provenance of the delivery - it does not prove ledger-fidelity of the content.

Executive Summary

JIL Sovereign's event ledger maintains a per-entity, sharded hash chain in which every recorded event is bound to an envelope hash derived from its position in that chain. When the platform notifies a subscriber that an event has occurred, the outbound webhook envelope embeds the exact same envelope hash already computed and stored as part of the ledger's own tamper-evident record - not a separately generated identifier, and not a value re-derived at send time.

That envelope hash is captured once, at the moment the notification is enqueued for delivery, and is preserved unchanged through every subsequent delivery attempt, including retries following a failed or delayed delivery. The result is a permanent, verifiable binding between "party X was notified" and "the exact hash-chained version of event Y that existed at enqueue time" - a binding that holds regardless of delivery timing, network failures, or how many retry attempts a given notification required.

Core Innovation: Surfacing the event ledger's own tamper-evident hash inside the outbound notification envelope, captured at enqueue time and held constant across retries, so a webhook delivery is not merely authenticated but cryptographically bound to a specific, independently verifiable link in a pre-existing hash chain.

Problem Statement

Webhook notification systems typically deliver a JSON payload describing "event X occurred" to a subscriber's endpoint, with the payload's authenticity protected by an HMAC signature over the wire transmission. That signature proves the payload came from the claimed sender and was not altered in transit - but it says nothing about whether the payload's content matches a specific, independently verifiable version of the underlying event as recorded in the system of record. If the underlying event record is later found to have been mutated, or if a dispute arises over precisely what version of an event a party was notified of, an HMAC over the wire transmission offers no way to tie the notification back to a specific point in an authoritative, tamper-evident history.

This gap matters most in regulated and evidentiary contexts - payer-provider disputes, appeal-timeline disputes, chain-of-custody questions - where "were you notified, and of precisely what version of the record" can be dispositive. A subscriber who received a webhook and later needs to prove what they were told, or a platform operator who needs to prove what was sent, both need more than "the bytes were unaltered in transit" - they need proof the notification corresponds to a specific, externally verifiable link in the event's own authoritative history.

Envelope hash, shared between the ledger record and the notification

Re-derivation of the hash across delivery retries

Independently checkable facts bound together: notified, and of exactly what

Why HMAC-Only Webhook Authentication Falls Short

Generic HMAC-signed webhooks (Stripe, Twilio, and most pub/sub systems): prove provenance and wire-transmission integrity, not ledger-fidelity of the reported event's content.
Payload-only audit logging: records that a notification was sent, but not a cryptographically verifiable tie to the specific chain-position of the underlying event.
Delivery-receipt tracking alone: confirms a subscriber's endpoint acknowledged receipt, but not what specific, tamper-evident version of the event the acknowledgment corresponds to.

Technical Architecture

From Ledger Write to Notification Envelope

Stage	Component	Function
1	Event ledger	Writes each event to a per-entity sharded hash chain, computing an envelope hash bound to the event's position in that chain
2	Notification enqueue	Captures the ledger's envelope hash for the triggering event at the moment the notification is queued for delivery to a subscriber
3	Outbound webhook envelope	Embeds the captured envelope hash, alongside event identifier and payload, in the notification sent to the subscriber
4	Delivery / retry	Resends the identical previously-captured envelope hash on every retry attempt, without re-deriving it

Enqueue-Time Capture, Not Send-Time Derivation

The envelope hash is fixed at the moment a notification is queued, independent of when - or how many times - it is actually delivered. This decoupling matters: if the hash were instead recomputed at each send attempt, a notification retried after an intervening ledger update could silently carry a different hash on a later attempt than on the first, without any indication to the subscriber that the underlying reference had shifted. By fixing the hash at enqueue time, every delivery attempt for a given notification - first attempt or fifth retry - carries proof of the same exact event version.

Verification Path

A subscriber who wishes to confirm a received notification's fidelity can, independent of the sending system, query the same event from the ledger (or, given the ledger's periodic public anchoring, verify against the anchored root) and confirm the envelope hash matches. This closes the loop between "you were told" and "here is cryptographic proof of exactly what you were told," without requiring the subscriber to trust the webhook sender's runtime behavior at delivery time.

Relationship to the Sharded Event Ledger

This mechanism deliberately narrows its novelty to one decision: surfacing a hash that the event ledger already computes and stores as part of its own per-entity sharded hash chain, inside the outbound webhook envelope. The hash-chain construction itself - durable write-before-chain-advance, per-entity sharding to avoid lock contention - is the ledger's own mechanism; this claim is specifically the binding of that pre-existing tamper-evident value into the notification subsystem, at enqueue time, held constant across retries.

Prior Art Differentiation

Approach	Proves Delivery Provenance?	Proves Ledger-Chain Fidelity?	Stable Across Retries?
Unsigned webhook payload	No	No	N/A
HMAC-signed webhook (Stripe/Twilio-style)	Yes	No - proves wire integrity, not ledger fidelity	Not addressed by the signature scheme
Delivery-receipt logging only	Partially - confirms endpoint response	No	N/A
JIL ledger-hash-bound webhook	Yes	Yes - same hash as the ledger's own chain	Yes - captured once at enqueue, unchanged on retry

Patent Claim

Independent Claim 151: A computer-implemented method for generating cryptographically-bound outbound event notifications comprising: maintaining a tamper-evident, hash-chained event ledger in which each recorded event is bound to an envelope hash derived from that event's chain position; upon enqueueing a notification for delivery to a subscriber, capturing the envelope hash of the underlying ledger event at enqueue time; embedding the captured envelope hash within the outbound notification payload delivered to the subscriber; and preserving the captured envelope hash unchanged across delivery retries, such that every delivery attempt for a given notification cryptographically attests to the identical, verifiable ledger-chain version of the underlying event regardless of delivery timing or retry count.