Integrators

Portable credentials & verification API

W3C Verifiable Credentials as Ed25519-signed JWTs. Verify once. rely on cryptographic proof, not re-KYC.

Example credential claims

Structured claims include assurance levels (L1–L4), sources, refresh dates, and asset-specific attestations.

{
  "iss": "did:sui:abraxas-issuer",
  "sub": "did:sui:0x…",
  "vc": {
    "credentialSubject": {
      "verification": {
        "level": "L3",
        "status": "active",
        "lastVerified": "2026-06-15",
        "refreshDue": "2026-12-15"
      },
      "identity": {
        "provider": "Veriff",
        "assurance": "government_id_liveness"
      },
      "asset": {
        "id": "ABX-RE-HOSP-001",
        "name": "Cielo Sunrise",
        "type": "hospitality",
        "appraisedValue": {
          "amount": 1100000,
          "currency": "USD",
          "assurance": "L3",
          "source": "Blue Ridge Highlands Appraisal",
          "asOf": "2025-05-01"
        }
      }
    }
  }
}

Integrator endpoints

POST
/api/credentials/verify
Verify + issue authentication proof (decision, proof_id, verify_url)
GET
/api/proof/{proof_id}
Self-verifying proof lookup — signature_valid, public_key
GET
/api/proof/reference/{assetId}
Production reference demo (Cielo · Chickasaw)
GET
/api/docs/relying-party
Machine-readable external RP integration guide (JSON)
GET
/api/credentials/public-key
Ed25519 issuer public key
GET
/api/credentials/verify?wallet=…
Wallet credential status
GET
/api/verify/registry?q=…
Asset + registry lookup
GET
/api/trust/status?sui=…
Account trust tier

Best practices for relying parties

  • Verify Ed25519 signature against GET /api/credentials/public-key
  • Check assurance level on each claim. do not treat L1 the same as L4
  • Respect refreshDue dates. stale appraisals may need re-attestation
  • Support selective disclosure. request only claims needed for the action
  • Handle revocation. credentials can be revoked server-side
Public verifier →Partner programWhy verification