Skip to main content
Multichain transactions let users act on one chain using assets they hold on another. Your application selects one source chain and token, then specifies delivery and destination calls. Rhinestone selects a route, moves or swaps assets when needed, and executes the calls as one intent. Users do not need to choose a bridge or manually move funds before interacting with your application. The same flow supports payments, vault deposits, and other contract interactions funded from across their portfolio.

​
Spend from a unified balance

A unified balance groups the account’s available assets across supported chains. Your application uses it to select one source chain/token pair before quoting. The custom signer SDK, embedded wallets, and Caucasus HTTP requests use that selected funding balance and at most one delivery token; they do not search or combine the portfolio for a quote. A delivery always requires a source. Only sufficiently sponsored no-delivery execution can omit one; omission does not search the portfolio. See the REST API tab in End-to-end transaction flow.

​
Separate funding from execution

A multichain intent combines two requirements: the tokens needed on the target chain and the calls that use them. For example, a vault deposit can source USDC from Base, deliver it to Arbitrum, then approve and deposit into the vault. Destination calls execute on one chain, in order, and revert together if a call fails. That atomicity applies to the destination batch—not to every operation across the participating chains. Track the full intent to understand completion, failures, and any refunds. Embedded wallets manage preparation, passkey approval, and submission through one SDK call. Custom signer integrations expose those stages separately so your application can inspect and select a quote before signing.

​
Get started