docs: design for supporting deposits from CEX (DEFI-2096)

[gregorydemay]

Design doc for DEFI-2096: allow onramping ckUSDC/ckUSDT (and generally any ckERC20, later ckETH) directly from a centralized exchange withdrawal.

Deposits currently require calling the helper smart contract, which a CEX cannot do: a CEX withdrawal is a plain transfer from a shared hot wallet, carrying no IC principal. The proposed design gives each IC account a unique tECDSA-derived deposit address and sweeps funds to the minter using EIP-7702 (Pectra), so deposit addresses never need ETH for gas and remain key-recoverable independently of any contract code.

The doc covers the requirements, claim-based deposit detection, the sweeper delegate, fee model, a phased delivery (ckERC20 first, then ckETH with its balance-based detection and fixed-21k-gas constraints), and the discussed alternatives (CREATE2 forwarders, ERC-4337, permit-based sponsoring).

The runnable proof-of-concept the doc references lives in a stacked follow-up, #10670.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds a design document describing how to support ckERC20 (and later ckETH) deposits directly from centralized exchanges by assigning each IC account a deterministic tECDSA-derived deposit address and sweeping funds to the minter using EIP-7702.

Changes:

• Introduces a new design doc covering motivation, requirements, and phased rollout (ckERC20 first, then ckETH).
• Specifies claim-based deposit detection, sweeping/delegation flow, fee model, and a test plan.
• Documents considered alternatives (CREATE2 forwarders, ERC-4337, permit-based approaches) and rationale.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to 3e7dc19.

Security Overview

• 🔎 Scanned files: 1 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/783a9bd4-fb4e-4e10-ab3c-c2fb2ddfb92f?scanId=a23d3511-6ac9-46de-95f1-56d1c72ee38c&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Other relevant categories	► rs/ethereum/cketh/docs/deposit_from_cex.md     Add comprehensive documentation for depositing from CEX via per-account deposit addresses (EIP-7702 sweeping)

[mbjorkqvist]

Thanks @gregorydemay! I have mostly clarifying questions.

[mbjorkqvist]

nit: The numbering jumps from R10 to R13 (R11 and R12 are in "Phase 2" below).

[gregorydemay]

🤖 Good catch. The requirements are grouped by phase rather than numbered sequentially (R11/R12 are Phase 2); renumbering would ripple through dozens of R-references across the doc, so instead I added a one-line note under the Phase 1 heading clarifying this. Done in 8c33a9d.

[mbjorkqvist]

Is "registered deposit addresses" listing them all, or a count? Does the minter store something per (principal, subaccount), in which case there could be a potential DoS attack if someone e.g., asks for lots of deposit addresses.

[gregorydemay]

This we will refine as we go, the dashboard is not that critical. For the DoS see the comments below.

[mbjorkqvist]

This part about registrations (partially) answers my earlier question(s). Can we do something to limit our exposure? E.g., rate limit registrations per principal (in inspect_message?), or something else?

[gregorydemay]

yes, I plan to do something similar as what was planed to do for ckSOL: an address as a limited time window (say 24h) and a limited amount of cycles to reach a deposit.

[mbjorkqvist]

I could imagine that one use case would involve users depositing to the same address (same (principal, subaccount)) multiple times, but perhaps days apart. For the first deposit, I assume a user would click a "get deposit address" button somewhere (in OISY, or in the MULTI/DEX), which would trigger a call to deposit_erc20 to derive the address (and open the scanning window). However, if the user then simply reuses that address (maybe stored in their address book in a CEX) for a subsequent deposit a week later, they may be confused as to why their deposit is not arriving. Is there something that could be done to improve this flow (other than a reminder/note next to the button the user initially pressed)?

[gregorydemay]

We could alleviate the problem by making Multicall3 /eth_call to fetch the ERC-20 balances of multiple addresses with a single HTTPs outcall (in the order of 1000s addresses). The limit there will probably the max response size of 2MB and this is per token but this would mean keep making HTTPs outcalls forever as soon as someone called the deposit endpoint. I would say let's me conservative now, and if this is a problem we can always throw more cycles at it.

[mbjorkqvist]

R7 says the fee covers the "amortized sweep gas cost", but two costs aren't captured:

1. Detection cycles. The background scan (step 3) spends cycles on every armed address whether or not a deposit arrives. At current mainnet gas (~0.1 gwei) a sweep is ~$0.017, while scanning one address for a full window is ~$0.02–0.03 in cycles — i.e. detection currently costs more than the sweep. The fee floor should be solved against detection + sweep, not sweep alone.
2. Currency mismatch. deposit_fee accrues in the deposited ckToken, but sweep gas is spent in ckETH (from the fee account) and detection in cycles. "Fees cover gas" only holds after the out-of-band treasury conversion noted in Non-goals — worth making explicit here.

[gregorydemay]

Yes the costs are currently not clear enough. Basically each address would get a cycle budget to account for

1. signatures
2. HTTPs outcalls

Once we have a better understanding of those cost, these will translate into a fee that will be taken by the minter. The currency mismatch is currently outscoped, but should be do able with OISY TRADE.

[mbjorkqvist]

The window is defined as a cycles budget per tick, but the tick cadence is left unspecified ("bounded by cost rather than wall time" bounds total cost but not detection latency — how fast the budget is spent). Two concrete additions worth pinning down (also relevant to the cadence/DoS questions on the sweep side above):

• Schedule. A CEX withdrawal usually lands within minutes, so a backoff cadence (e.g. every 30s for 0–10 min, every 2 min to 30 min, every 5 min to 60 min ≈ 36 ticks) covers the likely-arrival window with ~40% fewer calls than a flat 1/min (60 ticks).
• Cost. Detection goes through the EVM-RPC canister on the 34-node fiduciary subnet × 3 providers: base ≈ 0.8B cycles/call ($0.0011) plus byte terms (~$0.0003/req-byte, ~$0.0001/resp-byte; 1T cycles = 1 XDR ≈ $1.37). A balanceOf tick over the active set is ~$0.0003–0.0005 per address per tick, so a full 60-min window is ~$0.017–0.03 per address (T≈3–5 tokens).

Key economic point: detection cycles are spent on every armed address whether or not a deposit ever arrives, but the fee is only collected on successful deposits — so empty/abandoned windows are pure minter loss. cap × per-address-budget is the real bound (e.g. 256 addrs × ~15B cycles ≈ 3.8T cycles ≈ $5.25 to re-arm the whole set once). Stating concrete cap / budget / cadence values would let the fee floor and the DoS ceiling both be solved explicitly.

[gregorydemay]

Ethereum blocks are produced every 12s, so something like 30s, 1min, 2 min, 4min,... seems to make sense the exact schedule is dependent of the cost calculation

[mbjorkqvist]

Worth surfacing at requirement level, not just in this cell's cons: because variant B mints from the sweep's helper event, crediting is coupled to sweeping. A gas spike or an empty ckETH fee account halts not just sweeps but all new ckERC20 CEX crediting (funds stay safe at key-controlled addresses, but new deposits stop being credited until the fee account is topped up / gas subsides). R5's "a sweep delay never affects already-minted balances" holds for already-minted balances, but new deposits stall — this is the main operational cost of choosing B.

[gregorydemay]

🤖 A Cost estimation section quantifying variant B’s operational cost was added in 3e7dc19 (tECDSA + outcalls + gas across four scenarios). The crediting-coupled-to-sweeping point you raise is called out today in step 0 (“under variant B, crediting pauses with sweeping”) and in the variant-B cons cell; elevating it to an explicit requirement/non-goal is still open and a good follow-up.

[mbjorkqvist]

age > max_age is effectively R5's liveness net: it fires when unswept_value never crosses the economic threshold on its own — chiefly during gas spikes (which inflate sweep_gas_cost × margin above the deposit value) or for a lone below-margin balance waiting to be batched. Two notes:

• Under decided variant B this also bounds crediting latency, not just consolidation: since the mint follows the sweep, a below-margin deposit isn't credited until age > max_age forces the sweep. So max_age is the worst-case "my ckToken hasn't arrived yet" time for small deposits during a spike.
• max_age and margin are unspecified (as are the step-3 window cap / budget / cadence).

[gregorydemay]

🤖 Agreed, worth making explicit. Added to step 5: under decided variant B the mint follows the sweep, so max_age doubles as the worst-case crediting latency for a below-margin deposit (credited only once age forces its sweep, chiefly during gas spikes that keep unswept_value under sweep_gas_cost × margin). Done in 8c33a9d.

[mbjorkqvist]

The anti-spoofing sub-variant reads as undecided while variant B itself is decided: the delegate in Sweeper delegate contract and the demo both implement caller-gating, but this table declares no winner (unlike the other variant tables). The choice is cross-cutting — it determines whether sweeps are permissionless (self-attestation) or minter-only (caller-gating), and whether R3's best-effort sweep-exclusion survives. Recommend either marking a decision here or explicitly flagging it as the one open sub-decision.

[gregorydemay]

I tend to permissionless with self-attestation but want to have a better understanding of the cost involved first (tECDSA, gas, sweeper contract complexity)

[gregorydemay]

🤖 The cost understanding this decision was waiting on is now in the doc: the Cost estimation section (3e7dc19) sizes tECDSA signatures, HTTPS outcalls and gas, and notes the self-attestation sub-variant adds one tECDSA signature (≈ $0.036, one-time per address) to each address’ first sweep. So the sub-decision can now be made on cost grounds. It is tracked as the one open sub-decision (Jira DEFI-2918).

[mbjorkqvist]

The sweep assumes balanceOf(address(this)) equals the amount that will actually transfer, and that depositErc20 moves exactly balance. That holds for standard tokens (USDC, USDT today) but not for fee-on-transfer / rebasing ERC-20s. Probably out of scope (same assumption as today's helper flow), but a one-line "supported tokens are assumed standard, non-fee-on-transfer" would close it.

[gregorydemay]

🤖 Correct, and it is the same standard-token assumption as today’s helper flow. Added a note to the sweeper delegate section: supported tokens are assumed non-fee-on-transfer and non-rebasing, so balanceOf(address(this)) equals the amount depositErc20 transfers. Done in 8c33a9d.