B2B stablecoin settlement has outgrown the single-wallet model. A treasury team that wires USDC to one address cannot reconcile thousands of inbound customer payments, scope permissions per agent, or rotate keys without breaking accounting. Programmable addresses, sometimes called smart addresses, solve this by separating the onchain receipt from the underlying treasury account. One customer or invoice gets a deterministic destination. The funds settle wherever policy dictates.
​

This article maps the five address patterns now in production: virtual accounts (Circle, Bridge), per-invoice addresses (BitPay, OpenNode), counterfactual smart contract wallets (Safe, ERC-4337), session keys via EIP-7702, and HD-derived deterministic addresses. It compares the providers shipping each pattern, where each fits in a B2B settlement stack, and the tradeoffs treasury and developer teams hit at scale.
​

A programmable stablecoin address is an onchain destination that executes logic before, during, or after a transfer. Instead of a static externally-owned account (EOA), it is either a smart contract wallet, a virtual address mapped to a sweep rule, or a deterministic derivation tied to a customer or invoice. The address routes, restricts, or transforms USDC, USDT, USDC.e, USDT0, or USDe according to policy.
​

The pattern matters for B2B because reconciliation, compliance, and treasury controls all key off the address. A finance team that issues one address per customer can match incoming USDC to AR without webhooks. A platform that uses session keys can let an AI agent settle invoices up to $50,000 per day without holding the master key.
​

Virtual accounts assign each customer a dedicated onchain address that automatically sweeps inbound stablecoins to a master treasury. Circle Mint Accounts, Bridge.xyz virtual accounts, and BVNK virtual IBANs all expose this primitive. Customer A sends USDC to address 0xA1...; customer B sends to 0xB2...; both balances arrive in your single Circle Mint balance with the source clearly attributed.
​

Circle's Programmable Wallets product spins these up via a developer-controlled or user-controlled MPC architecture, with per-wallet quotas and webhook events. Bridge.xyz pairs the virtual address with a USD ACH or wire equivalent, useful when a customer prefers fiat rails but the merchant wants USDC. BVNK extends the pattern across EUR SEPA, GBP Faster Payments, and stablecoin rails simultaneously, with reconciliation IDs carried through.
​

The catch: virtual accounts at most providers are custodial. Funds touch the provider's omnibus before reaching your treasury. For regulated entities, this introduces a third-party custody dependency that may conflict with SOC 2 control boundaries or money transmitter licensing scope.
​

Per-invoice addresses generate a fresh destination for each invoice, payment link, or checkout session. The address exists for the duration of the settlement window, then funds sweep to treasury. BitPay has run this model since 2014 for BTC and now USDC; OpenNode does it for Lightning and stablecoins; Coinbase Commerce uses a hybrid where the address is reused but tagged with an invoice ID.
​

The pattern is operationally clean for high-volume merchants. Each invoice has its own destination, so refunds, chargebacks (where applicable), and reconciliation match 1:1 to the address. The downside is address-churn cost. Generating a new address per invoice costs either gas (for smart contract deployment) or HD derivation overhead, and on chains with high state-rent like Solana, ephemeral accounts add cumulative rent.
​

Most providers solve the gas problem with counterfactual deployment, covered next.
​

Counterfactual addresses are smart contract wallet addresses computed before the contract is deployed. The address is derived deterministically from the factory contract, the owner public key, and a salt using CREATE2 or CREATE3 opcodes. Funds can be sent to the address before any onchain deployment exists. The contract deploys on first outbound transaction, or sometimes never.
​

Safe (formerly Gnosis Safe) pioneered this with its proxy factory: every Safe has a predictable address derived from owners + threshold + salt. ERC-4337 account abstraction wallets extend the model. Alchemy's Modular Account, ZeroDev Kernel, Biconomy Nexus, and Coinbase Smart Wallet all expose counterfactual deployment so a B2B platform can compute 10,000 customer addresses in advance without paying 10,000 deployment fees upfront.
​

For settlement, this is significant. A platform can give every customer a personal smart wallet address on Base, Arbitrum, Optimism, Polygon, and 11 more chains, with consistent address derivation. The customer's USDC on Arbitrum and USDC on Base land in addresses they actually control, without per-chain key management.
​

EIP-7702, included in the Pectra upgrade, lets a regular EOA temporarily delegate to smart contract code. The practical result for B2B settlement is session keys: time-bounded, amount-bounded, function-bounded permissions issued from a master account.
​

A CFO can issue a session key valid for 24 hours, capped at $250,000 USDC, restricted to ERC-20 transfer calls to a whitelisted Circle Mint address. An AI procurement agent can hold the session key and settle vendor invoices autonomously within those bounds. Turnkey, Privy, Dynamic, and Para (formerly Capsule) all support session-key issuance over MPC or TEE-backed signers. Coinbase Smart Wallet exposes session keys natively for its Sub Accounts product.
​

Session keys answer the agentic settlement question: how do you give software autonomy over treasury funds without handing it the root key. The answer is scoped, expiring, revocable delegation, with every signature attributable to a specific session.
​

BIP-32 hierarchical deterministic wallets gave Bitcoin a way to derive infinite child addresses from a single seed. The pattern transfers to stablecoins, with caveats. On EVM chains, HD derivation produces EOAs, not smart contract wallets, so you lose programmability at the address level. On Solana, derivation paths produce account keypairs that can be used directly for SPL token accounts.
​

Fireblocks, BitGo, and Anchorage Digital all use HD derivation at scale for institutional custody. Each customer or sub-account gets a derived address, and the master seed (sharded across MPC parties) recovers everything. For a B2B platform issuing addresses to 50,000 merchants, HD derivation is cheaper than smart contract deployment and simpler than per-customer key management.
​

The tradeoff is that pure HD addresses cannot enforce policy onchain. Sweep rules, spending limits, and session permissions all live in the custody provider's offchain logic. If the goal is verifiable, onchain enforcement, smart contract wallets win. If the goal is cheap, scalable address issuance for inbound settlement only, HD is hard to beat.
​

Match the pattern to the failure mode you are trying to avoid. If reconciliation is the bottleneck, virtual accounts or per-invoice addresses give you 1:1 attribution without parsing memo fields. If unauthorized spend is the risk, session keys and smart contract wallets enforce limits onchain. If custody concentration is the audit finding, counterfactual self-custodial wallets keep funds in customer-controlled addresses until you need to sweep.
​

Most production stacks combine patterns. A merchant platform might use Bridge.xyz virtual accounts for inbound fiat-to-USDC, Privy embedded wallets with session keys for end-customer holding, and Safe multisig for the corporate treasury. Eco's orchestration layer handles routing between these address types when settlement needs to cross chains or stablecoins, but the address pattern itself is a provider choice, not a routing choice.
​

Yes, with provider-dependent caveats. Circle Programmable Wallets, Bridge.xyz, BVNK, Fireblocks, and Anchorage all hold regulated charters (BitLicense, EMI, trust charter, or equivalent) and run SOC 2 Type II programs. Turnkey and Privy are SOC 2 Type II certified and used by regulated fintechs. Safe has secured over $100B in cumulative treasury at peak.
​

The open questions sit at the integration boundary: how the address pattern maps to your accounting system, whether your auditor accepts onchain proofs as evidence of receipt, and whether your money transmitter posture changes when funds touch a provider's omnibus. None of these are blockers, but each adds three to six weeks of compliance review before go-live.
​

Provider features and chain coverage are drawn from each company's developer documentation as of May 2026: Circle Programmable Wallets docs, Bridge.xyz API reference, BVNK product pages, Turnkey policy engine documentation, Privy wallet API, Safe protocol docs, Coinbase Smart Wallet Sub Accounts spec, Fireblocks API guide, BitPay merchant docs. EIP-7702 details from the Ethereum Pectra upgrade specification. ERC-4337 references from the canonical ERC repository.
​