Skip to main content
Rhinestone Deposits is a cross-chain deposit infrastructure that lets you accept tokens from users on any supported chain and deliver them to a target chain and token automatically. You don’t need to build bridging logic, manage gas across chains, or handle token swaps — the service detects deposits, bridges them via Warp, and notifies your app when funds arrive. It’s built for teams that need reliable deposit rails: neobanks, modern dapps, DeFi protocols, or any app that onboards users from multiple chains. It supports a wide range of EVM chains and Solana — see supported chains and tokens below.

Two ways to integrate

Start with the widget. It ships the whole deposit UI — funding methods, chain and token selection, status screens, withdrawals and refunds — and it uses the same API underneath, so nothing is closed off later. Reach for the API directly when you’re not building in React, or when you want a deposit flow that doesn’t look like a modal.
A React modal that handles funding method, chain and token selection, and deposit execution out of the box. Also covers fiat and exchange funding, withdrawals, refunds, and migrating balances from other apps (e.g. Polymarket).

Widget UI

Get started with the Deposit Widget →

How it works

  1. You register a smart account with a target chain and token
  2. The user transfers tokens to their smart account on any supported source chain
  3. The deposit service detects the transfer, creates a bridging intent via Warp, and routes the funds to the target chain
  4. Your app receives a webhook notification when the deposit completes
The user makes a single transfer. Everything else — bridging, swaps, gas — is handled automatically.

Why Deposits

Deposits are self-custodial by design — funds are held in the user’s smart account at every step, and Rhinestone never takes custody. Stablecoin swaps settle at parity and fees can be fully sponsored. The result is a deposit rail that feels like a native single-chain transfer, without the trust trade-offs of a centralized bridge. Under the hood, Rhinestone aggregates multiple bridging providers, solvers, and quoting services, routing each deposit through the best available path. If one provider is degraded or a route is unavailable, the service falls back automatically — giving you a single integration with the reliability of several.

Key features

  • Automatic bridging — deposits are detected and bridged to the target chain without any user interaction beyond the initial transfer
  • Multi-chain support — accept deposits from any supported chain, EVM or Solana, with more added regularly
  • 1:1 stablecoin swaps — USDC and USDT are swapped at parity
  • Swap routing — route between tokens as part of the deposit
  • Fee sponsorship — cover gas, bridging, and swap fees on a per-chain basis

User experience

From the user’s perspective, depositing is a simple token transfer — send tokens to an address on any supported chain. There’s no bridging UI, no gas token management, and no chain switching. With the widget, the user picks how to fund — connected wallet, QR transfer, card, or an exchange — then confirms, all in one modal. Withdrawals and refunds have their own modals. With the API, you control the UX entirely. The user interacts with your app however you design it, and the deposit service handles everything behind the scenes.

Supported chains and tokens

Rhinestone Deposits supports a wide range of EVM chains plus Solana. Each chain is enabled as a source (the user can send funds to it), a destination (funds can settle on it), or both.
  • Source — users can transfer tokens on this chain and have them bridged to the target.
  • Destination — accounts on this chain can be registered as the target where funds land.
  • TokensAll means any token routable through Warp; otherwise, only the listed tokens are accepted.
This data is also available programmatically via the List supported chains and tokens endpoint.

Which should you use?

Both need a backend, and both see the same deposits — a user who sends funds to the deposit address never touches your UI either way. Most widget integrations also want webhooks, for fulfilment that can’t depend on the modal being open.