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

# Clone decisions

> What gets an EIP-1167 proxy and what does not, with the reasoning that decides each case.

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

## The rule

> **Clone what is deployed MANY times and called FEW times.
> Never clone what is deployed ONCE and called MANY times.**

A clone is a 45-byte signpost that says "the real code is over there." Deployment is cheap; every call pays an extra hop forever. The question is never whether the proxy is cheaper to deploy — it always is. The question is how many times it gets called.

## The decisions

| Artefact                                | Profile                                 | Decision                               |
| --------------------------------------- | --------------------------------------- | -------------------------------------- |
| **Forwarder, per invoice** (EVM + TRON) | deployed per invoice, called 1–2×       | **Clone**                              |
| **Pool** (EVM)                          | deployed once per chain, called forever | Do not clone                           |
| **Pool** (TRON)                         | deployed once, called forever           | **Do not clone** — reversed 2026-08-06 |
| **Forwarder, per customer**             | deployed once, called forever           | Do not clone                           |

## Why the hop costs what it costs

On EVM the overhead is 2,661 gas, and it is almost entirely **one cold account access** — EIP-2929 charges 2,600 the first time a transaction touches the implementation address, then 100 for subsequent touches.

That has a useful consequence: the tax is **per transaction, not per call**. Batching distribute and claim into one transaction means the second hop hits a warm implementation and costs about 161 rather than 2,661.

## Forwarder: clone, everywhere

The profile is exactly right — deployed per invoice, called once or twice.

| Forwarder, per invoice (TRON)            | Energy  | Cost at rent |
| ---------------------------------------- | ------- | ------------ |
| Full deploy + sweep (DEM-immune)         | 451,643 | \$14.79      |
| Clone, implementation calm               | 123,132 | \$4.03       |
| Clone, implementation at max DEM penalty | 307,817 | \$10.08      |

It wins even in the worst case, and saves 78% on EVM. **Proceed unconditionally.**

## Pool on EVM: do not clone

The crossover is 299 connect-rail payments, and it is **gas-price invariant** — both the saving and the tax scale with gwei, so "at high gas the clone wins" is false at every price.

But the economics are not what decides it. The saving is $0.07 on Ethereum and sub-cent on every L2; the customer tax is $0.0002 per payment. Both sides are noise. The tiebreakers are structural, and all four point the same way:

<AccordionGroup>
  <Accordion title="Cross-chain address identity becomes contingent">
    A clone's init code embeds the implementation address, so one pool address across seven chains would require the implementation at a byte-identical address on all seven. Today the pool address derives from merchant params, bytecode, salt, and factory — nothing external. Adding a dependency means any per-chain divergence silently breaks derivation for every merchant on that chain.
  </Accordion>

  <Accordion title="It is all-or-nothing">
    The saving is concentrated on Ethereum L1 and is rounding error elsewhere. Cloning only on Ethereum immediately diverges its pool address from the other six chains.
  </Accordion>

  <Accordion title="The trust story degrades">
    "Your pool *is* the audited contract" becomes "your pool is a proxy that delegates to a contract we deployed." Technically equivalent, but it is a paragraph of explanation instead of a fact, and the client-side re-derivation gains one more pinned constant that can drift.
  </Accordion>

  <Accordion title="More audit surface">
    Proxy pattern plus implementation plus two CREATE2 derivations, on seven chains instead of one.
  </Accordion>
</AccordionGroup>

## Pool on TRON: reversed

This was originally approved and was **reversed on 2026-08-06**. Three reasons, in order of weight.

### 1. The Dynamic Energy Model

TRON multiplies a contract's energy cost when *that contract* exceeds 5×10⁹ energy in a six-hour period, compounding to a **4.4× total multiplier**. There is no EVM equivalent.

<Danger>
  A full deploy creates a fresh contract with `energy_factor = 0`. Per-merchant pools are therefore **DEM-immune by construction**. A clone concentrates every merchant's usage onto one shared implementation.
</Danger>

A merchant's distribute-plus-claim goes from $4.91 to $21.61 at max factor. That is **+$16.70 per claim — the $27 deploy saving is erased after 1.6 claims**, permanently, because proxies are immutable and cannot be repointed. The threshold is reached at roughly 235,000 pool calls per day: a success problem, discovered at the worst possible moment.

### 2. It contradicts the merchant-paid pool gate

One issue treats TRON's $27 entry as a conversion wall to demolish. Another treats the pool deploy as "the little commitment that gates going live" — a deliberate anti-abuse filter on the chain where abuse costs most ($288,200 for 10,000 fake accounts). Cloning takes that gate from $27 to $2.37, weakening the exact mechanism the other issue was written to build.

Resolved in favour of the gate: **the \$27 stands, and it is deliberate.**

### 3. The 2,661 figure was an EVM number

TRON has **no EIP-2929** — the TVM hardfork matrix gates Constantinople, Istanbul, London, Shanghai, and Cancun, with no Berlin. The TVM opcode spec prices `DELEGATECALL` at 40 energy base. Realistic TVM overhead is around 150 energy, which would move the break-even from 310 to roughly 5,500 calls.

This finding argues *for* the clone. It is recorded because it is true, not because it changes the outcome — reason 1 dominates it.

## Per-customer forwarders invert the profile

Moving the forwarder from per-invoice to per-customer moves it from "deployed many, called few" into "deployed once, called forever" — the pool's profile, the one just rejected.

Crossover: `N* = (deploy_full − deploy_clone) / (sweep_clone − sweep_full)`

|                                 | Crossover          |
| ------------------------------- | ------------------ |
| EVM (2,661 overhead)            | **\~123 deposits** |
| TRON (\~150 overhead, DEM calm) | \~2,190 deposits   |
| TRON, DEM factor 0.5            | **12 deposits**    |
| TRON, DEM factor 3.4            | **1.8 deposits**   |

Per-customer addresses are the highest-traffic delegatecall target the system would ever have — every sweep of every customer of every merchant through one implementation.

**Resolution: a different forwarder per rail.** Cloned for per-invoice, full-deploy for per-customer. They already use different CREATE2 salts, so this costs nothing structurally beyond a second implementation to audit and a second predictor to keep byte-identical in the browser.

## Who pays the clone tax

Worth stating plainly, because it is easy to get backwards.

| Party    | What they pay                              | Effect                                                     |
| -------- | ------------------------------------------ | ---------------------------------------------------------- |
| Merchant | Tax only on their own distribute and claim | Saves the deploy, pays \~\$1/year — break-even 23–24 years |
| Customer | The tax on each connect-rail `deposit()`   | Pays from payment one, never sees a saving                 |
| Platform | Only the rare backstop distribute          | Effectively zero                                           |

The aggregate crossover of \~300 calls is a **social** number that no single party experiences. It is the wrong figure to decide with — but it is the right figure for judging whether the system as a whole is wasting money, which is why the EVM pool clone is still refused.