# Identity & KYC

Technical overview of how KYC/AML verification is performed via SumSub and bound to investor identities on the Internet Computer. The ICP KYC Registry is the single authoritative record of every verified investor — all compliance state on EVM chains is derived from it via Chain Fusion synchronization.

# Identity Binding

Tortuga uses SumSub for identity verification: identity confirmation, source-of-funds assessment, sanctions screening, and investor qualification. Upon successful verification, the result is written to the ICP KYC Registry canister, and Chain Fusion propagates the whitelist status to the ERC-3643 Identity Registry on all live chains (Plume, Base, Canton).

flowchart TB
    USER[Investor] --> SUMSUB[SumSub Verification]
    SUMSUB --> RESULT{Approved?}
    RESULT -->|Yes| BACKEND[Issuer Backend]
    RESULT -->|No| REJECT[Rejected]

    BACKEND --> KYC[ICP KYC Registry]
    KYC --> CF[Chain Fusion]
    CF --> PLUME[ERC-3643 Identity Registry — Plume]
    CF --> BASE[ERC-3643 Identity Registry — Base]
    CF --> CANTON[ERC-3643 Identity Registry — Canton]

# Binding Options

# Option 1: New Principal

A new cryptographic principal is created specifically for the user.

sequenceDiagram
    participant User
    participant Sumsub as SumSub
    participant Backend as Issuer Backend
    participant Registry as ICP KYC Registry

    User->>Sumsub: Complete Verification
    Sumsub-->>Backend: Webhook (Approved)
    Backend->>Backend: Generate New Principal
    Backend->>Registry: Write verified identity + wallet addresses
    Backend-->>User: Principal + Seed Phrase

Pros	Cons
Simple onboarding	New wallet to manage
Dedicated identity	Not portable to other ICP apps

# Option 2: Internet Identity

KYC status is bound to the user's existing Internet Identity.

sequenceDiagram
    participant User
    participant II as Internet Identity
    participant Sumsub as SumSub
    participant Backend as Issuer Backend
    participant Registry as ICP KYC Registry

    User->>II: Authenticate
    II-->>Backend: Principal
    Backend->>Sumsub: Start KYC (with Principal ref)
    User->>Sumsub: Complete Verification
    Sumsub-->>Backend: Webhook (Approved)
    Backend->>Registry: Write verified identity + wallet addresses

Pros	Cons
Use existing identity	Requires II account
Portable across ICP ecosystem	Slightly more complex flow

# KYC Registry Canister

The KYC Registry is a canister on ICP that stores verification status. It is the single authoritative compliance record — all EVM chain state is derived from it.

flowchart LR
    subgraph "ICP KYC Registry"
        MAP[Principal → Status]
        LEVEL[Verification Level]
        JURISDICTION[Jurisdiction]
        WALLETS[Associated Wallets]
        EXPIRY[Expiration]
    end

    ML[Master Ledger] --> MAP
    CF[Chain Fusion] --> WALLETS

# Data Model

type KycStatus = variant {
    Pending;
    Verified : KycData;
    Rejected;
    Revoked;
    Expired;
};

type KycData = record {
    level : KycLevel;
    jurisdiction : Text;
    accreditation : AccreditationStatus;
    wallet_addresses : vec WalletBinding;
    verified_at : Timestamp;
    expires_at : opt Timestamp;
    last_updated : Timestamp;
    provider_ref : Text;  // SumSub reference
};

type KycLevel = variant {
    Basic;      // Individual KYC
    Enhanced;   // Enhanced due diligence
    Corporate;  // KYB for entities
};

type AccreditationStatus = variant {
    Qualified;      // Qualified investor per applicable regime
    Professional;   // Professional investor (Swiss standard)
    None;
};

type WalletBinding = record {
    chain : Chain;
    address : Text;
    registered_at : Timestamp;
    active : bool;
};

# Registry Interface

service : {
    // Query KYC status
    get_status : (Principal) -> (opt KycStatus) query;

    // Check if principal is verified (used by Master Ledger)
    is_verified : (Principal) -> (bool) query;

    // Called by issuer backend after SumSub webhook
    set_verified : (Principal, KycData) -> (Result);

    // Revoke verification (sanctions hit, document expiry, voluntary offboarding)
    revoke : (Principal) -> (Result);

    // Update wallet addresses
    update_wallets : (Principal, vec WalletBinding) -> (Result);
}

# Revocation Flow

If an investor's KYC is revoked — sanctions hit, document expiry, voluntary offboarding — the revocation is written to the ICP KYC Registry and propagates via Chain Fusion to the ERC-3643 Identity Registry on all live chains. The investor's wallet is removed from the Identity Registry. The investor cannot receive or transfer tokens from that point. Existing balance is frozen in place (not destroyed) pending resolution.

For the full compliance synchronization architecture, see architecture/compliance-layer.md.

# Integration with Master Ledger

The Master Ledger queries the KYC Registry before allowing operations.

flowchart TB
    REQ[Transfer Request] --> ML[Master Ledger]
    ML --> CHECK[Query KYC Registry]
    CHECK --> STATUS{Both Verified?}
    STATUS -->|Yes| EXEC[Execute Transfer]
    STATUS -->|No| DENY[Deny Transfer]

All token operations (mint, transfer, burn) require:

Caller principal is verified
Recipient principal is verified (for transfers)
Verification has not expired
Wallet address is active in the registry

# ERC-3643 Enforcement on EVM

On EVM chains (Plume, Base, Canton), compliance is enforced at the token contract level via ERC-3643. The canTransfer(from, to, amount) function checks the on-chain Identity Registry — which mirrors current ICP KYC Registry state — before every transfer. A non-whitelisted wallet cannot receive or transfer Tortuga tokens. No manual override exists.

For the full ERC-3643 architecture, see architecture/compliance-layer.md.

For the token lifecycle that depends on KYC verification, see the Token Lifecycle section.

For the Master Ledger that queries the KYC Registry, see Master Ledger.

For chain-specific deployment and compliance enforcement, see Supported Chains.

For product structure and investor protections, see the Product section.