What Radom announced
Radom announced v2.0 on September 14. The payments platform now presents an organization with one balance per asset across every network it supports, rather than a separate balance for each network. Radom says that USDC received on Ethereum, Base, Polygon, Arbitrum, BNB Chain, Tron, or Solana can be paid out on another supported network without the customer first moving funds between network-specific balances.
The release also adds conversions with a live quote, cross-asset and cross-network payouts, and optional automatic conversion of incoming payments into a preferred settlement asset. Radom says v2.0 is live and that existing organizations will be migrated over the coming weeks. Future banking integrations described in the announcement are expectations subject to partner and regulatory approval, not capabilities available today.
One balance does not mean one settlement state
A unified balance simplifies the product surface, but the underlying system still crosses networks with different confirmation rules, reorganization behavior, fee markets, token contracts, and failure modes. A customer-facing ledger can aggregate economic exposure by asset; the operational ledger should continue to preserve the originating network, token identifier, transaction hash, observed finality, conversion record, destination rail, and payout transaction.
That distinction matters during an incident. If one network pauses or a token contract is replaced, teams need to identify affected receipts and payouts without freezing every balance carrying the same ticker. Product APIs and internal event schemas should therefore treat the unified balance as a view over rail-specific evidence, not as a replacement for it.
Bind quotes, intent, and retries into one execution record
Radom reports that a live quote is shown before a conversion or cross-asset payout is confirmed. For API-driven flows, the production control is the binding between that quote and the exact intent: source amount, source asset, destination asset and network, recipient, fee treatment, expiry, and minimum acceptable output. The execution record should retain the quote identifier and the values actually settled so finance can explain variance without reconstructing it from market prices later.
Retries are equally important. A timeout can occur after conversion or payout execution but before the caller receives confirmation. Clients need stable idempotency keys, a status lookup, and a reconciliation path that distinguishes an unobserved success from a safe retry. Queue workers should never create a second conversion or payout merely because the first response was lost.
Reconcile the abstraction, the treasury, and the chain
Radom states that its unified treasury backs every organization’s balance one to one and monitors solvency continuously. The announcement does not specify the custody structure, calculation method, attestations, or treatment of pending transactions. Integrators should treat the statement as a provider claim and obtain the evidence appropriate to their risk: safeguarding and legal-ownership terms, supported contract addresses, confirmation policy, reconciliation exports, incident procedures, and withdrawal controls.
A robust close compares at least four views: the customer balance and transaction history, Radom’s account or subledger records, custody or onchain positions by asset and network, and the recipient’s final settlement. Exceptions should carry an owner and reason code, including pending finality, quote expiry, conversion slippage, fee variance, rejected destination, or provider adjustment. Aggregating the customer view reduces manual treasury work; it does not remove rail-level liquidity, concentration, or counterparty risk.
Ineeza’s view
Radom v2.0 is a useful example of infrastructure absorbing cross-network complexity on behalf of product teams. The right integration boundary is not “one balance” alone. It is one balance backed by traceable rail evidence, deterministic payment intent, retry-safe execution, independently reconcilable records, and explicit degraded-mode behavior. Teams that preserve those controls can simplify the user experience without making operational risk invisible.