Sponsor fees - Rhinestone

Choose sponsorship per intent. You can cover all supported fee categories, cover selected categories, or prepare the transaction as user-paid.

Sponsorable fees

Fee	Sponsorable	When it applies
Gas	Yes	Executing and settling the transaction.
Bridge fee	Yes	Moving assets between chains.
Swap fee	Yes	Swapping assets along the route.
Protocol fee	Yes	A Rhinestone protocol fee configured for the intent. It accrues to Rhinestone.
App fee	No	Revenue charged by your application remains user-paid.

Rhinestone applies your configured sponsorship surcharge to surcharge-bearing costs advanced through the relayer flow. Externally settled provider subsidies and sponsored protocol fees do not incur that surcharge. See Pricing for the rates on each plan.

A sponsored request does not silently become user-paid when billing, a policy, or a budget rejects it. Prepare a new unsponsored transaction only after your application has shown the revised quote and the user has accepted it.

Embedded wallet
Custom signer
REST API

Complete the shared sponsorship setup, then start with the embedded-wallet example in Send a transaction. It defines wallet, the source and target tokens, and the real transfer calls used below.For sends, embedded wallets select fee payment with sponsorshipMode. The EVM example and fallback below are separate from managed Solana setup:

Mode	Behavior	Required tokens
`required`	Sponsorship must succeed. This is the default and fails closed.	App access token and extension token.
`disabled`	Request a self-funded quote. The intent needs a `source`.	App access token only; the wallet does not fetch an extension token.

const result = await wallet.sendIntent({
  source: { chain: base.id, token: usdcOnBase },
  destination: {
    chain: arbitrum.id,
    token: usdcOnArbitrum,
    amount,
    calls: [...calls],
  },
  sponsorshipMode: "required",
  closeOn: "completed",
});

Set sponsorshipMode: "disabled" to request a user-paid quote directly. An unsponsored intent must name its funding token in source.To fall back to user-paid execution, send with "required" and, if sponsorship fails before anything was submitted, send again with "disabled". The second send requests a new quote, and the user reviews its fees before signing:

const request = {
  source: { chain: base.id, token: usdcOnBase },
  destination: {
    chain: arbitrum.id,
    token: usdcOnArbitrum,
    amount,
    calls: [...calls],
  },
};

let result = await wallet.sendIntent({
  ...request,
  sponsorshipMode: "required",
});

if (
  !result.success &&
  !result.submitted &&
  result.error?.code.startsWith("SPONSORSHIP_")
) {
  result = await wallet.sendIntent({ ...request, sponsorshipMode: "disabled" });
}

Offer the fallback only when user-paid execution is part of the flow you present to the user.Configure sponsorship on WalletClient even for user-paid intents. The application access token authenticates the app and project for every user intent; only the extension token requests sponsorship. See Set up for the shared client configuration and Policies and security before exposing grants to a client.Embedded wallets do not expose controls for individual fee categories. They support the intent-level modes above; use the custom signer SDK when your product needs to choose gas, bridge, swap, or protocol-fee sponsorship separately.

Managed Solana setup costs

wallet.deploy({ chain }) is app-sponsored, including setup transaction fees and wallet rent. It has no user-paid fallback; a denied grant leaves setup unfinished. Setup installs the root, service recovery, and active passkeys, with separate grants for its steps and retries. See Set up a Solana wallet and Solana issuance policy.Do not treat sponsored setup as funding the user’s transfers or arbitrary instruction-created rent. Fund only after the selected cluster reports ready: true; follow Fund the wallet.

Try sponsored and user-paid transfers

Send 0.1 mUSD on Base Sepolia, switching between required sponsorship and disabled user-paid mode. Sign in and mint mock tokens if needed. The user-paid flow needs enough source assets for the transfer and fees; both modes still authenticate your application with an access token.This demo does not exercise the user-paid fallback or per-category sponsorship. Use Check status for a pending intent rather than sending it again.

Use the backend-held SDK instance from the custom signer tab in Set up. Start with the custom signer example in Send a transaction, which defines the source and target chains, tokens, and real transfer calls.Set sponsored: true when preparing that transaction to request sponsorship for gas, bridge, swap, and protocol fees:

const prepared = await account.prepareTransaction({
  source: { chain: base, token: usdcOnBase },
  destination: {
    chain: arbitrum,
    token: usdcOnArbitrum,
    amount,
    calls: [...calls],
  },
  sponsored: true,
});

Solana transfers accept the same boolean and category object. Apply them to the Solana transfer example; the selected route determines which costs it can sponsor. Deployment and authority changes are always gas-sponsored.Use the object form to select categories. Set gas, bridging, and swaps explicitly; protocolFees is optional and defaults to false:

const prepared = await account.prepareTransaction({
  source: { chain: base, token: usdcOnBase },
  destination: {
    chain: arbitrum,
    token: usdcOnArbitrum,
    amount,
    calls: [...calls],
  },
  sponsored: {
    gas: true,
    bridging: true,
    swaps: false,
    protocolFees: false,
  },
});

For a user-paid quote, omit sponsored or set it to false. The selected source token covers applicable fees. Inspect the selected quote’s fee breakdown before signing; the total cost alone does not identify who pays each category.A delivery always needs source, even with full fee sponsorship. A no-delivery EVM execution can omit it only when effective sponsorship covers all applicable orchestrator costs and there are no user-paid app fees. Sponsorship does not fund arbitrary call value: the user must still hold any native assets spent by destination calls.

Pay for Solana instruction execution

Reuse the reviewed instructions from the native SOL batch. These are alternative preparations, not two submissions:

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

const sponsoredExecution = await account.prepareTransaction({
  destination: { chain: solanaDevnet, instructions },
  sponsored: true,
});

const userPaidExecution = await account.prepareTransaction({
  source: {
    chain: solanaDevnet,
    token: solanaAddress("11111111111111111111111111111111"),
  },
  destination: { chain: solanaDevnet, instructions },
  sponsored: false,
});

The base58 System Program address is the native SOL fee sentinel, not viem’s zero address. You can select a supported SPL fee mint instead. Instruction execution does not accept a source cap or app/protocol fees. Gas-sponsored execution can omit source; it still needs wallet funds for instruction transfers and any rent they create. Wallet rent reserves are not spendable. Deployment and authority changes have their own sponsored path; see Account deployment.

Request fee coverage

For POST /quotes and estimates, use options.sponsorship, not the SDK’s sponsored settings:

const response = await fetch("https://v1.orchestrator.rhinestone.dev/quotes", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "x-api-key": apiKey,
    "x-api-version": "2026-09.caucasus",
  },
  body: JSON.stringify({
    ...caucasusBody,
    options: {
      sponsorship: {
        gas: true,
        bridgeFees: true,
        swapFees: false,
        protocolFees: false,
      },
    },
  }),
});
if (!response.ok) throw new Error(`Quote rejected: ${response.status}`);

Run this on your backend. caucasusBody is the singular request from the HTTP migration. Pin Caucasus on submission and reads too. Fee flags do not bypass authorization, policy, or budget checks; see intent-bound grants.Omit source only for no-delivery intents with effective sponsorship covering applicable orchestrator costs. Sponsorship pays fees, not delivered assets or arbitrary caller-authored call value. A rejected request cannot become user-paid at submission.

Sponsorship is available for same-chain and crosschain intents. Mainnet charges accrue to your organization’s sponsorship account. Testnet sponsorship does not accrue billed usage or consume the mainnet limits described in Policies and security.

​Sponsorable fees

​Managed Solana setup costs

​Try sponsored and user-paid transfers

​Pay for Solana instruction execution

​Request fee coverage

Sponsorable fees

Managed Solana setup costs

Try sponsored and user-paid transfers

Pay for Solana instruction execution

Request fee coverage