# Chain Fusion

Chain Fusion is the Internet Computer's native cross-chain technology that enables Tortuga to manage tokens across multiple blockchains without bridges or wrapped tokens.

# Overview

Traditional cross-chain solutions rely on bridges with trusted operators or wrapped tokens. Chain Fusion eliminates these by using threshold cryptography to sign transactions directly on external chains.

flowchart LR
    subgraph Traditional Bridge
        A1[Chain A] --> B1[Bridge Contract]
        B1 --> W1[Wrapped Token]
        W1 --> C1[Chain B]
    end

    subgraph Chain Fusion
        A2[ICP Master Ledger] --> T2[Threshold Signature]
        T2 --> N2[Native Token on Chain B]
    end

Approach	Trust Model	Token Type	Risk
Traditional Bridge	Trusted operators	Wrapped	Bridge hack, operator key compromise
Chain Fusion	ICP consensus	Native	Requires ICP subnet compromise

# How It Works

# Threshold Signatures

ICP nodes collectively hold cryptographic keys using threshold cryptography. No single node has the full private key.

flowchart TB
    subgraph ICP Subnet
        N1[Node 1<br/>Key Share 1]
        N2[Node 2<br/>Key Share 2]
        N3[Node 3<br/>Key Share 3]
        N4[Node N<br/>Key Share N]
    end

    N1 & N2 & N3 & N4 --> THRESH[Threshold Signature Protocol]
    THRESH --> SIG[Valid Signature]
    SIG --> TX[Signed Transaction]

Threshold: For a subnet with N nodes, at least 2/3 must participate to create a valid signature.

# Chain-Key Cryptography

ICP supports multiple signature schemes for different chains:

Chain	Signature Scheme	ICP Feature
EVM (Ethereum, Base, etc.)	ECDSA (secp256k1)	Threshold ECDSA
Solana	EdDSA (Ed25519)	Threshold Schnorr
Cosmos	ECDSA (secp256k1)	Threshold ECDSA
Bitcoin	ECDSA (secp256k1)	Threshold ECDSA

# Architecture

flowchart TB
    subgraph Chain Fusion Canister
        ORCH[Orchestrator]
        QUEUE[TX Queue]
        KEYS[Key Management]
        MONITOR[Chain Monitors]
    end

    subgraph External Integrations
        EVM_INT[EVM Integration]
        SOL_INT[Solana Integration]
        COSM_INT[Cosmos Integration]
    end

    ML[Master Ledger] <--> ORCH
    ORCH --> QUEUE
    QUEUE --> KEYS
    KEYS --> EVM_INT & SOL_INT & COSM_INT

    MONITOR --> EVM_INT & SOL_INT & COSM_INT

# Components

Component	Responsibility
Orchestrator	Coordinate cross-chain operations
TX Queue	Order and batch pending transactions
Key Management	Derive and manage chain-specific keys
Chain Monitors	Watch external chains for events
Chain Integrations	Chain-specific TX building and submission

# Key Derivation

Tortuga uses deterministic key derivation to manage keys for each supported chain:

flowchart TB
    MASTER[ICP Master Key] --> DERIVE[Derivation Path]

    DERIVE --> EVM_KEY[EVM Key<br/>secp256k1]
    DERIVE --> SOL_KEY[Solana Key<br/>Ed25519]
    DERIVE --> COSM_KEY[Cosmos Key<br/>secp256k1]

    EVM_KEY --> ETH_ADDR[Ethereum Address]
    EVM_KEY --> BASE_ADDR[Base Address]
    SOL_KEY --> SOL_ADDR[Solana Address]
    COSM_KEY --> OSMO_ADDR[Osmosis Address]

# Derivation Paths

Master Key
├── m/44'/60'/0'/0  → EVM chains (shared key)
│   ├── Ethereum: 0x...
│   ├── Base: 0x...
│   └── Arbitrum: 0x...
├── m/44'/501'/0'/0 → Solana
│   └── Solana: ...
└── m/44'/118'/0'/0 → Cosmos chains
    ├── Osmosis: osmo1...
    └── Cosmos Hub: cosmos1...

# Transaction Lifecycle

# Outbound Transaction (ICP → External)

sequenceDiagram
    participant ML as Master Ledger
    participant CF as Chain Fusion
    participant SUBNET as ICP Subnet
    participant EXT as External Chain

    ML->>CF: Request Mint (user, amount, chain)
    CF->>CF: Validate & Queue TX
    CF->>CF: Build Raw Transaction
    CF->>SUBNET: Request Threshold Signature
    SUBNET->>SUBNET: Nodes compute signature shares
    SUBNET-->>CF: Aggregated Signature
    CF->>EXT: Submit Signed Transaction
    EXT-->>CF: TX Hash
    CF->>CF: Monitor for Confirmation
    EXT-->>CF: Confirmed (N blocks)
    CF->>ML: Confirm Success

# Inbound Event (External → ICP)

sequenceDiagram
    participant EXT as External Chain
    participant CF as Chain Fusion
    participant ML as Master Ledger

    Note over CF: Continuous monitoring
    CF->>EXT: Poll for events
    EXT-->>CF: Burn Event Detected
    CF->>CF: Verify event authenticity
    CF->>CF: Wait for finality
    CF->>ML: Report Burn (user, amount)
    ML->>ML: Update balances

# Chain Monitors

Chain Fusion canisters monitor external chains for relevant events:

# EVM Monitor

type EvmEvent = record {
    contract : Text;        // Token contract address
    event_type : EvmEventType;
    block_number : nat64;
    tx_hash : Text;
    log_index : nat32;
    data : blob;
};

type EvmEventType = variant {
    Transfer;
    Burn;
    Mint;
};

# Monitoring Configuration

Chain	Block Time	Finality	Poll Interval
Ethereum	~12s	12 blocks (~2.4 min)	15s
Base	~2s	12 blocks (~24s)	5s
Solana	~400ms	32 slots (~12s)	2s
Osmosis	~6s	1 block	10s

# Canister Interface

candid
service : {
    // Request mint on external chain
    request_mint : (MintRequest) -> (Result<RequestId, Error>);

    // Request burn on external chain (returns tokens to ICP)
    request_burn : (BurnRequest) -> (Result<RequestId, Error>);

    // Get request status
    get_request_status : (RequestId) -> (RequestStatus) query;

    // Get derived address for a chain
    get_chain_address : (Chain) -> (Text) query;

    // Get pending transactions
    get_pending_txs : () -> (vec PendingTx) query;

    // Manual retry for stuck transaction (admin only)
    retry_transaction : (RequestId) -> (Result<(), Error>);
}

type MintRequest = record {
    token_id : TokenId;
    recipient : Text;       // Chain-specific address
    amount : nat;
    target_chain : Chain;
};

type BurnRequest = record {
    token_id : TokenId;
    amount : nat;
    source_chain : Chain;
    tx_hash : Text;         // External chain TX hash
};

type RequestStatus = variant {
    Pending;
    Signing;
    Submitted : Text;       // TX hash
    Confirmed : nat64;      // Block number
    Failed : Text;
};

# Error Handling & Recovery

# Failure Scenarios

flowchart TB
    START[TX Request] --> SIGN{Signing}
    SIGN -->|Success| SUBMIT{Submit to Chain}
    SIGN -->|Timeout| RETRY1[Retry Signing]
    RETRY1 --> SIGN

    SUBMIT -->|Success| CONFIRM{Wait Confirmation}
    SUBMIT -->|Failed| RETRY2[Retry Submit]
    RETRY2 --> SUBMIT

    CONFIRM -->|Confirmed| DONE[Complete]
    CONFIRM -->|Reorg| RESUBMIT[Resubmit TX]
    RESUBMIT --> SUBMIT
    CONFIRM -->|Timeout| ESCALATE[Manual Review]

# Recovery Mechanisms

Failure	Recovery
Signing timeout	Automatic retry (3x)
TX submission failed	Retry with adjusted gas
TX stuck in mempool	Replace with higher fee
Chain reorg	Detect and resubmit
Extended outage	Queue for manual review

# Gas Management

# EVM Chains

type GasConfig = record {
    base_gas : nat64;
    priority_fee : nat64;
    max_fee : nat64;
    gas_limit : nat64;
};

Chain Fusion maintains gas tokens on each chain:

flowchart LR
    TREASURY[Gas Treasury] --> ETH[ETH for Ethereum]
    TREASURY --> ETH_BASE[ETH for Base]
    TREASURY --> SOL[SOL for Solana]
    TREASURY --> OSMO[OSMO for Osmosis]

# Fee Estimation

Operation	Estimated Gas (EVM)	Estimated Cost
Mint	~65,000	~$0.50-5.00
Burn	~45,000	~$0.35-3.50
Transfer	~55,000	~$0.40-4.00

Costs vary by chain and network conditions