The Compliance Passport for tokenized finance

Abstract

Regulated finance is moving on-chain, but identity and compliance have not kept up. Every platform re-runs its own KYC, users re-submit the same documents, and sensitive data is copied across hundreds of databases. SBX ID is an identity and compliance infrastructure layer: a user is verified once by an accredited issuer, receives a portable verifiable credential held in their own wallet, and presents it — selectively and with cryptographic consent — to any platform that needs it. Platforms receive exactly the attributes they request, run their own AML obligations against verified data, and record an auditable consent receipt.

SBX ID is built on open identity standards (W3C Verifiable Credentials and DIDs), modern selective-disclosure formats (SD-JWT-VC), zero-knowledge predicate proofs for on-chain eligibility, and a minimal on-chain anchor that never stores personal data. It is the compliance layer of the SUPERBLOCK ecosystem.

Design principles

• Verify once, reuse everywhere — one verification event, many platforms.
• User-held and consent-gated — data moves only when the user signs to release it.
• Minimal disclosure — share the smallest set of attributes (or a yes/no proof) that satisfies the request.
• No PII on-chain — the ledger holds only non-personal, expiring commitments.
• Standards over bespoke — interoperate with the broader identity and tokenization stack rather than reinvent it.
• Reliance, not replacement — platforms keep regulatory responsibility; SBX ID accelerates their work.

The problem

Compliance in tokenized finance is fragmented by design. The same investor is verified again and again, and the cost and risk compound as the market scales.

The financial system does not have an identity problem — the checks have been done and the data exists. It has an identity architecture problem: nobody has made verified identity portable, private, and enforceable across platforms. That is what SBX ID provides.

How SBX ID works

SBX ID separates the one-time act of verification from the repeatable act of disclosure.

1. Verify once. The user completes KYC/IDV with SBX ID (or, later, any accredited issuer). Documents are authenticated, liveness is checked, and sanctions/PEP screening is run.
2. Receive a credential + on-chain marker. SBX ID issues a verifiable credential to the user's wallet and mints a non-transferable soulbound token so any platform can see the wallet is verified. The credential asserts attributes (jurisdiction, investor class, KYC level, expiry) signed by the issuer; raw documents stay encrypted in SBX GRID.
3. Reuse with consent. When a platform needs to onboard the user, it sends a presentation request. The user reviews it and signs to release only the requested attributes. The platform verifies the issuer signature and revocation status, then runs its own AML.
4. Enforce on-chain when needed. For tokenized assets and DeFi, eligibility is enforced at the contract level using a privacy-preserving attestation or a zero-knowledge proof — without exposing identity.

Roles & trust model

SBX ID follows the standard three-party credential model. Keeping these roles distinct is what bounds liability and preserves user control.

No party can act alone against the user's interest: the issuer cannot disclose data without the holder's signature, the verifier cannot read anything the holder did not release, and the on-chain layer never holds personal data at all.

System architecture

SBX ID is organised into five layers. The upper layers handle identity and consent off-chain; the lower layers handle enforcement and lifecycle. The jurisdiction-aware rules engine is cross-cutting — it feeds both the assurance levels offered during disclosure and the predicates enforced on-chain.

Each layer is addressed in detail in the sections that follow. The remainder of this whitepaper moves top-to-bottom: the credential and consent flow first, then cryptography, on-chain enforcement, storage, and lifecycle.

The credential

The unit of identity in SBX ID is a W3C Verifiable Credential (VC) bound to a Decentralized Identifier (DID). It is issued once and held by the user, not stored centrally for reuse. Credentials are encoded as SD-JWT-VC so the holder can disclose individual claims without revealing the rest.

Identifiers

Each user controls a DID. SBX ID supports did:pkh (derived from the user's wallet address) and did:key for app-managed keys; the credential subject is the user's DID, and the issuer is SBX ID's DID. This decouples identity from any single chain or platform account.

Credential contents

The credential asserts only compliance-relevant attributes. Raw documents and full PII never live in the credential — they remain encrypted in SBX GRID and are referenced, not embedded.

// SD-JWT-VC payload — claims are individually disclosable
{
  "iss": "did:web:sbxid.com",
  "sub": "did:pkh:eip155:1:0x7f3...d91",
  "vct": "https://sbxid.com/schema/compliance-passport/1",
  "iat": 1750000000,
  "exp": 1813072000,
  "status": { "status_list": { "uri": "https://sbxid.com/status/3", "idx": 9214 } },
  "kyc_level": "enhanced",
  "investor_class": "qualified_institutional",
  "jurisdiction": "AE",
  "residency": "AE",
  "sanctions_screened": true,
  "vault_ref": "grid://v1/4c0a...e22"   // encrypted docs, not the docs
}

Because the format is SD-JWT-VC, the holder can present, for example, investor_class and jurisdiction while withholding residency — or present none of them and instead prove a predicate over them (see Privacy & cryptography).

Consent & disclosure

Disclosure is the core repeatable flow and is always initiated by a request and authorised by a signature. SBX ID uses the OpenID for Verifiable Presentations (OIDC4VP) request/response pattern so it interoperates with standard wallets.

Consent receipts

Every disclosure produces a signed consent receipt recording who requested what, which attributes were released, the purpose, and an expiry. The receipt is retained by both parties as an auditable record and is the basis for later revocation of access. Receipts contain metadata only — never the disclosed PII.

Privacy & cryptography

SBX ID minimises what is revealed at every step using three complementary techniques.

Selective disclosure

SD-JWT-VC lets the holder reveal a subset of claims while the issuer's signature still verifies over the disclosed set. A platform that only needs jurisdiction never sees the user's name or document numbers. BBS+ signatures are a Planned upgrade for unlinkable multi-show selective disclosure.

Zero-knowledge predicate proofs

When a verifier needs only a yes/no answer, the holder proves a predicate over their credential without revealing the underlying attribute — for example, "jurisdiction is in the allowed set," "investor class ≥ accredited," or "not sanctioned as of status epoch N." Proofs are generated client-side and verified by a smart contract or API.

// proven in zero knowledge against the held credential
prove(
  jurisdiction ∈ {AE, SG, GB, CH},
  investor_class ≥ accredited,
  sanctions_screened == true,
  exp > now()
) → { proof, nullifier }   // no attribute values revealed

Nullifiers & sybil resistance

Each proof emits a nullifier — a deterministic, per-context value derived from the credential and the verifier's scope. The same person produces the same nullifier for a given platform (so they cannot create multiple "fresh" identities there), but nullifiers are unlinkable across platforms (so activity cannot be correlated between them). This gives one-person-one-credential guarantees without a global, trackable identifier.

On-chain enforcement

For tokenized assets and permissioned DeFi, eligibility must be enforced where the value moves — in the contract. SBX ID anchors verification with a soulbound token minted to the user's wallet, while keeping the on-chain footprint minimal and free of personal data.

The soulbound token

When a user is verified, SBX ID mints a non-transferable soulbound token (ERC-5192) to their wallet. Any platform can read it on-chain to instantly confirm that this wallet holds a valid SBX ID — and check the investor class, a salted jurisdiction commitment, the expiry, and a revocation pointer. The token deliberately carries no personal data: the documents and attributes behind it stay encrypted off-chain in SBX GRID. It pairs with EAS attestations for general use and ERC-3643 / ONCHAINID for regulated security tokens.

This is the "easy identification" layer: a platform doesn't have to ask whether a wallet is KYC-verified — the marker is right there on-chain. To actually view a user's KYC documents or attributes, the platform still needs the user to sign consent when the wallet interacts with it (the disclosure flow). Identification is public; data access is always permissioned.

Enforcement points

Integrating contracts enforce eligibility by reading the soulbound token (ERC-3643 compliance modules) or by verifying a fresh ZK proof at transfer time for privacy-sensitive flows. Account-abstraction wallets (ERC-4337) can enforce the same policy as a validation module (ERC-7579), so eligibility travels with the account rather than being re-checked by every dApp.

Target networks at launch are Ethereum and Polygon, with additional EVM chains and cross-chain attestation relay on the roadmap. Planned

Storage — SBX GRID

Raw documents and full PII are never held in the credential or on-chain. They live in SBX GRID, the ecosystem's decentralized storage layer, under client-side encryption.

• Zero-knowledge storage — GRID nodes store ciphertext only; they never see plaintext or keys.
• User-held keys — encryption keys are derived from the user's wallet, with optional MPC / social-recovery backup so a lost device does not force re-verification.
• Data residency — content is geo-sharded and pinned to satisfy in-country storage requirements in jurisdictions that mandate them.
• Durability — erasure coding across nodes provides resilience without a single point of failure (and without a single honeypot).

A platform never receives documents from GRID directly. It receives only the attributes the user discloses; if a regulator later requires the underlying document, retrieval is again gated by the user's signed consent (or a lawful, logged compulsion path).

Rules engine

The jurisdiction-aware rules engine is the part of SBX ID that encodes what compliant means for a given context. It is policy-as-code: versioned, testable, and auditable.

A policy maps a request context (asset type, offering exemption, target jurisdictions) to the attributes and assurance level required, and to the on-chain predicate that enforces it. Policies are referenced by id, so a platform integrates once and the underlying rules can be updated centrally as regulations change.

{
  "policy_id": "rwa.reg-d.506c",
  "requires": {
    "investor_class": "accredited_or_above",
    "jurisdiction_in": ["US", "AE", "SG", "GB"],
    "sanctions_screened": true,
    "max_kyc_age_days": 365
  },
  "enforcement": "zk_predicate"
}

Every decision the engine returns carries a deterministic reason code, so an allow or deny can be explained and audited after the fact.

Lifecycle

Credentials are living objects. SBX ID manages their full lifecycle so verification stays trustworthy over time.

Security & threat model

SBX ID's security rests on keeping data off-chain, encrypted, and consent-gated, and on distributing trust so no single party is a point of failure.

Trust assumptions

• The issuer correctly performs KYC and protects its signing keys.
• The MPC parties protecting recovery and vault key control are independent and non-colluding.
• The user protects their wallet (mitigated by recovery), and the verifier safeguards any data it receives.

Independent ZK circuit audits, smart-contract audits, a SNARK trusted-setup ceremony, and SOC 2 / ISO 27001 certification are part of the pre-launch program. Planned

SUPERBLOCK ecosystem

SBX ID is the identity and compliance layer of the SUPERBLOCK ecosystem. It gives every other product a shared, verified user base and a single compliance integration, and it is built to serve external platforms on the same terms.

Within the ecosystem, SBX Prime gates investor onboarding through SBX ID, SBX AURA confirms counterparties are eligible before settlement, Rizq Finance verifies eligibility for Shariah-compliant products, and SBX GRID provides the encrypted storage substrate. The same integration is available to external RWA platforms, exchanges, DeFi protocols, banks, and fintechs.

Token utility ($SBX)

$SBX is the ecosystem utility token. Its role in SBX ID is confined to the network layer:

• Partner access & SLA — platforms stake or hold $SBX to unlock higher API tiers, rate limits, and support SLAs.
• Governance — through SBX DAO, $SBX governs protocol parameters (issuer accreditation standards, fee schedules, treasury), never individual compliance decisions.
• Issuer staking Planned — accredited KYC issuers post a $SBX bond; mis-issuance is slashable, tying token economics to network integrity rather than to user gating.

Governance & roadmap

Governance

SBX ID launches under SUPERBLOCK stewardship and progressively decentralises to SBX DAO, which governs protocol parameters, the accreditation standard for federated issuers, fee schedules, and treasury allocation. Compliance decisions about individuals are never subject to governance — they are determined solely by the rules engine and the relying platform's own obligations.

Roadmap

Developer guide

This section is for engineers integrating SBX ID. The API is REST + JSON; on-chain integration is via the registry contracts and SDKs. All examples target the sandbox.

Integration flow

Authentication

API requests authenticate with a secret key in the Authorization header. Use the sk_test_… key against the sandbox and sk_live_… in production. Never expose secret keys in client-side code.

GET https://api.sbxid.com/v1/health
Authorization: Bearer sk_test_7f3d91...e22
Content-Type: application/json

Webhook payloads are signed; verify the SBXID-Signature header (HMAC-SHA256 over the raw body) before trusting an event. See Webhooks.

API reference

Base URL: https://api.sbxid.com/v1. All responses are JSON; errors use standard HTTP status codes with a machine-readable code and human-readable message.

Create a verification session

POST /v1/verification-sessions
{
  "reference": "user_8821",
  "policy_id": "rwa.reg-d.506c",
  "redirect_url": "https://yourapp.com/kyc/return"
}

{
  "id": "vs_3kf9...a1",
  "status": "pending",
  "hosted_url": "https://verify.sbxid.com/s/3kf9a1",
  "expires_at": "2026-06-16T18:30:00Z"
}

Check eligibility

POST /v1/compliance/check
{
  "subject": "did:pkh:eip155:1:0x7f3...d91",
  "policy_id": "rwa.reg-d.506c"
}

{
  "decision": "allow",
  "reason_code": "OK_ELIGIBLE",
  "checked_at": "2026-06-16T17:58:11Z",
  "expires_at": "2026-06-16T18:58:11Z"
}

SDKs

Official SDKs wrap the REST API and presentation flows. The TypeScript SDK is shown below; a Python SDK follows the same shape.

import { SbxId } from "@sbxid/sdk";

const sbx = new SbxId({ apiKey: process.env.SBXID_KEY });

// 1 · start a verification session
const session = await sbx.verification.create({
  reference: "user_8821",
  policyId: "rwa.reg-d.506c",
});
redirect(session.hostedUrl);

// 2 · later, gate an action on eligibility
const { decision } = await sbx.compliance.check({
  subject: userDid,
  policyId: "rwa.reg-d.506c",
});
if (decision !== "allow") throw new Error("not eligible");

Smart-contract integration

On-chain, integrating contracts read the SBX ID registry to gate transfers or actions. The interface returns an eligibility boolean and a reason code; for privacy-sensitive flows, a verifier contract checks a ZK proof instead.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

interface ISBXIDRegistry {
  function isEligible(address account, bytes32 policyId)
    external view returns (bool ok, uint16 reason);
}

contract GatedVault {
  ISBXIDRegistry public immutable registry;
  bytes32 public constant POLICY = "rwa.reg-d.506c";

  constructor(address _registry) { registry = ISBXIDRegistry(_registry); }

  modifier onlyCompliant() {
    (bool ok, uint16 reason) = registry.isEligible(msg.sender, POLICY);
    require(ok, "SBXID: not eligible");
    _;
  }

  function deposit() external payable onlyCompliant {
    // ... eligible participants only
  }
}

For ERC-3643 security tokens, SBX ID plugs in as a compliance module so transfer restrictions are evaluated natively by the token. For account-abstraction wallets, the same check can run as an ERC-7579 validation module.

Webhooks

Subscribe to events to react to verification and lifecycle changes without polling. Verify every payload's signature before acting on it.

import crypto from "node:crypto";

function verify(rawBody, header, secret) {
  const expected = crypto.createHmac("sha256", secret)
    .update(rawBody).digest("hex");
  return crypto.timingSafeEqual(
    Buffer.from(header), Buffer.from(expected));
}

Sandbox & testing

The sandbox mirrors production with deterministic test outcomes, so you can build the full flow before going live.

• Use sk_test_… keys; no real identity data is processed.
• Drive outcomes with reserved test subjects, e.g. did:pkh:…:0xTESTallow (eligible), 0xTESTreview (manual review), 0xTESTdeny (sanctioned/denied).
• Trigger lifecycle events from the dashboard to test credential.revoked and consent.revoked handling.
• Sandbox attestations are written to a testnet registry (Polygon Amoy) for end-to-end on-chain testing.

Legal & regulatory

Status. SBX ID is in pre-launch development. This document is technical and informational. It is not an offer or solicitation to buy or sell any security, token, or financial instrument, and it is not legal, tax, financial, or compliance advice.

Reliance. SBX ID provides verified identity data and tooling to partner platforms. Each platform remains independently responsible for its own KYC/AML obligations and regulatory compliance in its jurisdictions, consistent with FATF Recommendation 17 and applicable AML reliance frameworks. SBX ID does not assume a partner's regulatory obligations.

Data protection. SBX ID is designed for data-protection compliance (including GDPR): personal data is held off-chain under user-controlled encryption, disclosure requires the user's explicit signed consent, and data is erasable. SBX ID does not write personal data to any immutable ledger.

Travel Rule. SBX ID supplies verified identity data that can help partners meet FATF Recommendation 16 (Travel Rule) obligations; it is not itself a Travel Rule messaging solution.

Forward-looking statements. Items marked Planned describe intended functionality and may change. No assurance is given as to timing or delivery.

Glossary

FAQ

Does a platform stop doing its own KYC?

No. The platform receives verified data and a signed consent trail, then runs its own AML. SBX ID accelerates that work; it does not assume the platform's regulatory responsibility.

Where is my personal data stored?

Encrypted in SBX GRID under keys you control. It is never written to a blockchain, and it is shared only when you sign to release it.

What lives on-chain, then?

Only a non-personal attestation: a validity flag, investor class, a salted jurisdiction commitment, an expiry, and a revocation pointer. Nothing that identifies you.

Can I be tracked across platforms?

No. Disclosures are minimal and per-context nullifiers are unlinkable between platforms, so your activity cannot be correlated through SBX ID.

What if I lose my wallet?

MPC / social recovery restores access without re-running KYC; the old key can be revoked and the credential reissued.

Is $SBX required to verify?

Never. The token is confined to network-layer utility and governance and plays no part in any individual's verification.