Biconomy (@biconomy): Introducing Omnichain Virtual Addresses
Estimated coin impact
Scores are not price-change percentages. High impact means a score of +70 or more, or -70 or less.
Introducing Omnichain Virtual Addresses One address. Any chain. No sweep required. Virtual addresses showed the industry what was possible. A single address per customer, per invoice, per merchant — without the sweep overhead, without the reconciliation complexity. It's a genuinely better primitive for stablecoin payments. We built it for every EVM chain. And we took it further. The problem with deposit addresses today 1. Expensive at scale. Issuing a unique deposit address per customer, invoice, or payment means every address needs monitoring, every balance needs sweeping, and every sweep is another transaction, another failure mode, another operational cost. It compounds fast. 2. No virtual address standard across EVM. Most teams aren't building exclusively on one chain, and always do end up interacting with more than one chain over the long term. There has been no way to issue a virtual address for a specific purpose — a payment, an invoice, a one-time action, a customer deposit — that works across every EVM chain under one unified standard. 3. Your users don't all live in the same place.Your customers are spread across Ethereum, Arbitrum, Optimism, Base, Polygon, and beyond. Today you either restrict which chains you accept and lose payments, or you build bespoke routing logic per chain and inherit all the complexity that comes with it. Introducing Omnichain Virtual Addresses Omnichain Virtual Addresses from Biconomy give you one address per customer, per invoice, or per payment flow. The sender sees a single string of characters and sends to it. Funds arrive directly where your business wants to manage them — no sweep transaction in between. The reconciliation question stays simple: did funds arrive at this address? That's it. On a single chain: already better On a single chain, Omnichain Virtual Addresses remove the operational overhead that makes deposit addresses expensive at scale today. There is no sweep step. Funds settle directly to your treasury wallet the moment they arrive. There is no second transaction, no latency, no failure mode between "received" and "available." Your ledger logic doesn't change per customer. Your team doesn't manage thousands of individual deposit wallets. This is the baseline. Most teams will start here, and it's already a meaningful improvement over how deposit flows work today. Cross-chain: it just handles it When your payer is on a different chain than your treasury, Omnichain Virtual Addresses handle it automatically. The address is the same across Ethereum, Arbitrum, Optimism, Base, and Polygon. If funds arrive on any of them, they settle to the chain your treasury lives on — without a bridge UI, without asking the payer to switch networks, without any manual coordination. The payer sends from wherever they are. The merchant receives on the chain they've chosen. The chain the payer used is irrelevant to the outcome. This is the upgrade. You don't need to think about it until your users do — and when they do, it's already handled. What this means in practice For merchants and payment platforms. Issue one address per invoice. Accept payment from any chain your customers use. Receive on the chain your treasury lives on. No sweep logic, no chain-specific deposit endpoints, no support tickets from users who sent from the wrong network. For exchanges and onramps. Issue unique deposit addresses to every user. Regardless of which chain they fund from, attribution and settlement work the same way. Your ledger logic doesn't change per chain. For neobanks and financial applications. The same deposit infrastructure that works for your users on Arbitrum works for your users on Base. You don't maintain separate deposit flows per network. In each case, start on a single chain. The cross-chain capability is there when your users need it. Try the demo We've built a working demo so you can see the flow end to end: an invoice is generated, a payment is sent from one chain, and settlement arrives on another — with no manual bridging step. Try the demo → Work with us Omnichain Virtual Addresses are coming to Biconomy's infrastructure stack. If you're building payment flows, deposit infrastructure, merchant settlement, or onramp/offramp products and want to be among the first to integrate, we'd like to hear from you. Register your interest → How does it work under the hood? We have written a deep dive on how this works technically on our blog.