Non-custodial deposit addresses using Privy and Rhino

Many consumer-facing crypto apps use embedded wallet providers like Privy to create non-custodial wallets on behalf of their users — typically at signup, without requiring the user to manage seed phrases or browser extensions. Once a user has a Privy embedded wallet, they have a persistent on-chain address that is uniquely theirs.

Rhino's bridge SDK can be integrated directly with these embedded wallets to create a seamless, gasless deposit flow. The combination of the two unlocks a product pattern that addresses a specific compliance requirement: ensuring that the address a user deposits from is always the same address they withdraw to.

The problem it solves

The gas problem

Users onboarding via embedded wallets typically arrive from a centralised exchange. Their new wallet has no native gas token, so they cannot initiate any on-chain transaction — including a bridge deposit. Asking users to fund gas separately adds friction that breaks the onboarding flow.

The compliance problem

The requirement to use the same address for deposits and withdrawals is not just a best practice — it is a hard legal requirement for some partners. When a user can deposit from one wallet and withdraw to a different wallet, it opens the possibility of layering through the platform. This shifts the platform's AML risk classification from low to medium or high, and changes the regulatory paperwork in ways that can cause the platform to be flagged as a high-risk exchange by counterparties.

Closing the loop — ensuring funds always enter and exit through the same wallet — removes this risk entirely. It is a binary checkbox from a compliance perspective: same address in and out means the loop is closed and the risk profile is fundamentally different.

Rhino's standard Smart Deposit Addresses do not satisfy this requirement, because they introduce an intermediary address between the user's source wallet and their destination account. The Privy + Rhino pattern avoids this.

What this looks like in practice

The flow works across three layers:

User layer — The user's Privy embedded wallet (a non-custodial EOA, not a smart account) serves as the single address used for both depositing and withdrawing. The user holds the keys and can export them at any time.

Partner layer — The partner's backend monitors the Privy wallet addresses they have created. When a deposit is detected on a supported source chain, the partner prompts the user to sign an EIP-2612 permit — an off-chain signature that authorises Rhino to move the funds. No gas is required from the user at this step.

Rhino bridge layer — Rhino receives the permit, submits the transaction on-chain (paying the source-chain gas itself), bridges the funds cross-chain, and credits the user's destination account. Gas costs are reconciled with the partner as part of normal fee settlement.

Why this is different from Rhino SDAs

Rhino's Smart Deposit Addresses are Rhino-managed addresses that handle deposit detection and bridging automatically. They are the easiest path for most integrations and require minimal backend work from the partner.

The Privy + Rhino pattern takes a different approach: the partner controls the wallet infrastructure through Privy, detects deposits themselves, and uses Rhino purely as the bridge execution layer. The key differences are summarised below.

Chain compatibility: EIP-2612 support is the deciding factor

The gasless flow in this pattern depends entirely on whether the token being transferred supports EIP-2612 permit functionality on the source chain. This is the single most important factor when evaluating which source chains to support.

On chains where EIP-2612 is supported, the full gasless flow is available. The user signs an off-chain permit, no gas pre-funding is required, and the onboarding experience is seamless from end to end. This is the setup this pattern is designed around.

On chains where EIP-2612 is not supported, the permit-based approach is unavailable. Without it, the user must submit an on-chain approval before Rhino can move their funds — and that approval itself requires gas. This recreates the original chicken-and-egg problem, with no clean resolution. Partners would need to either ask users to fund gas manually (which breaks the frictionless onboarding experience), use a different wallet architecture, or restrict the flow to chains that do support EIP-2612.

It is important to note that EIP-2612 support must be verified at the token level, not just the chain level. A chain may be EIP-2612-compatible in principle, but the specific token being used (e.g. USDC, USDT) may not implement the permit extension on that chain. Always confirm token-level support before committing to a source chain.

Who this is for

This pattern is a good fit for apps that:

• Already use Privy to create non-custodial embedded wallets for their users (EOA mode, not smart accounts)

• Have a hard legal or compliance requirement that deposit and withdrawal addresses must match

• Want to offer a fully gasless experience without requiring users to hold native tokens

• Are primarily serving users who deposit from centralised exchanges

It is not necessary if your use case is satisfied by Rhino SDAs — SDAs remain the simpler and lower-maintenance option for most bridge integrations. It is also not suitable if you are using Privy's smart account / server-side wallet mode, as that changes the custody model.

Getting started

If you are already a Rhino partner and want to explore this integration pattern, speak with your integration manager. For the technical implementation details — including the EIP-2612 permit flow and SDK integration — see the companion article: Integrating Rhino bridge with a Privy embedded wallet.

Related articles

• How do SDAs work?

• What are best practices when setting up SDAs?

• How can SDA be used for checkouts?