SDA Creation Rate Limits — What You Need to Know

Last updated: May 19, 2026

Default Rate Limits

Limit Type

Default Value

SDA creation rate limit (production)

3,000 SDAs / hour

SDA creation rate limit (testing/initial)

500 SDAs total, 50 / hour

Multi-chain creation

Each chain counts separately

Multi-Chain Rate Limit Consumption

When you create an SDA on multiple chains in a single request (e.g., 7 EVM chains), each chain counts as a separate creation against the hourly rate limit. A single request for 7 chains consumes 7 of the 3,000 hourly allowance.

Note: Using reusePolicy: 'reuse-existing' to extend an existing SDA to additional chains does not count against the rate limit.

Why You Should Not Pre-Generate SDAs in Bulk

Generating a large number of SDAs in a very short window causes a delay in Rhino.fi's monitoring setup for newly created addresses. If too many addresses are generated rapidly, deposit detection on those new addresses may be temporarily slower.

Best practice: Generate SDAs on demand — only when a user is actively requesting a deposit address.

Solana-Specific Constraints

Solana has more restrictive SDA creation limitations compared to EVM chains. If you are planning to launch with Solana support from day one, inform your Rhino.fi account manager in advance so the appropriate limits can be pre-configured.

Requesting Limit Changes

The default rate limit of 3,000/hour is adjustable based on your commercial agreement and expected volume. To request a higher limit, contact your Rhino.fi account manager with:

  • Your expected peak SDA generation volume

  • Whether you plan to include Solana

  • Your planned go-live timeline

Testing Environment

There is no public testnet for SDA flows. The recommended approach for integration testing is to:

  1. Create a dedicated project in the developer portal (https://developers.rhino.fi)

  2. Use small live amounts for end-to-end testing

  3. Switch to production API keys when ready for launch

This gives the most representative integration experience, as testnet conditions (higher latency, custom tokens) are not equivalent to production.