> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rhino.fi/llms.txt
> Use this file to discover all available pages before exploring further.
# Offer every customer a persistent, multi-chain stablecoin deposit address
> Give each customer one deposit address that works like an account number. Accept USDT on Tron and other stablecoins from any supported chain, and settle them as USDC in your treasury on Base.
Neobanks and fintech platforms need to accept stablecoin deposits from customers who hold funds across multiple networks, most commonly USDT on Tron and USDC on Solana or Base. Rhino.fi's Smart Deposit Addresses (SDAs) assign each customer a single, persistent deposit address that functions like an account number. Inbound funds are detected automatically, screened for KYT/AML risks, bridged and converted, then settled deterministically into your treasury wallets in the asset and network of your choice. Your platform credits the customer's balance once Rhino.fi confirms settlement by webhook, with no multi-chain infrastructure for you to build or operate.
## Resources
> [card] [Smart Deposit Addresses (SDK)](https://docs.rhino.fi/sdk/smart-deposits.md)
>
> Create and manage SDAs with the Rhino.fi SDK.
> [card] [Smart Deposit Addresses (API)](https://docs.rhino.fi/api-integration/smart-deposits.md)
>
> The same flow over the REST API.
> [card] [Supported networks and assets](https://docs.rhino.fi/get-started/supported-chains.md)
>
> Chains and tokens you can accept.
## Prerequisites
* An active Rhino.fi account with API credentials provisioned in [Rhino.fi Console](https://docs.rhino.fi/get-started/rhino-console.md).
* The [Rhino.fi SDK](https://docs.rhino.fi/sdk/quickstart.md) integrated into your backend services.
* One or more treasury wallets under your control on your settlement network, pooled or segregated per client to match your fund management model. This recipe settles USDT received on Tron as USDC on Base.
* A publicly accessible HTTPS endpoint to receive Rhino.fi [webhook events](https://docs.rhino.fi/webhook/endpoint-setup.md).
> [!NOTE]
>
> Trial limits for testing are 500 SDAs in total and 50 per hour, with each EVM deposit chain counting as one SDA. See [SDA creation rate limits](https://learn.rhino.fi/articles/9652836744-sda-creation-rate-limits-what-you-need-to-know). Production limits for live clients are aligned with your subscription tier; contact your Rhino.fi account manager to move to production.
## How it works
```mermaid theme={null}
flowchart LR
A[Customer wallet
USDT on Tron] -->|sends to| B[Customer's SDA]
B --> C[Rhino.fi
KYT/AML, bridge, convert]
C -->|USDC on Base| D[Your treasury wallet]
C -->|webhook| E[Your backend
credits the customer]
```
1. **Persistent deposit address:** each customer is assigned one dedicated SDA that does not change.
2. **Customer deposit:** the customer transfers a supported stablecoin from any supported network (in this example, USDT on Tron).
3. **Rhino.fi processing:** Rhino.fi detects the inbound transfer, performs KYT/AML screening, and executes bridging and conversion.
4. **Treasury settlement:** funds settle into your treasury wallets as USDC on Base, or your chosen asset and network.
5. **Ledger reconciliation:** your backend receives a webhook, identifies the customer from the SDA's `addressNote`, and credits their account.
Deposits that fail compliance screening are not settled and should be shown to the customer as under review.
## Interactive demo
See what your customer sees when they deposit.
[Rhino.fi stablecoin deposit demo](https://rhino.coastdemo.com/share/6af4dd29dcbb0a4060635714)
Try it: what your customer sees when they deposit
## Step 1: Provision a dedicated SDA for each customer at onboarding
```ts theme={null}
// Create a persistent deposit address for a new customer
const sda = await sdk.api.depositAddresses.create({
depositChains: ['TRON'], // customers send USDT on Tron; add more chains here
destinationChain: 'BASE', // where you settle
destinationAddress: TREASURY_WALLET, // your treasury on Base
addressNote: customer.id, // your customer ID, returned on webhook events
});
// Save sda.depositAddress on the customer record to display it in-app.
// No separate SDA-to-customer mapping is needed: addressNote identifies the customer.
```
## Step 2: Surface the deposit address in the customer's account details
Present `sda.depositAddress` within the customer's account details, alongside the supported assets and networks returned in `sda.supportedTokens`.
> [!TIP]
>
> For Solana addresses, allow approximately 30 seconds after provisioning before the first deposit is sent. See [best practices when setting up SDAs](https://learn.rhino.fi/articles/6854878451-what-are-best-practices-when-setting-up-sdas).
## Step 3: Process settlement webhooks and credit the customer's account
Subscribe to deposit events and set up a signed endpoint as described in [Subscribe to webhooks](https://docs.rhino.fi/webhook/subscribe.md), [Server setup](https://docs.rhino.fi/webhook/endpoint-setup.md) and the [events list](https://docs.rhino.fi/webhook/events-list.md). Verify every event with the SDK's `verifySignature` helper, as described in [Verify signature](https://docs.rhino.fi/webhook/verify-webhook-signature.md).
```ts theme={null}
app.post('/webhooks/rhino', async (req, res) => {
// Verify the event was signed by Rhino.fi
const isValid = await sdk.api.webhook.verifySignature(req.body, req.headers['x-rhino-signature']);
if (!isValid) return res.sendStatus(401);
const { event } = req.body;
if (event._tag === 'BRIDGE_EXECUTED') {
// addressNote carries the customer ID set when the SDA was created
await ledger.credit(event.addressNote, event.amountOut, 'USDC');
}
res.sendStatus(200);
});
```
## Step 4 (optional): Configure fee sponsorship
Fee sponsorship lets customers receive the full amount transferred; alternatively, fees can be passed through to the customer. Fee sponsorship is configured with the Rhino.fi team: contact your account manager to enable it. For details, see [Advanced Fee & Limit Management](https://docs.rhino.fi/get-started/extensions/advanced-fee-management.md) and the Knowledge Hub article on [Tron, Solana and Bitcoin network costs](https://learn.rhino.fi/articles/7749894324-tron-and-solana-onchain-gas-costs).
## Monitor transaction status
Webhooks are the primary source of truth for settlement events. To review an SDA's deposits on demand, use the [deposit address history endpoint](https://docs.rhino.fi/api-reference/sda/depositaddresses/obtain-a-list-of-previous-activity-for-a-smart-deposit-address.md):
```bash theme={null}
GET https://api.rhino.fi/sda/deposit-addresses/{depositAddress}/TRON/history?from={ms}&to={ms}
```
It returns each deposit to the address with its outcome (accepted, rejected or failed) and, for rejected deposits, the reason, such as `UNSUPPORTED_TOKEN` or `SDA_PAUSED`. Without `from` and `to` it returns the last 7 days; the maximum window is 31 days. The [SDA status call](https://docs.rhino.fi/api-reference/sda/depositaddresses/get-deposit-address-status.md) returns the address's configuration and supported tokens, not its deposit history. See [Track transactions](https://docs.rhino.fi/api-integration/status-history.md) for more.
## Operational considerations
* **Misdirected deposits, handled for you:** customers will occasionally send an unsupported token on a supported chain, or send to their address on a network it wasn't set up for, such as the wrong EVM chain. Rhino.fi absorbs this complexity so your team doesn't have to. Our support team refunds these deposits in full, with no fees deducted and refund gas covered by Rhino.fi, typically within 24 hours on business days once a refund address is confirmed. See [how refunds on SDAs work](https://learn.rhino.fi/articles/4659122464-how-do-refunds-on-sdas-work-and-what-needs-to-be-considered) for thresholds and refund destinations.
* **Paused addresses:** you can pause, unpause or update an SDA through the API, for example when closing a customer account (see [pause, unpause or update deposit addresses](https://docs.rhino.fi/api-reference/sda/depositaddresses/pause-unpause-or-update-deposit-addresses.md)). Deposits sent to a paused SDA are not processed, so avoid pausing addresses that customers may continue to use.
* **Compliance holds:** deposits that fail KYT/AML screening are not settled. Show these to the customer as pending review.
## Reference architecture
One customer → one SDA → your treasury wallets (pooled, or segregated per client) → one webhook that credits your ledger. The same pattern applies to any supported settlement network or asset and to whichever fund management structure you operate.
## In the wild: Wirex
[Wirex](https://wirexapp.com) uses Rhino.fi's infrastructure to accept stablecoin deposits on behalf of its customers. Wirex Business gives every business customer a persistent crypto deposit address next to their bank details, built on Rhino.fi Smart Deposit Addresses: customers send USDT, USDC or EURC from the network they already use, and Wirex receives the funds settled and converted to the customer's base currency.
### How a Wirex Business customer funds their account with stablecoins
**1. Open Account Details → Crypto**
Alongside their bank transfer details, the customer sees a crypto deposit address and the tokens supported on the selected network (EURC, USDC and USDT on Base). The screen tells them deposits typically arrive within a few minutes and are automatically converted to their base currency.
*Rhino.fi: this is the customer's dedicated Smart Deposit Address, created when the account was opened.*
**2. Choose the network they're sending from**
Base, Arbitrum One, BNB Smart Chain, Ethereum, OP Mainnet, Polygon, Kaia, Tron, Solana or Stellar.
*Rhino.fi: one persistent address per chain family, monitored across every supported chain; deposits are bridged and converted before settlement.*
**3. Deposit received and credited**
The customer sends stablecoins to their address, and the funds appear in their Wirex Business account converted to their base currency, usually within a few minutes.
*Rhino.fi: detects the deposit, screens it for KYT/AML, settles it to Wirex's treasury and confirms by webhook, which is when Wirex credits the customer's balance.*
Read the [Wirex case study](https://rhino.fi/case-studies/wirex-stablecoin-deposits).
## Outcome
> "Wirex's mission is to make stablecoin complexity invisible. Users should see a bank account, not a bridge or a chain."
>
> — Daniel Rowlands, General Manager, Wirex
Your customers can fund their accounts from whichever network and stablecoin they already hold, using a single address that never changes. Your organisation gains predictable settlement into the treasury structure you choose, compliance screening on every inbound transaction, and no multi-chain infrastructure to build, operate or maintain. For integration support, contact Rhino.fi support or your account manager.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.