# Architecture Overview

Tortuga is a regulated real estate tokenization platform. The investor-facing layer is ERC-3643 permissioned security tokens on Plume, Base, and Canton. The Internet Computer serves as the canonical compliance authority and settlement ledger. Chain Fusion synchronizes compliance state from ICP to EVM natively, without bridges or wrapped tokens.

# Design Principles

Principle	Implementation
Single Source of Truth	Master Ledger on ICP holds canonical state
No Bridges	Chain Fusion uses threshold signatures, not wrapped tokens
Compliance First	KYC enforced at protocol level, not application level
Chain Agnostic	Investors choose their preferred chain
Live Chains	Plume (RWA-native L2), Base (Coinbase L2), Canton (institutional permissioned chain)

# High-Level Architecture

flowchart TB
    subgraph ICP["Internet Computer"]
        ML[Master Ledger]
        KYC[KYC Registry]
        YLD[Yield Distributor]
        CF[Chain Fusion Orchestrator]
    end

    subgraph Token["Token Layer"]
        ERC3643[ERC-3643 Tokens]
    end

    subgraph External["Live Chains"]
        PLUME[Plume]
        BASE[Base]
        CANTON[Canton]
    end

    subgraph Roadmap["Roadmap"]
        SOL[Solana Programs]
        COSM[Cosmos Modules]
    end

    subgraph Infra["Infrastructure"]
        SUMSUB[Sumsub KYC]
        ISSUER[Issuer Backend]
    end

    SUMSUB --> KYC
    ISSUER --> ML
    KYC --> ML
    ML <--> CF
    CF <--> ERC3643
    ERC3643 --> PLUME
    ERC3643 --> BASE
    ERC3643 --> CANTON
    ML --> YLD

    INVESTOR[Investor Wallet] --> PLUME
    INVESTOR --> BASE
    INVESTOR --> CANTON

# Component Overview

# Master Ledger

The canonical record of all tokenized bonds, holder balances, and transaction history. All cross-chain state ultimately syncs back here.

# Chain Fusion

ICP's native cross-chain technology using threshold cryptography. Enables direct signing of transactions on external chains without bridges or wrapped tokens.

# Cross-Chain Operations

Technical flows for minting, burning, and transferring tokens across chains. Includes signature schemes and message formats.

# Compliance Layer

ICP-to-EVM compliance synchronization via Chain Fusion. ERC-3643 enforcement architecture.

# Yield Distribution

USDC coupon distribution mechanics, holder snapshots, batched on-chain payments.

# DeFi Integration

Morpho Blue collateral lending architecture and curator model.

# Compliance Architecture Summary

The ICP KYC Registry is the authoritative compliance record for all verified investor identities and wallet whitelist status. Chain Fusion propagates whitelist state to the ERC-3643 Identity Registry on each live chain (Plume, Base, Canton) via threshold-signed transactions. Transfer compliance is therefore enforced natively on EVM without a live ICP dependency at transfer time — but ICP remains the single source of truth. See compliance-layer.md for the full architecture.

# Live Networks

Chain	Type	Rationale
Plume	RWA-native EVM L2	Purpose-built for real-world asset tokenization; deliberate positioning within the RWA ecosystem
Base	Coinbase EVM L2	Broad crypto-native capital pool access via Coinbase's distribution and liquidity infrastructure
Canton	Institutional permissioned blockchain	Used by major financial institutions (Goldman Sachs, BNP Paribas); signals institutional distribution intent

# Data Flow

flowchart LR
    subgraph Issuance
        BOND[Bond Created]
        META[Metadata Stored]
        MINT_ICP[Mint on ICP]
    end

    subgraph Distribution
        KYC_CHECK[KYC Verified]
        CHAIN_SEL[Chain Selected]
        MINT_EXT[Mint on External Chain]
    end

    subgraph Operations
        TRANSFER[Transfers]
        YIELD[Yield Payments]
        REDEEM[Redemption]
    end

    BOND --> META --> MINT_ICP
    MINT_ICP --> KYC_CHECK --> CHAIN_SEL --> MINT_EXT
    MINT_EXT --> TRANSFER
    MINT_EXT --> YIELD
    MINT_EXT --> REDEEM

# Security Model

All cross-chain operations require multiple security checks:

flowchart TB
    REQ[Operation Request] --> V1[KYC Verification]
    V1 --> V2[Balance Check]
    V2 --> V3[Compliance Rules]
    V3 --> SIGN[Threshold Signature]
    SIGN --> EXEC[Execute on Target Chain]
    EXEC --> CONFIRM[Confirmation]
    CONFIRM --> UPDATE[Update Master Ledger]

Key security properties:

Threshold Signatures: No single node can sign transactions
Consensus Required: ICP subnet consensus before any cross-chain action
Immutable Audit Log: All operations recorded on master ledger
KYC Enforcement: Protocol-level, not bypassable

# Network Topology

flowchart TB
    subgraph ICP_SUBNET["ICP Subnet"]
        N1[Node 1]
        N2[Node 2]
        N3[Node 3]
        N4[Node N...]
    end

    subgraph CANISTERS["Tortuga Canisters"]
        C1[Master Ledger]
        C2[KYC Registry]
        C3[Chain Fusion]
    end

    N1 & N2 & N3 & N4 --> CANISTERS

    C3 --> ETH[Ethereum]
    C3 --> BASE[Base]
    C3 --> SOL[Solana]
    C3 --> OSMO[Osmosis]

Canisters run on a dedicated ICP subnet with nodes distributed globally for fault tolerance and decentralization.

For the token lifecycle (minting, distribution, yields, redemption), see the Token Lifecycle section.

For identity verification and KYC binding, see Identity & KYC.

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

For chain-specific deployment details, see Supported Chains.