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

# Connect rail

> The customer signs a deposit directly into the merchant's pool and pays their own gas.

The customer connects a wallet and signs one transaction: `MerchantPool.deposit(paymentId, token, amount)`. Funds go straight into the pool. The platform touches nothing.

## Properties

|                          |                                                                                     |
| ------------------------ | ----------------------------------------------------------------------------------- |
| Who pays gas             | The customer                                                                        |
| Platform cost            | Zero — no floor on any chain                                                        |
| Requires a deployed pool | **Yes.** `deposit()` is a contract call and reverts against an address with no code |
| Capture point            | When the `deposit()` transaction reaches required confirmations                     |
| Reversible               | No, once confirmed                                                                  |
| Attribution              | Exact — `paymentId` is an indexed event parameter                                   |

Because the platform fronts nothing, `platformFloor(chainId, "connect")` returns `0` on every chain. This makes the connect rail the correct destination for any payment too small to justify the deposit rail's sponsored gas.

## Flow

<Steps>
  <Step title="Quote">
    `create-quote` prices the order and returns the token amount. The pool address is derived and returned with a binding bundle the client re-proves.
  </Step>

  <Step title="Verify before signing">
    The widget reads `MerchantRegistry.effectiveRecipient(anchor)` on-chain, re-derives the pool address from that chain-read value, and cross-checks the deployed pool's `recipient()`. Any mismatch produces a terminal `pool_mismatch` state and signing is blocked. See [DB-display-only trust](/trust/db-display-only).
  </Step>

  <Step title="Approve and deposit">
    Standard ERC-20 approval followed by `deposit()`. On TRON this will be `MerchantPoolTron.deposit()` once the connect rail lands there.
  </Step>

  <Step title="Confirm">
    The indexer observes the `Deposited` event. Capture is at required confirmations — not first-seen.
  </Step>
</Steps>

## Recipient race protection

Between quoting and signing, the on-chain recipient could change. The widget re-reads `effectiveRecipient` immediately before the signature. On mismatch it enters a `recipient_changed` state with a calm warning and a refresh action, and no signature is sent.

## Wallet coverage

EVM coverage comes through Reown AppKit. AppKit's built-in Swaps widget is disabled (`swaps: false`) because no aggregator may sit in the trust path.

TRON is a separate stack. The WalletConnect-TRON connector ships via `@tronweb3/walletconnect-tron`, not a first-party Reown adapter. Verified over standard WC-TRON: TokenPocket, Trust Wallet, Binance Web3, SafePal. OKX requires its own OKX Connect protocol. Bitget is unverified. Injected TronLink remains a parallel path.

## TRON status

<Warning>
  TRON does **not** have a connect rail today. `railEconomics.ts:availableRails()` hard-returns `["deposit"]` for TRON, making it the only chain where a customer cannot pay from a connected wallet.
</Warning>

GO was given 2026-08-05. The target is `MerchantPoolTron.deposit()` **direct** — explicitly not a WalletConnect-signed plain transfer to a forwarder, which would still require a keeper deploy and sweep and therefore save nothing.

Most of the plumbing exists: `MerchantPoolTron.deposit()` is implemented and `tron-pool-keeper` already handles `rail === "connect"` and observes `Deposited` events. The gap is the widget.

This matters more on TRON than anywhere else. Every deposit-rail optimisation still leaves a floor; only the connect rail removes it, because the customer's own wallet pays the energy.

| TRON path                   | Platform cost per payment | Break-even order |
| --------------------------- | ------------------------- | ---------------- |
| Deposit rail, burn (today)  | \$14.74                   | \$1,965          |
| Deposit rail, rented energy | \$6.03                    | \$804            |
| Deposit rail, rent + clone  | \$1.81                    | \$241            |
| **Connect rail**            | **\$0**                   | **no floor**     |

The honest customer-side trade on TRON: approve plus deposit costs roughly $2.40 versus about $1.40 for a plain transfer. TRON users already expect \$1–3 per USDT transfer, so this is tolerable, and a `consume_user_resource_percent` spike may remove it entirely.