Send a transaction - Rhinestone

An EVM multichain transaction combines target-chain calls with the assets needed to execute them. Select one funding chain and token. The clients quote any required swap or bridge and execute the destination 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.
Requested tokens	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 chain and token	The selected balance that funds delivery and user-paid fees.

Calls and calldata in this section are EVM-specific. Solana delivery uses mint and wallet addresses, not calldata; both wallet tabs below include delivery examples. Requested tokens are not calldata. Both clients request one token with destination.token and its amount with destination.amount. 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
REST API

Use the initialized wallet client from Accounts after the user signs in; sends always use the authenticated account. sendIntent() prepares the quote, requests passkey approval, and submits the intent:The Solana example delivers 0.001 USDC from Base Sepolia to a Devnet wallet. Supply an owned, case-sensitive base58 recipient address. If receiving into the user’s managed wallet, set it up and confirm Devnet readiness before funding. EVM-funded delivery does not require experimental_solana; it cannot include Solana instructions. See availability before enabling a route.Keep the whole result, including intentId, status, submitted, shouldResubmit, destination-native transactionHash, and chain-qualified refund, before handling errors. A timeout or success: false is not permission to resend.Embedded wallets use numeric EVM chain IDs and exported Solana cluster IDs. source names exactly one funding token, here USDC on Base; omitting source.chain funds from the destination chain rather than searching other chains. destination.token and the bigint destination.amount request the token the calls need. Delivery and user-paid execution require a source; only fully sponsored no-delivery execution with sponsorshipMode: "required" can omit it. Gas sponsorship does not supply assets consumed by calls or instructions.The default is sponsorshipMode: "required". See Sponsor fees for user-paid quotes and fallback behavior. Passkey-signed intents always show Rhinestone’s prepared-action review. The end-to-end flow covers closeOn: "completed" and waitForHash: true without repeating them in every request.destination.recipient is delivery-only: it requires destination.token and cannot be combined with calls. To pay someone from a call, encode the recipient in the transfer call, as shown above.

Fund a managed Solana wallet

Complete Solana setup and re-read cluster readiness before either funding journey:

From an external wallet: show the ready address and receive a supported token on the same cluster. Confirm receipt before sending a transfer or executing instructions. External transfers cannot be blocked by the SDK’s readiness checks.
From the EVM account: use the EVM → Solana delivery example above, naming the ready Solana address as recipient. Retain the funding intent ID and wait for its confirmed destination outcome before submitting same-cluster instructions separately.

Funding can succeed while the later instruction fails. Show both outcomes and retain both intent IDs; do not repeat delivery to retry execution. The delivered funds remain on Solana unless another operation spends them. On uncertainty, look up status instead of blindly resubmitting.

Send from a managed Solana wallet

After setup and fresh passkey sign-in with experimental_solana, send an SPL token on the same cluster with matching source and destination mints. This is token delivery, not a native SOL transfer or a swap:

import { solanaDevnet } from "@rhinestone/wallet";
import { wallet } from "./wallet";

export async function transferDevnetUsdc(recipient: string) {
  const mint = "4zMMC9srt5Ri5X14GAgXhaHii3GnPAEERYPJgZJDncDU";
  return wallet.sendIntent({
    source: { chain: solanaDevnet, token: mint, maxAmount: 10_000n },
    destination: { chain: solanaDevnet, token: mint, amount: 1_000n, recipient },
    sponsorshipMode: "required",
    closeOn: "completed",
    waitForHash: true,
  });
}

Supply another wallet you control on Devnet, not the sending wallet itself. Omit destination.amount for max output; retain a positive source.maxAmount to cap the observed balance available to the quote, not unconditional total spend. Omitting source.chain is same-chain shorthand, never chain discovery. Do not rely on Solana → EVM delivery yet. See Networks for current limitations.

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. Solana-signed intents must be sent alone: no mixed Solana batches or Solana SmartSessions. Cross-VM calls and cross-cluster Solana execution are unsupported.

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 and the constants and calls above. The preparation examples below are alternatives, not one script:Use account configuration to set up the source signer and any default recipient. Network and route availability depend on your environment.For either preparation, continue with the same lifecycle:

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);

For the EVM example, the SDK uses viem chain objects. source selects USDC on Base; it never searches or combines other portfolio balances. Omitting source.chain selects the destination chain, not another chain. Delivery always needs a source, even when sponsored. Review the selected quote’s inputs, outputs, requirements, and fees before signing.For max-output routing with an observed-balance cap, see Cap the selected source balance. A cap is not a guaranteed exact-input spend.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 destination.recipient — no calls allowed. This delivers 100 USDC on Arbitrum, funded from the account’s USDC on Base:

const prepared = await account.prepareTransaction({
  source: { chain: base, token: usdcOnBase },
  destination: { chain: arbitrum, token: usdcOnArbitrum, amount, recipient },
});

The delivered token is destination.token, so the same request also swaps when the source asset differs; see Make a swap.destination.recipient is delivery-only and cannot coexist with destination calls. Pass an address or a managed EvmAccountConfig from @rhinestone/sdk/evm, not the composite account config. It does not rewrite calldata: the transfer above encodes its own payee and leaves destination.recipient unset.

Deliver from Solana to EVM

Use an existing authorized managed Solana account from Solana setup. This request delivers to an explicit EVM address; it does not execute EVM calls:

import { baseSepolia } from "viem/chains";
import { solanaAddress, solanaDevnet } from "@rhinestone/sdk/solana";

const prepared = await account.prepareTransaction({
  source: {
    chain: solanaDevnet,
    token: solanaAddress("4zMMC9srt5Ri5X14GAgXhaHii3GnPAEERYPJgZJDncDU"),
    maxAmount: 2_000_000n,
  },
  destination: {
    chain: baseSepolia,
    token: "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
    amount: 1_000_000n,
    recipient: "0xd8da6bf26964af9d7eed9e03e53415d37aa96045",
  },
});

A Solana source requires an explicit cluster and one SPL mint or native SOL sentinel. maxAmount caps the total debit in that source token, including applicable user-paid fees; exact-output delivery must fit under it. Omit the output amount for max-output routing within the cap, not guaranteed exact-input spending. Native SOL’s rent-exempt reserve is not spendable. Delivery still requires a source when sponsored. Use the shared quote review, sign, submit, and status flow above.

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.For EVM-origin routes, constrain the routes before they are quoted with settlement-layer filters. Solana-origin requests do not accept settlementLayers or quoters. 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({
  source: { chain: base, token: usdcOnBase },
  destination: { chain: arbitrum, token: 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

The following call-execution example is EVM-only.destination.gasLimit sets the gas limit used to quote the destination calls. The SDK leaves it to the orchestrator when omitted:

const prepared = await account.prepareTransaction({
  source: { chain: base, token: usdcOnBase },
  destination: {
    chain: arbitrum,
    token: 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

This option is EVM-only.source.auxiliaryFunds declares incoming funds in the selected source token, such as a pending withdrawal. They must arrive before settlement; declaring them does not transfer them. Available funds are min(observed balance, maxAmount) + auxiliaryFunds when a cap is set:

const prepared = await account.prepareTransaction({
  source: {
    chain: base,
    token: usdcOnBase,
    auxiliaryFunds: parseUnits("100", 6),
  },
  destination: { chain: arbitrum, token: usdcOnArbitrum, amount, calls: [...calls] },
});

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

This option is EVM-only.source.calls runs on the selected source chain before the claim. Use it for an approval, wrap, or withdrawal. Each provides token must match source.token; here wrapping releases WETH, so WETH is the funding token:

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

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

Review the quote’s source plan to confirm the calls and funding movement. Do not assume unsupported source calls are silently skipped. provides amounts are added after the observed-balance cap, together with auxiliary funds; do not also declare the same output in source.auxiliaryFunds.

Plain EOA requirements

This section is EVM-only.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 requirements array before signing and submitting. For the recommended route, read prepared.quotes.best.requirements.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

For same-chain Solana batches, use the instruction workflow, not 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.

Caucasus HTTP selects one source: { vm, chainId, token } and one destination: { vm, chainId, token, amount }, like the SDK’s singular selection, but with explicit VM identifiers, CAIP-2 chains, and decimal-string amounts instead of viem chain objects and bigint values. Nest EVM calls and gas under destination.execution.calls and .gasLimit; an explicit receiver is destination.recipient: { address }. Preserve call order and encoded payees: the recipient does not rewrite calldata.source.maxAmount caps observed balance, not exact input. EVM-only source.auxiliaryFunds is one base-unit decimal string for the selected pair: available funds are min(observed balance, maxAmount) + auxiliaryFunds. It asserts funds will be available when needed; it does not transfer them. EVM source calls use source.execution.calls with pre-claim timing, not SDK provides; declare newly available selected funds separately as auxiliary funds and review the plan for source movement.See quote request migration and execution mapping.

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

​Describe the outcome

​Define the calls

​Send the transaction

​Fund a managed Solana wallet

​Send from a managed Solana wallet

​Batch calls

​Try a non-atomic queue

​Deliver to another address

​Deliver from Solana to EVM

​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

Fund a managed Solana wallet

Send from a managed Solana wallet

Batch calls

Try a non-atomic queue

Deliver to another address

Deliver from Solana to EVM

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