
Event Seal
Fail-closed verification for onchain events before relayers, agents, or backends act.
Demo
About
Solana programs can emit convincing logs even when the surrounding transaction fails. A backend that trusts a webhook or decoded log too early can release a reward, grant access, or update a ledger for state that never committed. EventSeal gives relayers, indexers, agents, and application backends a fail-closed checkpoint before they act. A developer submits a transaction signature and network, then separately supplies the expected program ID and Anchor event discriminator from a trusted source. EventSeal fetches finalized transaction evidence, confirms execution succeeded, reconstructs the active program invocation frames, and checks that the event came from the intended program. Missing or ambiguous evidence is never presented as success. The live demo makes the failure visible using two Solana devnet transactions that emit the same event shape. The successful transaction verifies and receives a deterministic public receipt. The failed transaction returns TX_FAILED and receives no receipt. Duplicate deliveries of the same verified event resolve to the same receipt identity, giving downstream systems a stable basis for idempotent processing. Continuity disclosure: EventSeal’s core SDK, hosted verifier, and Anchor devnet demonstration existed before ETHOnline 2026. Work completed during the event window includes stronger receipt-identity integrity, public receipt pages, an authenticated saved-receipt dashboard, hardened browser-to-function authentication, automated release tests, a public product homepage, developer documentation, and a redesigned verification workflow. The public Git history separates this work from the pre-event foundation.
How it's made
EventSeal is a TypeScript monorepo containing a verification SDK, Next.js web application, InsForge edge functions, PostgreSQL receipt storage, and an Anchor program written in Rust for adversarial testing. The core @eventseal/sdk reads Solana JSON-RPC using finalized commitment. It requires complete transaction metadata and meta.err === null, reconstructs nested program invocation frames, matches the expected eight-byte Anchor discriminator, and attributes the event to the expected active program. It returns an explicit verified, rejected, or indeterminate result. Missing, malformed, truncated, or unavailable evidence fails closed. The browser first calls POST /api/inspect using only the signature and network. Inspection reports transaction facts and untrusted event candidates, but cannot authorize an event or create a receipt. Verification begins only after the caller independently provides the trusted program ID and discriminator through POST /api/verify. The Next.js server attaches the internal function credential, keeping backend credentials out of the browser. Verified results are stored as immutable v2 receipts in PostgreSQL. Each receipt ID binds the network, finalized commitment, signature, trusted program, discriminator, event position, emitter, and event-data hash. Row-level security keeps writes server-only while permitting public evidence lookup. The Anchor devnet program exposes emit_success and emit_then_fail. Both emit the same event bytes, but the second deliberately aborts. This matched pair proves EventSeal’s central claim: observing the expected log is insufficient; the complete transaction must have succeeded.