Verify signed trust decisions without Abraxas as your trust root

What the verifier checks

• Ed25519 receipt signature against your pinned ABRAXAS_RECEIPT_VERIFICATION_REGISTRY (offline).
• Partner and policy binding for the relying party scope you configure.
• Expiration and revocation signals — unsigned revocation hints are rejected.
• Authenticated portable revocation snapshots with monotonic checkpoint advancement.
• Optional single-use receipt consumption to block replay at your application boundary.
• Cross-application isolation — the same presentation must not authorize under another tenant's policy.

Trust material (versioned)

Loading verification contract…

Environment capabilities

Who this is for

• Institutional engineering teams operating their own authorization API (banks, exchanges, hospitality platforms, identity orchestrators).
• Security engineers who must pin issuer keys and digest v2 trust material independently of Abraxas hosted UI.
• Backend teams that need inspect-only cryptography separate from authorize-with-replay enforcement.

Package delivery (Build #587)

Package @abraxas/institutional-verification at version 0.1.0 ships as a controlled local tarball — not on public npm until founder approval.

# Inside abraxas-app (maintainers)
npm run pack:institutional-sdk
# → packages/abraxas-institutional-verification/abraxas-institutional-verification-0.1.0.tgz

# Your backend (third party)
npm install ./abraxas-institutional-verification-0.1.0.tgz

Node.js 20+. Runtime deps: tweetnacl only. Optional PostgreSQL adapter remains institution-implemented via ReceiptConsumptionStore.

Integration module

The tarball bundles production Build #546/#586 verification logic — no duplicate signature math and no @/ path aliases at runtime.

// Controlled release — install from founder-approved tarball (not public npm yet)
// npm install ./abraxas-institutional-verification-0.1.0.tgz

import {
  resolveInstitutionalTrustEnv,
  inspectSignedDecisionReceipt,
  verifySignedDecisionReceipt,
  RECEIPT_TRUST_DIGEST_VERSION,
} from "@abraxas/institutional-verification";
import { FileReceiptConsumptionStore } from "@abraxas/institutional-verification/consumption";

const trust = await resolveInstitutionalTrustEnv({
  receipt_verification_registry_json: process.env.ABRAXAS_RECEIPT_VERIFICATION_REGISTRY,
  pinned_receipt_key_document_digest: process.env.ABRAXAS_RECEIPT_KEY_DOCUMENT_DIGEST,
});
if (!trust.ok) throw new Error(trust.code);

// Inspection — never grants access (no replay writes)
const inspected = await inspectSignedDecisionReceipt({
  signed_record: holderReceipt,
  relying_party: { partner_id: "your-partner", policy_id: "your-policy" },
  request_id: "checkout_inspect",
  trust_env: trust.env,
});

// Authorization — durable replay + authenticated revocation on your infrastructure
const store = new FileReceiptConsumptionStore(process.env.RP_CONSUMPTION_DIR!);
const decision = await verifySignedDecisionReceipt({
  signed_record: holderReceipt,
  relying_party: { partner_id: "your-partner", policy_id: "your-policy" },
  request_id: "checkout_123",
  trust_env: trust.env,
  consumption_store: store,
  revocation_source: institutionOperatedRevocationFeed,
});

if (!decision.authorize) {
  return res.status(403).json({ errors: decision.rejection_reasons, digest_v: RECEIPT_TRUST_DIGEST_VERSION });
}

Monorepo reference: examples/institutional-verifier-backend · Clean-room consumer smoke: examples/external-sdk-consumer

Replay and revocation

• FileReceiptConsumptionStore — single-host reference only; requires shared atomic filesystem for multiple processes.
• Multi-instance production — implement ReceiptConsumptionStore with PostgreSQL, Redis, or equivalent compare-and-set semantics.
• Revocation — use an institution-operated adapter with observed_at freshness; never treat arbitrary JSON as authenticated issuer evidence.
• Digest v2 — re-pin ABRAXAS_RECEIPT_KEY_DOCUMENT_DIGEST when rotating keys or changing lifecycle metadata.

Rejection reason codes (partner-safe)

Separation of concerns

• Receipt verification — cryptographic authenticity + registry (this module).
• Application policy enforcement — your product rules after authorize === true.
• Issuer trust configuration — pinned env + optional digest-checked fetch.
• Revocation freshness — authenticated portable snapshots + checkpoint store on your side.
• Replay state — durable consumption store you operate (filesystem or DB).

Billing and metering can wrap successful authorize events without making signature verification depend on Abraxas online services.

Quick links

Institutional protocol access and signed receipts. Commerce Partner Flow is a separate path.

1. Step 1
   Create application

   Create or select your sandbox application in Launchpad.

   Launchpad →
2. Step 2
   Choose verification

   Select organization protocol access for this integration.

   Verify →
3. Step 3
   Connect application

   Add callbacks and sandbox credentials.

   Connect →
4. Step 4
   Test sandbox

   Run tests and complete holder verification.

   Test →
5. Step 5
   View receipt

   Review the signed receipt and integration activity.

   Workspace →
6. Step 6
   Request Production

   Submit sandbox evidence for Production authorization.

   Production →