What are best practices when setting up SDAs?

Integration Considerations

Smart Deposit Addresses can be integrated with minimal development effort. When using the SDK, SDA creation typically requires only a single function call, allowing you to get started quickly without complex setup.

To ensure a smooth user experience, integrate webhooks to receive real-time updates on deposit detection and processing status. This allows your system to react immediately to incoming transactions and keep users informed throughout the flow.

You should also account for the timing gap between when a quote is shown and when a deposit is actually made. Market conditions or fees may change during this window, so your integration should be designed to handle potential discrepancies gracefully.

By addressing these considerations early, you can ensure a reliable, transparent, and responsive integration experience for your users.

Generate addresses on demand, not in bulk

When Rhino.fi initially generates a Smart Deposit Address, monitoring must be set up on it to check for incoming deposits. This ensures that the necessary swapping and/or bridging activity can take place once funds are received into the address. Rhino.fi therefore pre-generates many SDAs so that this monitoring can be set up in advance of any activity into them. These pre-generated addresses are then allocated to client’s at the point of need. This enables you to create new SDAs on demand; wherever your customer is ready to make a deposit and without the need to generate during the customer onboarding stage or in bulk batches. This on-demand approach keeps your address inventory clean, reduces operational overhead, and ensures that the address is tied to an active, traceable user action.

For that reason, we ask our clients to generate new SDAs only when customers specifically request them in favour of bulk generation for many customers at once.

This ensures your customers can begin transacting using SDAs immediately.

Rate Limits when creating SDAs

The creation of SDAs is initially limited to 500 addresses for clients that just signed up to our console. Once you reached out to our sales, we will increase the limit to 3'000 SDAs per hour. Each chain in a multi-chain SDA creation request counts separately against the rate limit. Creating an SDA on 7 chains simultaneously consumes 7 of your 3,000/hour allowance.

Solana-specific constraints: Solana has specific and more restrictive SDA creation constraints compared to EVM chains. Clients planning Solana at launch should flag this early with their account manager.

Enable all EVM chains right from the start

When constructing your depositChains array for EVM chains, create SDAs on all supported chains immediately, as they will have the same address across all EVM networks

This enables your customers to send stablecoins from as wide array of chains as possible and reduces deposit drop-off.

If you want to add additional EVM chains at a later stage, define the param "reusePolicy": "reuse-existing" and add the additional chains to the depositChains array. All other params need to be identically as with the initial SDA creation call

The list of supported chains can be found here: https://docs.rhino.fi/general/supported-chains

Reuse SDAs per User

Smart Deposit Addresses are designed to be reused across multiple transactions. Instead of generating a new address for every deposit, create one SDA per user and continue using it over time.

SDAs remain active for 10 years by default and can always be re-activated beyond this period. For all practical purposes, SDAs function indefinitely.

Reusing addresses reduces operational overhead, minimizes system load, and ensures that monitoring remains continuously active without interruption.

By following this approach, you maintain a clean and efficient setup while providing a consistent deposit experience for your users.

Use Address Notes for User Mapping

When creating a Smart Deposit Address, use the addressNote parameter to store your internal client or user ID (up to 80 characters). This allows you to associate each SDA directly with a specific user at creation time.

By leveraging this parameter, you can later query and retrieve SDAs based on your client ID without maintaining a separate mapping in your own system.

This simplifies your architecture, reduces the need for additional storage, and ensures you can always resolve the correct deposit address for each user efficiently.

Choose the Right Mode

When creating a Smart Deposit Address, you need to decide whether to use bridge mode or tokenOut mode. This choice determines how incoming funds are handled and must be defined at the time of SDA creation.

In bridge mode, the original token is preserved and transferred to the destination chain as-is. In token-out mode, incoming funds are automatically swapped into a specified token before being delivered.

As this setting cannot be changed after the address is created, it is important to align the selected mode with your product requirements and user expectations upfront.