Build on verifiedSolana events.

Inspect a transaction. Verify the event you expect.
Decide from the evidence.

Start with the repository.

The SDK builds inside this workspace. Start here for local development.

Terminal
git clone https://github.com/abhigyan1102/event-seal.git
cd event-seal
npm install
npm run dev

# open http://localhost:3000

Inspect the transaction.

Start with a signature and network to discover the available evidence. Candidate program IDs and event bytes remain untrusted.

POST /api/inspect

TypeScript · SDK
import { inspectTransaction } from "@eventseal/sdk";

const inspection = await inspectTransaction({
  signature,
  cluster: "devnet",
});

if (inspection.reasonCode === "CANDIDATES_FOUND") {
  // Confirm identity from your trusted source.
}

No verdict. No receipt. Inspection does not verify event identity or persist evidence.

Verify your expected event.

Supply the program ID and event discriminator from your trusted IDL or deployment configuration. Never take these values from inspection candidates.

POST /api/verify

TypeScript · SDK
import { verifyEvent } from "@eventseal/sdk";

const result = await verifyEvent({
  signature,
  cluster: "devnet",
  expectedProgramId,
  event: {
    format: "anchor-log",
    discriminator: expectedDiscriminator,
  },
  commitment: "finalized",
});

Trusted identity goes in. The expected discriminator must be eight bytes, encoded as 16 lowercase hexadecimal characters.

Decide from the verdict.

Only verified evidence passes the event checks. Your application still decides whether an action is authorized and whether it has already been processed.

TypeScript · Application policy
switch (result.verdict) {
  case "verified":
    // Your application checks authorization and replay
    // protection before performing any protected action.
    break;
  case "rejected":
  case "indeterminate":
    return;
}

Missing evidence never passes. Rejected and indeterminate results must not trigger a protected action.

Example outcome

Verified VERIFIED

The expected event matches.

Finality, execution, program attribution, and event identity passed. Apply your application's authorization and business rules.

Know what the result means.

Three boundaries to keep explicit in your integration.

Verified means the requested identity passed. Rejected means available evidence disproved it. Indeterminate means the evidence was not strong enough.

"verified" | "rejected" | "indeterminate"

Treat indeterminate as a stop, not as a tentative success.

Verify the evidence. Keep your own trust boundary.

Keep the evidence
close at hand.

Use the verifier, then apply your own authorization and business rules.

Open verifier