feat: add EVMTransferStress scenario with deterministic keys and single-use senders

[amir-deris]

Summary

• Adds EVMTransferStress scenario: a high-fee simple ETH transfer (1000 gwei cap, 1 gwei tip, 10^12+1 wei value) for max-throughput single-recipient stress testing
• Adds deterministicEvmStressKeys account config flag to derive a reproducible secp256k1 key pool (indices 1..N) so genesis funding and load keys stay in sync
• Adds singleUseSenders account config flag that gives each pooled account exactly one turn as sender; generation stops cleanly when the pool is exhausted
• Adds fixedReceiver per-scenario config to pin all transactions to a single recipient address instead of picking from the pool
• Adds profiles/evm_transfer_stress.json ready-to-run profile (50k senders, 500 TPS, 250 workers, single recipient)
• Updates scenarioGenerator to handle nil from NextAccount() so pool exhaustion stops generation gracefully (returns ok=false)

Test plan

• go test ./types/... ./generator/... — covers pool exhaustion, fixed-receiver routing, and deterministic key golden values
• Run evm_transfer_stress.json against a local node funded with the deterministic genesis accounts and confirm all 50k txs land in one block sweep
• Verify singleUseSenders + prewarm: true is not used together (comment in config warns; confirm no panic)

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes core transaction/account generation semantics (pool exhaustion, fixed receiver routing) and alters types.NewAccountPool to return errors, which can affect runtime behavior if any call sites missed or configs are invalid.

Overview
Adds a new single-recipient EVM stress mode: per-scenario fixedReceiver routing plus a new EVMTransferStress scenario (high-fee dynamic tx) and a ready-to-run profiles/evm_transfer_stress.json.

Extends account configuration with deterministic stress keys (deterministicEvmStressKeys) and single-use sender pools (singleUseSenders), updates the generator to stop cleanly when pools are exhausted, and changes types.NewAccountPool to return (pool, error) with validation.

Adds startup/config validation to prevent prewarm with single-use pools and to reject malformed fixedReceiver addresses, with accompanying tests.

^{Reviewed by Cursor Bugbot for commit 93fbf10. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 93fbf10. Configure here.}

[cursor]

singleUseSenders without fixedReceiver consumes accounts as receivers

Medium Severity

When singleUseSenders is true but fixedReceiver is empty, Generate() calls NextAccount() twice per transaction—once for the sender and once for the receiver. Both calls advance the single-use pool index, so half the accounts are consumed as receivers and never get their "one turn as sender." With N accounts this produces only N/2 transactions instead of N. There's no validation preventing this misconfiguration even though singleUseSenders only works correctly with fixedReceiver.

Additional Locations (1)

• types/account_pool.go#L46-L56

 

^{Reviewed by Cursor Bugbot for commit 93fbf10. Configure here.}