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

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;TRONatTRX1,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

​
The fact that shapes everything

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.
Pool calls come from exactly three places: connect-rail deposit() (the customer), distribute(), and claim(). This determines the clone decisions and means a pure deposit-rail merchant touches their pool only a handful of times per month.

​
What the optimisations buy

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.

​
Live cost, one full deposit-rail order

Measured against live prices, 2026-08-03. 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.30onEthereumand1.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. 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.