Send a transaction - Rhinestone

A multichain transaction combines target-chain calls with the assets needed to execute them. Rhinestone selects a funding route, moves or swaps assets when required, and executes the calls as one intent.

Describe the outcome

Keep funding and execution separate in the request:

Field	Purpose
Target chain	The chain where every destination call executes.
`tokenRequests`	Tokens and amounts needed on the target chain before calls execute. Use target-chain token addresses.
Calls	Real target-chain calldata. The calls execute in order and revert together if one fails.
Source chains and assets	Constraints on balances that the orchestrator may spend. The fields differ by client.

tokenRequests are not calldata. Add them when a call needs tokens delivered to the target chain. Omit them for a gas-only call that does not need assets delivered. For a token-only swap with no calls, see Make a swap. Do not add dummy calldata or a self-transfer to a request that does not need a call.

Define the calls

This example sends 100 USDC to a recipient on Arbitrum, funded with USDC from the account on Base. Both wallet types use the same calldata:

import { encodeFunctionData, erc20Abi, parseUnits } from "viem";
import { arbitrum, base } from "viem/chains";

const usdcOnBase = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913";
const usdcOnArbitrum = "0xaf88d065e77c8cC2239327C5EDb3A432268e5831";
const recipient = "0xd8da6bf26964af9d7eed9e03e53415d37aa96045";
const amount = parseUnits("100", 6);

const calls = [
  {
    to: usdcOnArbitrum,
    value: 0n,
    data: encodeFunctionData({
      abi: erc20Abi,
      functionName: "transfer",
      args: [recipient, amount],
    }),
  },
] as const;

Send the transaction

Embedded wallet
Custom signer

Use the initialized oneAuth client and authenticated accountAddress from Accounts. sendIntent() prepares the quote, requests passkey approval, and submits the intent:

const result = await oneAuth.sendIntent({
  accountAddress,
  targetChain: arbitrum.id,
  sourceChainId: base.id,
  sourceAssets: [usdcOnBase],
  tokenRequests: [{ token: usdcOnArbitrum, amount }],
  calls: [...calls],
});

if (!result.success) throw new Error(result.error?.message);

Keep result.intentId for status checks.Embedded wallets use numeric chain IDs and tokenRequests[].token. sourceChainId restricts funding to Base; sourceAssets restricts the input token to USDC. To let the wallet choose across available mainnet balances, omit both source constraints and keep tokenRequests. A call with neither tokenRequests nor sourceAssets defaults to target-chain funding unless you set sourceChainId.The default is sponsorshipMode: "required". See Sponsor fees for user-paid quotes and fallback behavior. Set experimental_clear_signing: true for prepared-action review. The end-to-end flow covers closeOn: "completed" and waitForHash: true without repeating them in every request.Embedded wallets have no separate recipient field for this flow. Encode the payment recipient in the transfer call, as shown above.

Batch calls

Pass multiple calls to sendIntent() for an atomic destination batch. They target one chain, execute in order, and all revert when any call fails. Use this for dependent actions such as approve then deposit.sendBatchIntent() instead authorizes several separate intents with one passkey ceremony. Each intent has its own submission and outcome, so they can succeed or fail independently. Do not use it when the operations must be atomic.

Try a non-atomic queue

Add several small mUSD mint transactions on Base Sepolia, then authorize them with one passkey ceremony. This embedded-wallet demo shows separate intents, not an atomic batch or a crosschain funding route. For dependent calls that must revert together, try the atomic relay demo.Review each result independently. A submitted intent is not necessarily completed; retain its ID and check its status before retrying. Clear the queue deliberately after reviewing partial results rather than resubmitting successful entries.

Use account from the Custom signer quickstart:

const prepared = await account.prepareTransaction({
  sourceChains: [base],
  sourceAssets: [usdcOnBase],
  targetChain: arbitrum,
  tokenRequests: [{ address: usdcOnArbitrum, amount }],
  calls: [...calls],
});

const quote = prepared.quotes.best;
console.log(quote.cost.input, quote.cost.output, quote.cost.fees);

const signed = await account.signTransaction(prepared, {
  intentId: quote.intentId,
});
const submitted = await account.submitTransaction(signed);
const result = await account.waitForExecution(submitted);

console.log(result.status, result.operations);

The SDK uses chain objects and tokenRequests[].address. sourceChains restricts funding to Base, while sourceAssets restricts the input token to USDC. Omit sourceAssets to allow other assets on Base, or omit both fields to allow routing across available balances. Review the selected quote’s inputs, outputs, and fees before signing.To spend a fixed input amount instead of requesting a fixed output, pass amounts in sourceAssets and drop the amount from the token request; see Spend an exact input amount.The example is user-paid. Set sponsored: true during preparation if your application pays the fees; see Sponsor fees.

Deliver to another address

To move assets to someone else on the target chain, request the token and set recipient — no calls needed. This delivers 100 USDC on Arbitrum, funded from the account’s USDC on Base:

const prepared = await account.prepareTransaction({
  sourceChains: [base],
  sourceAssets: [usdcOnBase],
  targetChain: arbitrum,
  tokenRequests: [{ address: usdcOnArbitrum, amount }],
  calls: [],
  recipient,
});

The delivered token is the one in tokenRequests, so the same request also swaps when the source asset differs; see Make a swap.recipient changes the destination account for delivered assets and execution. A plain address selects an EOA destination. For another smart account, pass its RhinestoneAccountConfig. It does not rewrite addresses encoded in calldata: in the transfer example above, the payment recipient comes from the call itself and recipient stays unset.

Choose a different route

prepareTransaction returns every candidate route in prepared.quotes.all, ranked with the orchestrator’s recommendation in prepared.quotes.best. Pick another one by passing its intentId to signTransaction:

const cheapestFastEnough =
  prepared.quotes.all
    .filter((candidate) => candidate.estimatedFillTime.seconds <= 60)
    .sort((a, b) => a.cost.fees.total.usd - b.cost.fees.total.usd)[0] ??
  prepared.quotes.best;

const signed = await account.signTransaction(prepared, {
  intentId: cheapestFastEnough.intentId,
});

Each quote carries its own signing payload. Never sign one quote and submit another; always pass the intentId of the quote you reviewed.To constrain the routes before they are quoted, filter the settlement layers. Pass an allow-list to pin the route, or a deny-list to avoid one layer and let the orchestrator choose among the rest:

const prepared = await account.prepareTransaction({
  sourceChains: [base],
  targetChain: arbitrum,
  tokenRequests: [{ address: usdcOnArbitrum, amount }],
  calls: [...calls],
  settlementLayers: { include: ["ACROSS"] },
});

Available layers are ACROSS, ECO, RELAY, OFT, NEAR, RHINO, CCTP, and LZ. An empty allow-list fails closed rather than falling back to an unconstrained route. Omit the field to let the orchestrator pick.

Set the destination gas limit

gasLimit is the gas the destination calls are quoted against. Without it, the quote assumes a conservative default of 1,000,000 units, so a small call is over-quoted:

const prepared = await account.prepareTransaction({
  sourceChains: [base],
  targetChain: arbitrum,
  tokenRequests: [{ address: usdcOnArbitrum, amount }],
  calls: [...calls],
  gasLimit: 200_000n,
});

Estimate the destination calls and add headroom. A limit below actual usage makes the destination execution run out of gas.

Quote against incoming funds

auxiliaryFunds declares balances the orchestrator cannot see yet but that arrive before the intent settles — a pending exchange withdrawal, an unstake, a vault exit. Routing treats them as spendable:

const prepared = await account.prepareTransaction({
  targetChain: arbitrum,
  tokenRequests: [{ address: usdcOnArbitrum, amount }],
  calls: [...calls],
  auxiliaryFunds: {
    [base.id]: { [usdcOnBase]: parseUnits("100", 6) },
  },
});

Do not declare funds the account already holds. The orchestrator reads those balances itself, and declaring them again double-counts them and inflates the quoted input amount.

Run calls on the source chain first

sourceCalls executes on the source side before the claim, covered by the same signature. Use it for an approval, a wrap, or a withdrawal that releases the funds the intent spends. Declare tokens that a call frees up with provides so routing counts them:

const wethOnBase = "0x4200000000000000000000000000000000000006";
const wrapAmount = parseUnits("0.05", 18);

const prepared = await account.prepareTransaction({
  sourceChains: [base],
  targetChain: arbitrum,
  tokenRequests: [{ address: usdcOnArbitrum, amount }],
  calls: [...calls],
  sourceCalls: {
    [base.id]: [
      {
        to: wethOnBase,
        value: wrapAmount,
        data: encodeFunctionData({
          abi: [
            {
              type: "function",
              name: "deposit",
              stateMutability: "payable",
              inputs: [],
              outputs: [],
            },
          ] as const,
          functionName: "deposit",
        }),
        provides: [{ token: wethOnBase, amount: wrapAmount }],
      },
    ],
  },
});

Each key must be a chain in sourceChains. Source calls only run when the route actually moves funds from that chain: a sponsored or no-op fill with no source movement skips the source element, and the calls keyed on that chain are dropped.

Plain EOA requirements

This example uses a smart account, which handles approvals and wrapping as preclaim operations. If you use a plain EOA instead, inspect the selected quote’s tokenRequirements before signing and submitting. For the recommended route, read prepared.quotes.best.tokenRequirements.The SDK does not execute these requirements for an EOA. Complete each approval or native-token wrap on the specified chain and wait for confirmation. Follow Complete token requirements for the onchain operations.

Batch calls

Pass multiple calls to prepareTransaction() for an atomic destination batch. They target one chain, execute in order, and all revert when any call fails. Use this for dependent actions such as approve then deposit.

Continue to the end-to-end transaction flow for the route lifecycle and failure recovery.

​Describe the outcome

​Define the calls

​Send the transaction

​Batch calls

​Try a non-atomic queue

​Deliver to another address

​Choose a different route

​Set the destination gas limit

​Quote against incoming funds

​Run calls on the source chain first

​Plain EOA requirements

​Batch calls

Describe the outcome

Define the calls

Send the transaction

Batch calls

Try a non-atomic queue

Deliver to another address

Choose a different route

Set the destination gas limit

Quote against incoming funds

Run calls on the source chain first

Plain EOA requirements

Batch calls