[Xangle RWA Series] Interoperability Infrastructure

Table of Contents

1. Three Ways RWA Businesses Use Bridges

2. Key Considerations for Bridge Adoption

3. Bridges and Interoperability Infrastructure by Use Case

4. Adoption by RWA Issuers and Financial Institutions

5. Conclusion: Infrastructure for Broader RWA Distribution and Use

 

 

1. Three Ways RWA Businesses Use Bridges

As RWA products circulate across multiple chains, customers may hold assets on a different chain from the service they want to use. RWA businesses use bridges and interoperability infrastructure to move customer assets to the desired chain, expand the distribution of their own tokens, or offer transfers and swaps across chains within their services. The functions required and the roles businesses assume depend on the service they intend to provide.

The first use case is moving assets held by customers and institutions to another chain. The aim is to let users access services on another blockchain with their existing assets or withdraw assets on their preferred chain. Key selection criteria include the asset customers receive at the destination and the party responsible for paying it out.

The second is expanding the distribution of tokens issued by the business itself. To offer the same product to users of multiple blockchains, issuers connect their tokens across chains and support transfers between them. They must preserve total supply and apply the product's controls consistently on each chain, including investor eligibility requirements and transfer restrictions.

The third is integrating transfers and swaps across chains into the business's own service. By connecting bridges and swap services, businesses enable customers to move or exchange assets within a single application. Once customers choose a chain and asset, the service uses the connected infrastructure to find available routes and execute the transfer and swap. This reduces the need for customers to find separate services on each chain to complete their transactions.

The functions and processing methods required of bridges and interoperability infrastructure vary by use case. This report first examines common considerations for bridge adoption, then introduces the main transfer methods and services for the three use cases.

 

2. Key Considerations for Bridge Adoption

When selecting a bridge, businesses need to assess both support for their chosen chains and assets and the requirements of operating an actual service. The main areas to review before adoption are transfer performance and security, liquidity and the characteristics of received tokens, technical support and incident response, and compliance and asset controls. Even when a chain and asset are supported, customers must be able to receive assets when needed, and the business must be able to respond to problems. This chapter organizes the main considerations around transfer performance and security, liquidity and received assets, technical support and incident response, and compliance and asset controls.

2-1. Transfer Performance and Security

Bridge performance should be measured from the moment a customer sends assets until they can receive and use them on another chain. For example, even after a USDC withdrawal has been processed on Base, additional time may pass before the customer can use the USDC on Ethereum. Businesses should therefore distinguish the source chain's processing status from actual receipt at the destination. Completion times and costs vary with the chains, assets and amounts involved, making it important to compare routes under the conditions the business expects to use.

Speed should be assessed alongside the security of asset delivery. The party verifying transfer records may differ from the party paying customers at the destination, so businesses need to understand the safeguards protecting each stage. Security audits and past incident records help inform this assessment. The conditions for pausing transfers or recovering assets when problems arise also require consideration.

2-2. Liquidity and the Type of Asset Received

Support for a transfer route does not by itself establish whether the amount a customer wants to send can be paid immediately at the destination. Available inventory is particularly important for liquidity-based transfers, which pay customers using assets already held on the destination chain. Insufficient assets may delay payouts, raise transfer costs or limit the amount that can be sent in one transaction.

Suppose a customer wants to send $1 million worth of USDC to another chain. If the bridge can immediately pay only $300,000 in USDC at the destination, the customer must wait for more USDC to become available or use another route. A route that handles small transfers smoothly may be unable to process a large institutional order on the same terms. Liquidity therefore needs to match expected order sizes.

The token customers ultimately receive matters alongside the amount that can be paid. USDC issued directly by Circle differs from a token a bridge issues on another chain against USDC it holds in custody. Redeeming the bridge-issued token for the original asset requires the underlying USDC to be returned successfully, so problems at the bridge may make recovery difficult. Exchanges and services may also support only one of the two tokens, limiting where customers can use the asset they receive.

2-3. Technical Support and Incident Response

Once a bridge is integrated into a service, businesses need support to identify the causes of transfer delays and outages. This includes the technical assistance available during integration and the contacts responsible for issues during operation. Support hours and scope should be established in advance, along with adequate notice of changes to support for particular chains or transfer routes.

Businesses should also establish who takes which actions after the cause of a problem has been identified. Responsibilities for recovery should be divided between the bridge provider and the business, with clear ownership of customer communications and refunds. A prolonged outage may require new transfers to be paused or traffic to be redirected to another route. Assigning responsibility for these decisions and their execution helps prevent delays in the response.

2-4. Compliance and RWA Asset Controls

Integrating asset transfers also requires clear responsibilities for customer checks and transaction monitoring. Know Your Customer (KYC) and Anti-Money Laundering (AML) obligations depend on the service provided and the countries in which the business operates. Businesses retain responsibility for their applicable obligations when a bridge handles asset transfers. The bridge provider and the business therefore need to agree in advance who checks customer eligibility and reviews transactions.

Consider a tokenized fund that only eligible investors may hold. A destination wallet's technical ability to receive the token does not establish whether its user meets the product's subscription requirements. Recipient eligibility and the issuer's authorization must be checked before the transfer, and the product's investor restrictions must remain in place when tokens move to another chain.

Product controls must continue to operate on the destination chain after recipient eligibility has been established. Investor restrictions and visibility into holder information must remain intact across chains. Products that require freezing or changes to holder records must support those functions on the destination chain as well.

 

3. Bridges and Interoperability Infrastructure by Use Case

Comparing the main services against these criteria requires understanding which part of the transfer process each service handles. Several services may be involved in a single transaction. For example, a routing service may find a route for a customer's transfer to another chain, while the selected bridge handles the actual movement of assets.

This chapter compares the main methods and services for moving assets, distributing and managing issued tokens, and integrating transfers and swaps into a business's service. Each section first explains the common processing model, then examines the differences between services and the conditions under which they can be used.

3-1. Moving Assets Between Chains

The main methods for moving customer and institutional assets to another chain can be grouped into burn-and-mint, lock-and-mint, liquidity-based transfers, and institutional accounts and custody. A service may offer several methods, so their differences should be understood in terms of the actual route used.

Burn-and-mint burns tokens on the source chain and issues new tokens from the same issuer at the destination. Lock-and-mint also issues tokens at the destination, but holds the original asset on the source chain and delivers a token representing it. Liquidity-based transfers pay customers using assets already held by a pool or relayer at the destination. Institutional accounts and custody allow businesses to deposit assets into a service account and withdraw on their selected chain, with the provider handling the underlying transfer process.

Comparisons should consider the type of token customers receive, the party making the payout, and the scope of operations the business needs to manage directly.

1) Burn-and-Mint

Burn-and-mint transfers burn tokens on the source chain and issue the same quantity on the destination chain. The issuer links the burn and mint operations across chains, allowing customers to receive tokens issued directly by the issuer at the destination. This reduces the need to pre-position assets for payouts, while limiting availability to the assets and chains the issuer supports.

Circle CCTP

Circle CCTP is a burn-and-mint protocol for transferring USDC across chains. For example, when USDC moves from Base to Ethereum, Circle confirms that the tokens have been burned on Base and uses that confirmation to mint USDC on Ethereum. Customers receive USDC issued directly by Circle at the destination.

Standard Transfer waits until the source transaction has reached sufficient finality. Fast Transfer reduces the wait by minting USDC at the destination within Circle's available allowance before full transaction finality. Actual transfer speed depends on the chains involved and the available allowance. Circle provides development tools for businesses to integrate these transfers into their services and connect subsequent actions such as deposits.

2) Lock-and-Mint

Lock-and-mint transfers lock the original token in a custody contract on the source chain and issue a wrapped token representing it at the destination. To return to the original chain, the wrapped token is burned and the original asset is released. This connects assets without requiring the issuer to issue tokens directly at the destination. The received token may nevertheless be treated separately from the original, and custody and return of the original asset depend on the bridge.

Wormhole Wrapped Token Transfers and Portal (WTT)

Wormhole's Wrapped Token Transfers (WTT) is a protocol that uses lock-and-mint to move assets between chains. Users can access it through the Portal interface. When an asset moves from Ethereum to another chain, for example, the original is locked in a custody contract and the recipient receives a wrapped token representing it. Verification participants known as Guardians confirm the transfer records, which support the issuance of wrapped tokens on the destination chain. Transfers can also carry instructions for actions to be performed at the destination.

WTT supports more than 30 chains and multiple token formats, making it easier to connect a wide range of assets without requiring issuers to mint tokens directly on the destination chain. Wrapped tokens received at the destination may be treated as separate tokens from the original asset. When different bridges issue different wrapped versions of the same asset, trading activity and liquidity can fragment across those tokens. Exchanges and DeFi services that support the original asset may support only some wrapped versions, restricting where customers can use the token they receive.

Canonical Bridges

Another option is to use a chain's official deposit and withdrawal route. In Ethereum-based rollups, assets are held on Ethereum and corresponding tokens are issued on Layer 2 (L2). Withdrawals reverse this process by releasing the assets held in custody. This relies on Ethereum's verification and settlement framework, reducing the additional trust required in a separate group of bridge verifiers such as Wormhole's Guardians. It also avoids the need to separately pre-position assets for destination payouts.

The trade-offs are routes focused on a particular chain and withdrawal speeds determined by that chain's verification process. Optimistic rollups initially accept transaction results and allow time for incorrect results to be challenged. Withdrawals from L2 to Ethereum must wait for this period to expire. For example, deposits from Ethereum to Arbitrum One typically take 15 to 30 minutes, while withdrawals back to Ethereum through the canonical route require a wait of about a week. This limits services that need immediate withdrawals. Services seeking shorter waits can instead use assets already available at the destination to pay customers first.

3) Liquidity-Based Transfers

Liquidity-based transfers pay customers using assets already held on the destination chain. These assets belong to a liquidity pool or a relayer (a participant that pays with its own assets first and is reimbursed later). Customers can therefore receive assets before settlement on another chain has finished. This supports faster payouts, but a large transfer or concentrated demand for a particular chain can exhaust the available inventory. The amount available for transfers may then be limited, or transfer costs may rise.

Across

Across is a transfer service in which relayers pay customers on the destination chain first and are reimbursed later. After a customer deposits assets on the source chain, a relayer checks the deposit and the delivery conditions, then pays from its own destination-chain inventory. For example, when a customer sends USDC from Ethereum to Base, the relayer first delivers USDC it holds on Base. The relayer earns a fee for handling the transfer and recovers the amount it advanced once the deposit and payout records are verified. Customers can use the assets they receive while that settlement is completed.

Fast payouts require relayers to hold enough assets on the destination chain. Large orders or concentrated flows to a particular chain may limit transfer capacity or raise fees. Businesses can use Swap API, a development tool, to integrate Across transfers into their services. It connects transfers across chains with asset swaps or deposits at the destination, allowing customers to complete the required actions without moving between multiple services. RWA tokens with investor eligibility restrictions introduce additional conditions. Relayers must also meet the token's holding and transfer requirements, limiting which relayers and routes can participate.

Stargate

Stargate connects assets and transfer methods across multiple chains through one service. Its pool-based routes use assets contributed by liquidity providers to pools on each chain. Across, by comparison, pays customers first from relayers' own inventory. When a customer deposits assets into the source-chain pool, LayerZero relays the deposit information and the destination-chain pool pays the customer.

Stargate also offers OFT routes, which connect issuers' token contracts across chains, and CCTP routes, in which Circle burns and mints USDC. Customers can choose their chains and assets through the same interface, reducing the need to use a separate service for each transfer method. Pool-based routes are limited by the assets available in the destination pool. OFT routes follow the transfer rules of the connected token contracts, while CCTP routes follow Circle's burn verification and minting process. Receipt times and costs therefore depend on the liquidity and issuance procedures of the selected route, even when orders are placed through the same interface.

4) Institutional Accounts and Custody

Under the institutional account and custody model, businesses deposit assets into an issuer's or custodian's account and specify a destination chain for withdrawal. The provider's account balances and deposit and withdrawal functions handle the transfer process. Using a custody service also allows businesses to delegate asset safekeeping and approval procedures. Available assets, chains and withdrawal terms follow each institution's policies.

Circle Mint

Circle Mint is an account and API service that allows institutions to issue and redeem USDC and EURC and make deposits and withdrawals on supported chains. CCTP directly links token burning and minting as a transfer protocol. Mint instead allows institutions to manage deposits, withdrawals and fiat conversions against an account balance. For example, USDC received on Base can be deposited into a Mint account and withdrawn on Ethereum. It can support customer withdrawals and corporate treasury management within the same account framework.

The main users are institutions that handle USDC and EURC at scale, including exchanges, banks and institutional traders. A key advantage is direct access to Circle as the issuer, allowing stablecoin deposits, withdrawals and fiat conversions to be managed through one account. Role-based permissions and dual transaction approvals can align account operations with an institution's internal treasury procedures. Circle's own treasury team has also used these features for USDC settlement between businesses. Access requires institutional account onboarding and eligibility screening, and deposits and withdrawals are limited to the assets and chains Circle supports.

Coinbase Prime

Coinbase Prime combines institutional digital asset custody with trading and deposits and withdrawals across multiple networks. For example, USDC deposited through Ethereum and Base into Prime Trading Balance is aggregated into one USDC balance. The recipient network is selected when making a withdrawal. Circle Mint is the issuer's account service for USDC and EURC, while Prime combines trading and custody for multiple supported assets, including USDC, ETH and BTC.

Managing trading, safekeeping and withdrawals in one place reduces the need to maintain separate wallets and balances on each chain. Businesses should distinguish the point when an account is credited from the point when assets become usable on the destination chain. Support for deposits and withdrawals across networks and balance aggregation differs by wallet type. Withdrawals are subject to supported asset and network lists, approvals and limits, and may be delayed by network conditions.

Anchorage Digital

Anchorage Digital provides institutional custody, trading, settlement and stablecoin issuance services through a business centered on Anchorage Digital Bank, which is chartered by the U.S. Office of the Comptroller of the Currency (OCC). Like Coinbase Prime, it safeguards institutional assets and supports transfers and withdrawals to external addresses. Institutions can specify the asset and recipient address through an interface or API and apply approvals aligned with internal policies. This brings custody, internal approvals, deposits and withdrawals into one operating framework.

Alongside withdrawals of assets in custody, Anchorage supports issuance, redemption and conversion across chains for supported stablecoins. For a chain conversion, tokens are burned on the source chain and the same quantity is minted on the destination chain against the same reserves. Institutions can therefore move supported stablecoins between chains without directly integrating a separate bridge. This burn-and-mint function is limited to the token and chain combinations Anchorage supports for conversion and is separate from ordinary withdrawals of assets in custody.

3-2. Managing the Supply of Issued Tokens

Businesses issuing their own stablecoins or tokenized funds need to manage the quantity issued on each chain alongside transfers between chains. Offering the same product across chains requires deploying tokens on each chain and connecting them for transfers, while accounting for the quantity circulating on each chain to maintain total supply.

For example, moving 20 of 100 tokens from Ethereum to Base using burn-and-mint burns 20 tokens on Ethereum and issues 20 on Base. After the transfer, 80 tokens circulate on Ethereum and 20 on Base, keeping total supply at 100. Issuers must preserve the product's holding and transfer requirements as well as its supply. A product restricted to certain investors must apply the same eligibility requirements after moving to Base. Token frameworks such as LayerZero OFT and Wormhole NTT connect tokens across chains and help implement this supply management structure.

LayerZero OFT

LayerZero OFT is a token standard that enables the same token to circulate across multiple chains while maintaining its total supply. LayerZero messaging connects the token contracts on each chain. Burning or locking tokens on the source chain results in the same quantity being minted or unlocked on the destination chain. New tokens can include OFT functionality from the outset. Existing tokens can retain their original contract and add a separate adapter contract to support transfers across chains.

Issuers choose the Decentralized Verifier Networks (DVNs) that verify transfer messages and the Executor that executes transactions at the destination. They can configure verification combinations aligned with a product's security policies and connect tokens across chains under consistent standards. Each added chain requires management of its token contract, connected counterparts and verification settings. Configuration errors or misuse of administrator permissions can affect transfers. Issuers choosing their own verification setup therefore also assume responsibility for managing settings and administrator permissions on each chain.

Wormhole NTT

Wormhole Native Token Transfers (NTT) is a framework for connecting tokens under the issuer's own control across multiple chains. In the WTT model discussed earlier, the bridge issues wrapped tokens. With NTT, issuers retain administration and upgrade authority over their token contracts. They deploy a transfer smart contract, the NTT Manager, on each chain to handle burning and minting or locking and unlocking. For burn-and-mint transfers, this contract is granted permission to burn or mint the token.

NTT provides per-chain transfer limits and an emergency pause function, allowing issuers to control asset movements. If a large quantity of tokens moves to a chain in a short period, for example, transfers exceeding the limit can be queued, and transfers can be paused if a problem arises. This applies risk management policies to transfers across chains while preserving the issuer's token controls. Limits set too low may also queue legitimate requests and delay processing. Transfer limits constrain abnormal activity but also affect normal order capacity and waiting times.

Chainlink CCT·CCIP

Chainlink CCIP transfers messages and tokens across chains, while Cross-Chain Token (CCT) is the standard for connecting an issuer's token to CCIP. Issuers deploy a Token Pool contract on each chain to handle token minting and burning or custody and release, then connect it to that chain's token. For example, when the source-chain token pool burns tokens, CCIP relays the information and the destination-chain pool mints the same quantity. Existing tokens can also be connected by granting the necessary permissions to the token pool.

Instructions for destination actions can accompany the tokens, supporting services that follow a transfer with a deposit or payment for a product. For example, a service can send a payment token from Ethereum to Base together with a fund subscription request, then have the subscription contract on Base process the request using the arriving tokens. This reduces the separate transactions customers need to submit after moving their assets. Availability is limited to the chains and routes CCIP supports, and the administrator settings of token pools granted the necessary permissions are also important. Delays in the transfer or destination contract execution can delay the subsequent fund subscription.

Axelar ITS

Axelar Interchain Token Service (ITS) supports transfers across chains for new and existing tokens. A Token Manager is a smart contract deployed separately from the token contract to handle the burning and minting or locking and unlocking required for transfers. Issuers select the management method that fits their token's existing structure, and Axelar messaging connects the operations performed by Token Managers on different chains.

ITS allows issuers to choose a transfer method suited to their token's structure and connect transfers with contract execution at the destination. Per-token and per-chain flow limits can restrict excessive asset movements over short periods. Burn-and-mint Token Managers must be granted minting and burning permissions, while locking contracts hold the original assets. Issuers must continuously manage the permissions and assets entrusted to the contracts under the chosen model.

3-3. Integrating Transfers and Swaps Across Chains

Routing services connect multiple bridges and decentralized exchanges (DEXs) to find transfer and swap routes for a customer's chosen chains and assets. Converting USDC on Base into ETH on Ethereum, for example, requires both a transfer between chains and an asset swap. A routing service compares available routes by fees, expected output amounts and processing times, then links the necessary steps so customers can place an order through one interface.

Businesses reduce the work of integrating bridges and DEXs individually, while customers can transfer or swap assets without moving between services. The selected bridge and DEX still perform the underlying operations, so an outage or liquidity shortage along that route affects the order. If the swap fails after the transfer, customers may receive an intermediate asset instead of their desired asset. This section examines LI.FI and Socket, which compare and connect multiple routes, and Swap API, which combines Across transfers with swaps and subsequent actions.

LI.FI

LI.FI compares and connects transfer and swap routes offered by bridges, DEXs and relayers. Businesses can build the order process using its API and SDK or embed a widget to provide a transfer and swap interface. After customers specify source and destination chains and assets, the service presents routes with expected output amounts, fees and processing times. Supported routes can also connect subsequent destination actions such as deposits or staking.

Businesses can prioritize routes offering larger output amounts or shorter processing times and allow or exclude particular bridges and exchanges. This lets them present routes aligned with their service's criteria. Quotes reflect each route's liquidity and fees, while the selected bridge also affects transfer security and completion times. If an order stalls, businesses need to examine the bridge used and the swap stage alongside the status shown by LI.FI to identify the cause of the delay and respond.

Socket

Socket also connects transfer and swap routes from multiple bridges and DEXs through APIs and widgets. Given the input asset, desired asset and quantity, it provides available routes and the transaction data needed for execution. Businesses can select faster routes or routes offering larger output amounts, execute transactions through customer wallets and track order status. A Socket widget can also provide transfer and swap functions within a wallet or trading app without requiring a custom interface.

Connecting multiple routes in one interface reduces the need for customers to find bridges and DEXs themselves. The fastest route may, however, differ from the route offering the largest output amount. Businesses can let customers choose their priority or present routes according to their own service criteria. Price movements or reduced liquidity after a quote may make the original terms unavailable, requiring the quote to be refreshed or another route to be offered before execution.

Across Swap API

Across Swap API is a development tool that connects Across transfers between chains with asset swaps and destination contract execution. For example, a customer using USDC on Base to access a deposit service on Ethereum can combine the transfer, any necessary swap and the destination deposit into one order. Across relayers handle the transfer by paying assets at the destination first. Alongside quotes and fees, the API provides token approval and transaction data needed to execute the order.

Across Swap API builds orders around the transfer routes Across supports. LI.FI and Socket instead compare quotes from multiple bridges. This allows businesses to integrate Across transfers into their services and simplify subsequent deposits or purchases after customers receive their assets. Available amounts and costs depend on relayers' destination-chain inventory and the liquidity of the DEX used for the swap.

 

4. Adoption by RWA Issuers and Financial Institutions

Adoption involves deciding who manages the product and existing business processes alongside the technology connecting chains. Ondo and Securitize use external infrastructure to expand distribution while retaining their own product management frameworks. Swift, ANZ and DTCC test ways to connect the messaging, settlement and custody systems used by financial institutions with blockchains. The following cases focus on the problem each organization is addressing and the role assigned to external infrastructure.

4-1. Ondo: Transfers Across Chains with Token Controls

Ondo uses LayerZero to make its USDY product and tokenized stocks and ETFs available across multiple chains. USDY supports transfers through OFT, with users selecting source and destination chains in Ondo Bridge or the Stargate interface. Ondo Stocks, its tokenized stocks and ETFs, also supports transfers between Ethereum and BNB Chain. Customers can move their holdings to another chain while continuing to hold the same product.

Ondo manages token issuance and supply, while LayerZero delivers transfer messages across chains. Ondo configures different verification networks to check transfer records and includes per-chain transfer limits and emergency pause functions in its contracts. It uses an issuer token standard to operate verification and transfer conditions under its own policies. This allows Ondo to use external messaging infrastructure while applying asset-specific transfer policies and restricting or pausing transfers when problems arise.

4-2. Securitize: Distributing Funds Across Chains

Securitize is a financial infrastructure company supporting asset tokenization and the issuance, administration and trading of digital securities for financial institutions and businesses. Its multichain service combines Wormhole messaging with its own smart contracts to distribute asset managers' funds across chains. Wormhole relays transfer information between chains, while Securitize uses its own systems and contracts to manage each product's investor eligibility and transfer restrictions.

A prominent example is VanEck's tokenized Treasury fund, VBILL, which is available on Avalanche, BNB Chain, Ethereum and Solana. Wormhole provides connectivity between the supported chains. Investors can transfer tokens between those chains while remaining subject to the product's investor eligibility requirements and transfer restrictions. Asset managers can thereby expand fund distribution while maintaining their investor management framework.

4-3. Connecting Existing Financial Systems with Blockchains

Swift, the international financial messaging network, tested whether banks could use their existing messaging systems to transfer assets across multiple blockchains. Chainlink connected the Swift network to blockchains, and CCIP moved simulated tokens between public chains or between public and private chains. The experiments tested how financial institutions could access multiple chains through their existing Swift connection. Such connectivity could reduce the need for institutions to integrate systems separately with each chain.

ANZ, an Australian and New Zealand bank, demonstrated purchases linked to payments across chains on a testnet. Using simulated assets and stablecoins, it configured a customer's purchase request through a banking interface to send payment tokens to another chain through CCIP and link payment with asset delivery. This tested the process from the customer's purchase request through settlement across chains.

DTCC, the U.S. securities clearing and settlement infrastructure provider, demonstrated the use of tokenized securities held in custody in real transactions. In July 2026, securities held by its depository subsidiary DTC were tokenized on blockchains including LFDT Besu and Canton and used for collateral provision and securities and cash settlement. Tokens issued against securities in custody can be delivered to participant wallets and converted back to the existing form of holding when required. The case connects securities to blockchain markets while maintaining the rights established under the existing custody framework.

 

5. Conclusion: Infrastructure for Broader RWA Distribution and Use

As RWA products are issued and distributed across multiple chains, connectivity between chains is becoming a factor in product accessibility and utility. The chains on which a product is available determine which investors and services can access it. Bridges and interoperability infrastructure connect users and assets distributed across chains, helping expand the markets and applications for tokenized assets.

This expansion requires structures that support product management and continuity of existing operations alongside transfers between chains. Ondo and Securitize use external infrastructure while retaining their respective roles in token issuance and investor management. Financial institutions are also testing ways to connect existing messaging, settlement and custody systems with blockchains. These approaches seek to preserve product controls and operational continuity as connectivity expands.

RWA businesses need to understand both their own business model and the characteristics of each connectivity method before deciding how to adopt it. Supporting transfers of customer assets and distributing an issuer's own product across multiple chains involve different functions and responsibilities. Assessing each method's strengths and limitations against operating costs, responsibilities and customer use cases helps businesses choose suitable infrastructure and partners. As RWA products reach more chains and financial services, bridges and interoperability infrastructure are likely to play an increasingly important role in connecting them reliably.