# Compliance Layer

This document explains how compliance enforcement works across the ICP-EVM stack — from SumSub KYC verification through ICP as the source of truth to ERC-3643 enforcement on each live chain. The architecture ensures that a non-whitelisted wallet cannot receive Tortuga tokens on any chain, because every compliance check ultimately traces back to ICP-confirmed identity state.

# Design Principle

Compliance is enforced at the token contract level, not the application level. It cannot be bypassed by interacting with a different interface, a different protocol, or a different front-end. The source of truth is ICP; enforcement is native on EVM. A transfer to a non-whitelisted wallet is rejected by the smart contract automatically, without issuer intervention.

Protocol-level compliance. There is no configuration of DeFi protocol, wallet interface, or smart contract interaction that can move Tortuga tokens to an unverified address. Compliance is embedded in the asset, not in the venue.

# ERC-3643 Components

# Identity Registry

Every investor wallet is linked to an on-chain identity record. The record does not store PII — it stores cryptographic claims proving KYC status, accreditation status, and jurisdiction. Only registered wallet addresses can hold or transact in the token. The registry is maintained by Tortuga's compliance layer and updated via Chain Fusion synchronization from ICP.

# Compliance Module

Per-token rules encoded at deployment: investor caps, geographic restrictions (US persons excluded across all issuances), lockup periods, transfer limits, accreditation requirements. Rules are checked on every transfer. Rules can be updated by the Tortuga compliance agent without redeploying the token contract, subject to timelock.

# Transfer Validation

canTransfer(from, to, amount) is called before every transfer. The function checks both the Identity Registry (are both wallets registered and active?) and the Compliance Module (do all configured rules pass?). If any condition fails, the transaction is rejected on-chain. No manual override path exists.

# ICP as Compliance Source of Truth

SumSub performs KYC/AML verification: identity confirmation, source-of-funds assessment, sanctions screening, and investor qualification. Upon successful completion, SumSub calls the Tortuga issuer backend, which writes the verified identity to the ICP KYC Registry canister.

The KYC Registry canister records per principal:

Verification status
Jurisdiction
Accreditation level
Associated wallet addresses
Last updated timestamp
Status (active / revoked / pending)

The ICP KYC Registry is the single authoritative record. Any compliance state on EVM is derived from it.

For the KYC Registry canister interface, see master-ledger.md.

# Chain Fusion Synchronization

When the ICP KYC Registry is updated — new wallet whitelisted, existing wallet revoked, accreditation status changed, jurisdiction updated — the Chain Fusion canister detects the state change and propagates it to the ERC-3643 Identity Registry on all live chains (Plume, Base, Canton) via threshold-signed transactions.

For Chain Fusion threshold signature mechanics, see chain-fusion.md.

sequenceDiagram
    participant SUMSUB as SumSub
    participant BACKEND as Issuer Backend
    participant KYC as ICP KYC Registry
    participant CF as Chain Fusion
    participant ERC as ERC-3643 Identity Registry (EVM)

    SUMSUB->>BACKEND: Verification complete
    BACKEND->>KYC: Write verified identity + wallet
    KYC->>CF: State change detected
    CF->>CF: Build update transaction
    CF->>CF: Request threshold signature
    CF->>ERC: Submit signed update (Plume / Base / Canton)
    ERC-->>CF: Confirmed
    Note over ERC: canTransfer() now reflects current ICP state

# Why This Architecture

Why not check ICP at transfer time on EVM? Two reasons:

EVM cannot call ICP synchronously during transaction execution. It would require a cross-chain oracle with all the associated latency and manipulation risk. A lending protocol cannot depend on ICP availability to execute a liquidation.
DeFi protocol integration requires self-contained EVM compliance. Protocols integrating Tortuga tokens need compliance checks to resolve within a single EVM transaction, without external dependencies at execution time.

The synchronization model gives both: EVM-native enforcement without a live ICP dependency on every transfer, while ICP remains the single source of truth.

# 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 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. Token supply is unchanged.

# Access Control

Component	Write Access	Constraint
ICP KYC Registry	Authenticated issuer backend canister call only	No other caller can modify identity records
ERC-3643 Compliance Module rules	Tortuga compliance agent address	Subject to timelock
ERC-3643 Identity Registry	Chain Fusion canister (threshold-signed) only	No direct write path from any other address
Freeze/unfreeze specific wallets	Issuer principal only	Documented justification required

# Full Compliance Data Flow

flowchart LR
    SUMSUB[SumSub KYC/AML] --> BACKEND[Issuer Backend]
    BACKEND --> KYC[ICP KYC Registry]
    KYC --> CF[Chain Fusion]
    CF --> ERC[ERC-3643 Identity Registry]
    ERC --> CHECK["canTransfer(from, to, amount)"]
    CHECK -->|All checks pass| EXEC[Transfer Executes]
    CHECK -->|Any check fails| REVERT[Transaction Reverts]