System Architecture

• Minimize on-chain and off-chain exposure of personal data
• Remain composable with existing Solana programs
• Support multiple KYC providers without lock-in
• Enable auditability without centralizing trust

1. Client Application

The consuming Solana application or backend service. Responsible for initiating identity verification flows and enforcing access control based on verification state.

2. KYC Compliance SDK

A middleware layer that abstracts provider-specific logic, normalizes verification states, and exposes a stable interface to application developers.

3. Off-Chain Verification Providers

External identity verification services. Providers never interact directly with Solana programs.

4. Solana Programs

On-chain programs consume verification proofs or flags without storing personal or identifying information.

• User initiates a verification flow through the client app
• SDK routes the request to a configured verification provider
• Provider performs identity checks off-chain
• SDK receives a verification result or proof
• Client enforces access based on verification status
• Optional proof references are passed to Solana programs

The SDK is explicitly designed to separate trust domains. No single component has access to both identity data and on-chain authority.

• Solana programs never receive raw identity data
• Verification providers never interact with on-chain logic
• Client applications control enforcement logic

The architecture supports adding new providers, jurisdictions, or verification methods without modifying core interfaces. This allows the SDK to evolve alongside regulatory and ecosystem changes.