Relying party program

Verify once. Your protocol clears the transaction.

A relying party is any lender, marketplace, registry, or protocol that accepts an Abraxas credential or Passport state to clear a downstream action. without re-running KYC on the user.

Minimal integration path

External relying parties: one verify call → cryptographic proof → independent check. Full guide with copy-paste examples at /docs/relying-party-verify · JSON API

Current pilot status

Pilot-ready verification infrastructure for real assets. Public verification, consent-based Passport access, and partner policy APIs are live in pilot. External relying-party and external-originator onboarding is underway.

Why this is the network-effect milestone

Abraxas becomes infrastructure when an unaffiliated lender, marketplace, or protocol checks our credential state in production. not when we claim acceptance on a landing page. First-party flows (Cielo booking, /passport) prove the rails work. Your integration proves they travel.

Partner sandbox (internal demo)

Tier 3 policy, consent, and screening architecture is live for testing. labeled honestly as a sandbox, not as an external relying party.

Sandbox · not an external partner
Abraxas Partner Sandbox

Sandbox demonstration — not a live financial offering or external partner integration.

Demonstration policy for testing transaction-specific eligibility. Exercises portable identity, wallet binding, and sandbox screening claims — not document re-upload.

Policy partner-sandbox-gate-v1 · POST /api/v1/verification-requests · Status sandbox
Try on Passport →

Holders never paste API keys. they consent at /passport?verify_request=…

External relying parties

Four-step onboarding

1
Choose your trust gate

Identity-only (POST /api/credentials/verify), wallet trust (GET /api/trust/status), or asset registry (GET /api/verify/registry).

2
Test in sandbox

Use /verify/ABX-RE-HOSP-001 or POST with your abx_live_ key. Confirm decision: approved before wiring production gates.

3
Implement the gate

Call our API server-side. Never trust client-side JWT parsing alone. verify signature via our endpoint or published Ed25519 public key.

4
Pilot + measure

Run a 30-day pilot with a defined metric: time-to-verify, conversion lift, or cost per manual review eliminated.

Production integration path

  • Read /docs/relying-party-verify. one verify call → proof → independent check
  • Issue abx_live_ key with verify:credential scope
  • Implement server-side POST /api/credentials/verify at your transaction gate
  • Confirm GET /api/proof/{proof_id} returns signature_valid: true
  • First approved production verify logs toward the external RP mainnet gate

Gate status updates automatically when an external abx_live_ partner receives decision: approved on a production verify call.

Asset monitoring webhook (partners)

Title companies, registries, and operators can push material state-change signals. Abraxas maps them to credential refresh or suspend. fail-closed at transaction time.

// Partner webhook. report lot status change (MLS sync)
const res = await fetch("https://abraxas-app.vercel.app/api/v1/listings/lot-status", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: "Bearer abx_live_YOUR_KEY",
  },
  body: JSON.stringify({
    asset_id: "ABX-RE-LAND-006",
    idempotency_key: "cpg:2026-07-18:lot4",
    lots: [
      { lot: 4, status: "under_contract", notes: "MLS offer accepted" },
    ],
  }),
});

const result = await res.json();
// { ok: true, fingerprint, changed, results[] }

// Or via asset-signals with credential review:
await fetch("https://abraxas-app.vercel.app/api/v1/asset-signals", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: "Bearer abx_live_YOUR_KEY",
  },
  body: JSON.stringify({
    asset_id: "ABX-RE-LAND-006",
    signal_type: "listing_status_change",
    apply: true,
    lots: [{ lot: 4, status: "under_contract" }],
  }),
});

API reference. credential verify

Full identity gate for regulated flows. User presents JWT; your server verifies via Abraxas.

// Server-side: verify → decision + cryptographic proof
const res = await fetch("https://abraxas-app.vercel.app/api/credentials/verify", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: "Bearer abx_live_YOUR_KEY",
  },
  body: JSON.stringify({
    record_id: "ABX-RE-HOSP-001",
    policy_id: "abraxas-verify-v1",
  }),
});

const result = await res.json();
// decision, proof_id, verify_url, authentication_proof, decision_receipt

if (result.decision === "approved") {
  const proof = await fetch(result.verify_url).then(r => r.json());
  if (proof.signature_valid && proof.proof_reliable) {
    // Clear gated action. independently verifiable proof on record
  }
}

API reference. trust status

Lightweight wallet check for browse-to-transact flows.

// Lightweight gate: does this Sui wallet have an Abraxas account + ID?
const res = await fetch(
  `https://abraxas-app.vercel.app/api/trust/status?sui=${walletAddress}`
);
const trust = await res.json();

if (trust.enhanced_trust) {
  // ID verified + active credential
} else if (trust.ready_to_transact) {
  // Account exists. optional ID for your risk tier
}

API reference. public registry

Asset and Passport DID lookup with assurance taxonomy (L1–L4).

// Verify an asset or Passport DID in the public registry
const res = await fetch(
  `https://abraxas-app.vercel.app/api/verify/registry?q=${encodeURIComponent(identifier)}`
);
const state = await res.json();

if (state.state === "RESOLVED_VALID" && state.assurance_level >= 3) {
  // L3+ attested. suitable for collateral decisions
}

Try: ABX-RE-HOSP-001 · Integration docs

Open design partner slots

RWA marketplace

Investor eligibility gate without re-KYC

POST /api/credentials/verify
Private credit / lending

Collateral + identity tier for borrow

GET /api/verify/registry
Music / IP platform

Catalog ownership attestation

GET /api/verify/registry
Regulated retail (cannabis)

Age-gated Passport + batch COA provenance

POST /api/credentials/verify
Corporate registry

Wyoming LLC + asset binding check

GET /api/trust/status

Relying party limitations

  • Abraxas credentials attest to verification state. they are not investment advice or securities approvals.
  • Relying parties must define their own risk tier mapping (which assurance level clears which action).
  • Passport reuse on Abraxas today; external partner acceptance expands as design partners come online.
  • Revoked or expired credentials must fail closed. always check state at transaction time, not cache indefinitely.
Apply as design partner →Strategic roadmapAIL spec →