> ## Documentation Index
> Fetch the complete documentation index at: https://jephalabs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Venues & Transports

> CEX lanes, bridge lanes, and how to combine them

# Venues & Transports

QTG supports two families of transfer lanes: **CEX lanes** for exchange-to-exchange transfers, and **Bridge lanes** for on-chain cross-chain transfers. Each lane compiles into a specific DAG shape with a known number of steps. You can combine lanes into multi-hop routes when a single lane cannot reach the destination.

## CEX Lane

A CEX lane moves funds between two exchange accounts using the exchanges' own withdrawal and deposit infrastructure. Every CEX transfer compiles into the same 3-node pipeline:

```mermaid theme={null}
flowchart LR
    W["Withdraw"] --> WO["Observe\nWithdrawal"]
    WO --> DO["Observe\nDeposit"]

    style W fill:#2563eb,stroke:#1d4ed8,color:#fff
    style WO fill:#6366f1,stroke:#4f46e5,color:#fff
    style DO fill:#8b5cf6,stroke:#7c3aed,color:#fff
```

1. **Withdraw** -- QTG calls the source exchange's withdrawal API with the destination address, amount, and any required fields (memo, network, travel rule data).
2. **Observe Withdrawal** -- QTG polls the source exchange until the withdrawal is confirmed as sent. This catches rejections, holds, and AML review states.
3. **Observe Deposit** -- QTG polls the destination exchange until the deposit arrives and is credited. The transfer is not marked complete until the funds are confirmed on the receiving side.

<Tip>
  The 3-node pipeline means QTG tracks both sides of the transfer. If an exchange holds a withdrawal for review, you will see it in the observe step rather than wondering where the funds went.
</Tip>

### Supported CEX Venues

| Venue    | Status | Notes                                                                                                 |
| -------- | ------ | ----------------------------------------------------------------------------------------------------- |
| Upbit    | Live   | Korean venue. Beneficiary fields required for KR compliance.                                          |
| Binance  | Live   | Master-signed sub-account balance and capital transfers supported.                                    |
| Coinbase | Live   | Advanced Trade API. Address-scoped deposit observation.                                               |
| Bybit    | Live   | Requires internal transfer from Unified Trading to Funding before withdrawal.                         |
| OKX      | Live   | KR travel-rule (`walletType=exchange` + `exchId`) and private-wallet paths both exercised on mainnet. |

### Exchange-Specific Considerations

Different exchanges have different quirks that QTG handles transparently:

* **Korean venues** (Upbit, OKX) require travel rule fields: exchange name, receiver type, and receiver names in Korean and English.
* **Binance sub-accounts** are signed through the master account's API key. QTG never holds sub-account trading keys.
* **Bybit** requires a manual internal transfer from the Unified Trading wallet to the Funding wallet before QTG can initiate a withdrawal. This is a Bybit platform requirement, not a QTG limitation.

## Bridge Lane

A Bridge lane moves funds across blockchains using an on-chain protocol. Unlike CEX lanes where the exchange handles custody, bridge lanes require QTG to sign and broadcast transactions using your KMS key.

### CCTP (Cross-Chain Transfer Protocol)

CCTP is Circle's native USDC bridge. It compiles into a 5-node pipeline:

```mermaid theme={null}
flowchart LR
    B["Burn"] --> A["Attest"]
    A --> M["Mint"]
    M --> RO["Observe\nReceipt"]
    RO --> FO["Observe\nFinality"]

    style B fill:#059669,stroke:#047857,color:#fff
    style A fill:#0d9488,stroke:#0f766e,color:#fff
    style M fill:#0891b2,stroke:#0e7490,color:#fff
    style RO fill:#0284c7,stroke:#0369a1,color:#fff
    style FO fill:#0284c7,stroke:#0369a1,color:#fff
```

1. **Burn** -- QTG signs and submits a USDC burn transaction on the source chain via your KMS.
2. **Attest** -- QTG waits for Circle's attestation service to confirm the burn.
3. **Mint** -- QTG submits the mint transaction on the destination chain using the attestation proof.
4. **Observe Receipt** -- QTG confirms the destination address actually received the USDC, matching amount and token contract.
5. **Observe Finality** -- QTG waits for the mint transaction to reach finality.

CCTP is live on mainnet (Base, Arbitrum) with V2 support.

### CCIP (Chainlink CCIP)

CCIP is a Free bridge lane for cross-chain token transfers signed via KMS. It runs through a sidecar client when `MG_CCIP_ENABLED` is set.

### USDT0 / LayerZero

USDT0 is a Free bridge lane built on LayerZero V2's OFT standard. QTG signs and broadcasts the OFT send transaction via KMS, then observes destination delivery. It is enabled with `MG_USDT0_ENABLED`.

### Circle Gateway

Circle Gateway provides a managed deposit and transfer flow through Circle's infrastructure. Live with balance and movement tests.

### Hyperliquid

Hyperliquid transfers use CCTP-backed mainnet topup and drain flows, signed via KMS. This is how you move funds into and out of Hyperliquid's L1 from EVM chains.

### Stargate (Pro)

Stargate is a **Pro** bridge lane. It is part of the Pro package, enabled through Pro configuration, and is not part of the Free distribution.

### Bridge Lane Summary

| Transport         | Tier | Status    | Notes                                                                                     |
| ----------------- | ---- | --------- | ----------------------------------------------------------------------------------------- |
| CCTP              | Free | Live      | V2 mainnet Base and Arbitrum. KMS-signed burn, attestation, and mint.                     |
| CCIP              | Free | Available | Chainlink CCIP via sidecar (`MG_CCIP_ENABLED`).                                           |
| USDT0 / LayerZero | Free | Available | LayerZero V2 OFT send, KMS-signed (`MG_USDT0_ENABLED`).                                   |
| Circle Gateway    | Free | Live      | Balance and movement tests.                                                               |
| Hyperliquid       | Free | Live      | CCTP-backed mainnet topup and drain via KMS.                                              |
| Stargate          | Pro  | Available | Part of the Pro package, enabled through Pro configuration; excluded from the Free build. |

## Choosing the Right Lane

| Scenario                                          | Recommended Lane           | Why                                                               |
| ------------------------------------------------- | -------------------------- | ----------------------------------------------------------------- |
| Exchange to exchange (e.g., Upbit to Binance)     | CEX                        | Direct withdrawal/deposit. Fastest, cheapest for supported pairs. |
| Chain to chain (e.g., Base USDC to Arbitrum USDC) | CCTP Bridge                | Native USDC bridge. No slippage.                                  |
| Exchange to chain (e.g., Binance to Base)         | CEX withdrawal             | Most exchanges support direct chain withdrawal.                   |
| Chain to exchange (e.g., Arbitrum to Upbit)       | Depends on deposit support | Check if the exchange accepts deposits on that chain.             |

## Multi-Hop Routes

Some transfers require combining lanes. For example, moving USDC from Upbit to Hyperliquid might require:

1. **CEX lane**: Withdraw USDC from Upbit to Arbitrum
2. **Bridge lane**: Topup Hyperliquid from Arbitrum via CCTP

QTG templates can express multi-hop routes as a single DAG. The nodes execute in dependency order -- the bridge step waits for the CEX withdrawal to complete before starting.

```mermaid theme={null}
flowchart LR
    subgraph CEX["CEX Lane"]
        W["Withdraw\n(Upbit)"] --> WO["Observe\nWithdrawal"]
    end
    subgraph Bridge["Bridge Lane"]
        WO --> B["Bridge\n(CCTP)"]
        B --> BO["Observe\nFinality"]
    end

    style W fill:#2563eb,stroke:#1d4ed8,color:#fff
    style WO fill:#6366f1,stroke:#4f46e5,color:#fff
    style B fill:#059669,stroke:#047857,color:#fff
    style BO fill:#0d9488,stroke:#0f766e,color:#fff
```

<Note>
  For the full executor architecture and implementation details, see [Executors Overview](/reference/executors/overview). For details on the CEX 3-node pipeline internals, see [CEX Lane](/reference/executors/cex-lane). For bridge lane internals, see [CCTP Lane](/reference/executors/bridges/cctp-lane) and [CCIP Bridge](/reference/executors/bridges/ccip-bridge). The Stargate (Pro) lane is documented separately in the Pro reference.
</Note>