Faucet Rate Limit Exception — Automated E2E Testing for toodigital

Technical Support
1

I’m building **toodigital**, a native music distribution app (Flutter + Rust) fully on Sui — zkLogin onboarding, Move contract catalog (sale/listing/catalog), decentralized vendor shops, and NFT purchases with fiat settlement. Currently on testnet, planning mainnet migration.

We run a fully automated E2E testing pipeline: cron-based contract redeployment after testnet resets (30-min monitoring → auto-republish 3 Move modules), Platform Wallet SUI drops to NFT buyers (5-min batch), and gas sponsorship for new zkLogin users (balance starts at 0). Faucet rate limits (`429 Too Many Requests`) cause our deploy to fail post-reset (10 retries × 60s still not enough) and drain our Platform Wallet, blocking all automated tests — sometimes for hours.

**Request:** Rate limit exception for 2 server-side wallets (~5-10 req/hour) to achieve near-100% faucet success during automated test runs. One wallet handles SUI drops and gas sponsorship, the other handles contract publishing after resets.

Happy to demo or share automation scripts. Thanks!

2

I’m smart contract and DeAI engineer with 7+ years. I’m very interested in your project. I want to implement this project together while sharing the development experience each other. Let’s contact for the future.

3

Thanks for sharing the detailed context, this makes sense from an E2E reliability perspective.

That said, I would avoid depending on the public Devnet/Testnet faucet as a guaranteed part of your CI pipeline. The faucet is intentionally rate-limited and is shared infrastructure, so even with retry logic, it is not ideal for near-100% automated funding guarantees.

A more robust setup would be:

  1. Run the majority of automated E2E tests on Sui Localnet
    Use a local network with its own faucet for deterministic CI runs, contract redeployments, zkLogin-like onboarding flows, marketplace/listing/purchase logic, and post-reset simulations. This removes public faucet rate limits from the critical path.

  2. Keep public Testnet for smoke/integration tests only
    For Testnet, run a smaller set of scheduled or post-reset smoke tests instead of using it for every automated funding path.

  3. Pre-fund and recycle a platform/gas sponsor wallet
    For zkLogin users with zero balance, the app should sponsor transactions from a funded backend wallet/gas station rather than requesting faucet funds per user. Add a balance threshold check and only request/refill when truly needed.

  4. Add a centralized faucet queue + backoff
    If you still need faucet calls, make sure all services go through one queue, respect rate-limit responses, use exponential backoff with jitter, and stop retrying aggressively after a 429 to avoid extending the lockout window.

If this still requires an exception, I’d suggest sharing the two exact wallet addresses, expected request volume, IP/range, test schedule, and why Localnet cannot cover those cases. But structurally, I would treat faucet access as best-effort rather than CI-critical infrastructure.