Skip to main content
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

​
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. 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.07onEthereumandsub−centoneveryL2;thecustomertaxis0.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:
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.
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.
“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.
Proxy pattern plus implementation plus two CREATE2 derivations, on seven chains instead of one.

​
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.
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.
A merchant’s distribute-plus-claim goes from 4.91to4.91 to 21.61 at max factor. That is +16.70perclaim—the16.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 27entryasaconversionwalltodemolish.Anothertreatsthepooldeployas"thelittlecommitmentthatgatesgoinglive"—adeliberateanti−abusefilteronthechainwhereabusecostsmost(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 27to27 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) 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. 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.