Today we are launching the Universal Deposit Address — one address per user that accepts any token on any supported chain and auto-swaps it into the asset your app actually wants. It is live for every Openfort project, and the full overview lives. If you have ever lost a user to a bridge, a wrong network, or a wrong token, this is the primitive that closes that gap.
Why this matters
Cross-chain onboarding is the single biggest tax on web3 conversion right now. Your app is on Base. Your next user holds USDC on Polygon. Between them sits a maze: pick the right bridge, pick the right network, pick the right token, wait for the right confirmation. Every one of those steps is a place to drop out, and none of them has anything to do with what your product actually does.
The same friction shows up server-side. Funding a backend wallet from whichever chain happens to hold the float should not require a hand-rolled bridge integration, a custom indexer, and a Slack channel of operators chasing failed transfers. It should be one address.
That is what the universal deposit address is: a single endpoint for every inbound funding flow, for both embedded wallets and backend wallets, with the bridging and swapping handled for you.
What you get
- One address per user, across every supported chain. Mint it once for a destination wallet. Users fund it from anywhere.
- Users pay in any token; you receive the destination asset. They send USDC on Polygon, ETH on Arbitrum, or SOL on Solana — your wallet ends up with the token and chain your app expects.
- No bridging UX for end users. No network switching, no manual swaps, no second transaction. They send. It lands.
- Funding wallet autoswap, handled for you. The bridge-and-swap step runs inside the funding rail. You do not pick routes, manage slippage, or watch confirmations.
- Works for embedded wallets and backend wallets. Same primitive whether the funder is a human tapping a button or an agent calling an endpoint.
How it works
The universal wallet deposit address is one address per destination, with three things happening behind it:
- Accept any token on any supported chain. Openfort detects the inbound deposit on the source chain the user actually used.
- Auto-swap through the funding rail. Openfort bridges and swaps it into the destination token on the destination chain — no extra steps for the user, no extra plumbing for you.
- Land in the destination asset. The funds arrive in the wallet you control, denominated in the token your app already speaks.
Chains and tokens routable through the rail — Base, Arbitrum, Optimism, Polygon, Ethereum, BNB, Solana, plus natives and stablecoins like USDC and USDT — are surfaced live, so you do not have to hardcode anything.
Built for
- Non-crypto-native onboarding. New users do not need to learn what chain your app runs on. They send what they have, where they have it, and the funds land correctly.
- Cross-chain users entering a single-chain app. Your product is on one chain. Your users are spread across many. One address absorbs all of them, with no bridging interface in your funnel.
- Treasury operations. Top up backend wallets from whichever chain holds the float today, without rewiring every quarter.
- Agent ops. Agents that hold funds can be topped up programmatically through the same primitive — no human in the loop, no per-chain integration.
Get started
The universal deposit address is live for every Openfort project today. The developer guide — including the headless API, React modal, WebView, and webhooks — lives in the Funding docs. If you do not have a project yet, start one at dashboard.
If you have a flow that does not fit the patterns above — programmatic agent funding, multi-destination splits, anything weird — we want to hear about it.