> ## 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.

# Who pays what

> Three cost points, three different payers, and the live numbers for each. The map to read before any economics discussion.

Spec: `docs/superpowers/specs/2026-08-06-deposit-rail-gas-economics.md`.

## The governing rule

> The platform fronts nothing it does not recover, and never holds anything back.

The keeper fronts deposit-rail sweep gas so money settles whether or not the merchant is awake, then recovers it as a bounded fee inside `distribute()`. It never gains the ability to withhold merchant funds.

## Three cost points

| # | Cost                | Frequency           | Payer        | Mechanism                                            | Ethereum | TRON        |
| - | ------------------- | ------------------- | ------------ | ---------------------------------------------------- | -------- | ----------- |
| 1 | Pool deploy         | Once per chain      | **Merchant** | Signs and pays native                                | \~\$0.07 | **\$29.37** |
| 2 | Forwarder + sweep   | Per invoice         | **Merchant** | Keeper fronts, recovered in stablecoin at distribute | \$0.0097 | \$1.84      |
| 3 | Distribute + claim  | Per batch           | **Merchant** | Signs and pays native                                | \~\$0.01 | \~\$4.59    |
| — | Customer send fee   | Per order           | Customer     | Their wallet or exchange                             | —        | —           |
| — | Connect `deposit()` | Per connect payment | Customer     | Signs and pays native                                | —        | —           |

Only **#2** flows through the reimbursement mechanism. The merchant pays #1 and #3 directly in native gas.

Ethereum figures at 0.045 gwei with ETH at $1,885.85; TRON at TRX $0.3274 with the forwarder cloned and energy rented. Ethereum numbers scale linearly with gas price — at 50 gwei the same clone payment costs \$8.94.

## The flow, annotated

```
SETUP (once per chain)   merchant deploys their pool, signs + pays native gas
                         → unlocks SDK keys / embed snippet
      │
QUOTE                    live gas priced in; if cost exceeds the merchant's
                         tolerance %, the deposit rail is HIDDEN for that chain
                         and the connect rail is offered instead
      │
CUSTOMER PAYS            plain transfer / QR / CEX withdrawal → forwarder address
                         (CREATE2-derived and displayed at quote time; no code yet)
      │
SWEEP (per invoice)      keeper clones the forwarder + sweeps 100% → pool,
                         in ONE merged transaction. Platform fronts native gas
                         and writes a receipt with the USD cost snapshotted
                         AT SPEND TIME.
      │
CLAIM (per batch)        merchant presses Claim → one tx does distribute + claim.
                         Merchant pays that tx's native gas. Accrued gas debt is
                         carved from the merchant share.
                         Backstop: monthly conditional keeper distribute.
```

## The fact that shapes everything

<Info>
  **The deposit-rail sweep does not call the pool.** A forwarder sweep is a plain ERC-20 transfer, and `MerchantPool.sol` has no `receive`, `fallback`, or token hook. Deposit-rail volume generates **zero** pool calls.
</Info>

Pool calls come from exactly three places: connect-rail `deposit()` (the customer), `distribute()`, and `claim()`. This determines the [clone decisions](/economics/clone-decisions) and means a pure deposit-rail merchant touches their pool only a handful of times per month.

## What the optimisations buy

| Change                                                 | Effect on per-invoice cost                     |
| ------------------------------------------------------ | ---------------------------------------------- |
| EIP-1167 clone forwarder                               | 423,918 → **93,801 gas** (−78%)                |
| Merge deploy + initialize + sweep into one transaction | −21,000 intrinsic gas (two submits become one) |
| Rent TRON energy instead of burning                    | TRON only, −60% on the energy rate             |
| TRON forwarder clone                                   | 451,643 → **123,132 energy**                   |
| Strip `refund()` and reward code                       | Nothing per payment — see below                |

<Warning>
  Stripping code from the forwarder or pool does **not** reduce per-payment cost once cloning lands. An EIP-1167 proxy has a 45-byte runtime regardless of implementation size. The strip pays off on the one-time implementation deploy and on the merchant-paid pool deploy. It is bundled into the same cutover for address-migration reasons, not for per-payment savings.
</Warning>

## Live cost, one full deposit-rail order

Measured against live prices, 2026-08-03.

|                                           | Ethereum     | TRON           |
| ----------------------------------------- | ------------ | -------------- |
| Today (deploy + sweep, two transactions)  | \$0.0395     | \$15.01 (burn) |
| Clone + merged transaction / clone + rent | **\$0.0097** | **\$1.84**     |

TRON is **189× Ethereum** even after every planned optimisation. That gap does not close, which is why TRON drives nearly every economic decision in this section.

## Break-even, and why it stops mattering

At a 0.75% take rate, break-even order value is `gas ÷ take_rate`: about $1.30 on Ethereum and $245 on TRON post-optimisation.

Once the merchant bears the cost, the platform is whole at any order size and this floor **stops being loss protection**. It remains as a quality gate and as the live gas oracle, but its justification changes from "refuse or we lose money" to "refuse because the merchant said this is too expensive."

The binding constraint becomes the merchant's configured tolerance — a single percentage that, combined with the live gas figure, yields a per-chain minimum automatically, since `gas / order ≤ maxPct` is `order ≥ gas / maxPct`.

| Merchant sets | Implied minimum, Ethereum | Implied minimum, TRON |
| ------------- | ------------------------- | --------------------- |
| 1%            | \$0.97                    | \$184                 |
| 2%            | \$0.49                    | \$92                  |
| 5%            | \$0.19                    | \$37                  |

The UI must show the **implied minimum per chain** as the merchant moves the control. A percentage is abstract; the consequence is a payment method silently disappearing.