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 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.
Holders never paste API keys. they consent at /passport?verify_request=…
External relying parties
Four-step onboarding
Identity-only (POST /api/credentials/verify), wallet trust (GET /api/trust/status), or asset registry (GET /api/verify/registry).
Use /verify/ABX-RE-HOSP-001 or POST with your abx_live_ key. Confirm decision: approved before wiring production gates.
Call our API server-side. Never trust client-side JWT parsing alone. verify signature via our endpoint or published Ed25519 public key.
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
Investor eligibility gate without re-KYC
POST /api/credentials/verifyCollateral + identity tier for borrow
GET /api/verify/registryCatalog ownership attestation
GET /api/verify/registryAge-gated Passport + batch COA provenance
POST /api/credentials/verifyWyoming LLC + asset binding check
GET /api/trust/statusRelying 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.