test(cketh): adversarial end-to-end coverage of sweeper fee funding

[mbjorkqvist]

Part of DEFI-2933 (sweeper fee funding), last of a seven-PR stack. Targets #11094.

Why

The stack's existing live test proves funding works. This one proves it fails safe. Each test drives a distinct way funding can go wrong through the real pipeline — real ckETH ledger, real EVM RPC canister, local anvil, threshold-ECDSA signature — and asserts the invariant the feature exists to protect: ETH never moves ahead of the ckETH burned to pay for it.

What

Three adversarial scenarios:

• An empty fee account. The burn fails, so no ETH may move. Held for longer than a withdrawal-timer tick, since "the minter must not do this" can only be established as a bounded negative.
• A sweeper already above the low-water mark. No funding is due, so nothing is burned. Also a bounded negative.
• A funding transaction that fails on chain. The destination is given code, so a bare transfer runs out of gas and reverts. The ckETH stays burned and is not reimbursed — it becomes prepaid gas the next funding offsets against, which is exactly what keeps burned ahead of spent. The test waits for finalization and asserts the withdrawal reaches a terminal failed status rather than a reimbursement.

No live fee-spike test: that ceiling is pinned exactly by unit tests, and reproducing it here would mean driving anvil's base fee up over several ticks for little extra signal.

What it found

Waiting for finalization — rather than asserting mid-flight, as the earlier live test did — surfaced a production defect that would trap the withdrawal timer permanently. The fix ships in #11086, where it belongs; this PR is what made it visible.

Harness work this required

Two things had to change before these tests could run at all, both also in #11086:

• A real deposit. Crediting the minter's address with anvil_setBalance moves ETH the minter's accounting has never seen. The harness now emits a genuine ReceivedEth log for the minter to scrape, so its ETH balance counter is backed the way it is in production.
• A PocketIC server that outlives the suite. PocketIc::new hard-codes a 600-second hard TTL, after which the server exits unconditionally — mid-request, ignoring in-flight work, with the budget shared across the whole test binary. Any suite past ten minutes has its backend shot out from under it, and every client then panics with Connection reset by peer. The harness starts its own server with a TTL above the Bazel timeout.

Note on CI: the new target is tagged long_test, so ordinary CI skips it. It needs a run with CI_ALL_BAZEL_TARGETS before merge.

Stack

Merge in order; each PR targets the one above it.

#	PR	Status
1	#11060 — Read a native ETH balance via the EVM RPC canister	ready for review
2	#11065 — Burn ckETH from the minter's own fee subaccount	ready for review
3	#11072 — Add the SweeperFunding withdrawal-request variant	ready for review
4	#11083 — Burn-first accounting for sweeper fee funding	ready for review
5	#11086 — Sweeper fee-funding task, with an end-to-end test	Copilot re-review pending, CI green incl. long tests
6	#11094 — Sweeper funding observability and the prepaid-gas gate	open
7	Adversarial end-to-end coverage of sweeper fee funding	this PR

[Copilot]

Pull request overview

Adds adversarial end-to-end coverage ensuring sweeper fee funding fails safely.

Changes:

• Tests empty fee accounts, sufficient sweeper balances, and reverted funding transactions.
• Extends the live harness with dashboard, balance, code, status, and finalization helpers.
• Adds a dedicated long-running Bazel target.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
rs/ethereum/cketh/test_utils/src/sweeper_funding.rs	Expands live-test utilities.
rs/ethereum/cketh/minter/tests/sweeper_funding.rs	Uses dashboard-derived sweeper address.
rs/ethereum/cketh/minter/tests/sweeper_funding_hardening.rs	Adds three adversarial scenarios.
rs/ethereum/cketh/minter/BUILD.bazel	Registers the long-running test target.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[mbjorkqvist]

Correct, and well spotted — fixed in 2096a99.

The ordering is as you describe: fund_sweeper_address awaits the ledger burn and records AcceptedSweeperFundingRequest only after that call returns, while await_burn watches the ledger's total supply through an external query. So there is a real window in which the supply has dropped and the dashboard still shows no in-flight funding, and reading the index there would panic on an empty row.

It now polls, with the deadline as a named constant because it has to sit between two bounds rather than merely being long enough: generous for an inter-canister hop, but well under the roughly six minutes before the transaction finalizes and clears that row again. Polling indefinitely would have traded this race for the opposite one.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (1)

rs/ethereum/cketh/minter/tests/sweeper_funding_hardening.rs:83

• The no-burn baseline is captured after upgrade_minter(), which starts the zero-delay funding timer on this live PocketIC instance. The task can therefore complete its ledger burn before these queries run, causing both “unchanged” assertions to compare against an already-debited state. Capture the supply and fee-account balance before re-arming the timer so the test cannot miss the behavior it is intended to reject.

    let supply_before = setup.cketh_total_supply();
    let fee_account_before = setup.cketh_balance_of(setup.fee_account());

[mbjorkqvist]

Replying to the suppressed comment about this baseline being captured after upgrade_minter() (no comment node to thread onto, hence a fresh one here).

Right, and a fair catch — fixed in 532989e.

Worth being precise about the failure mode, because it is not a flake in the current code: with a correct minter the sweeper is above the low-water mark, no funding is due, and nothing is burned, so the ordering never bites. It matters for a broken minter — if the post-upgrade check wrongly funded, its burn could land before those two queries returned, and then both "unchanged" assertions would compare against an already-debited state. The test would go green at precisely the moment it was supposed to fail.

The baselines are now read before upgrade_minter(), which is the one point where nothing can yet have happened: the fee account is funded, the sweeper is arranged, and the next scheduled check is a whole interval away. The revert test below already did it in that order — I fixed it there when addressing the in-flight race and did not carry the reasoning back up.

I left the first test as it is: its fee account is empty, so no burn can succeed at all, and its log assertion proves the task ran and declined at the burn rather than never running.