Skip to main content
SVM gas sponsorship is an enterprise-only feature. Contact Dynamic to learn more about upgrading your plan.
With the default SVM gas sponsorship flow, the client sends a transaction and Dynamic sponsors it automatically. That is the fastest path, but the decision to sponsor lives entirely in the SDK, and any transaction the client builds is eligible. This recipe moves that decision to your backend. Your server builds the exact transaction, applies whatever policy you want, asks Dynamic to sponsor it for a specific user, and returns the co-signed transaction to the client. The user then signs it and broadcasts it. Because your server defines the transaction, nothing outside your policy gets sponsored. Common reasons to do this:
  • Require KYC or another verification before sponsoring a user.
  • Apply custom rate limits or budgets per user or per wallet.
  • Enforce custom preconditions for each user or wallet, such as a plan tier, a region, or an existing balance.
  • Sponsor only specific actions, such as a swap through a route you approve, and reject everything else.
Sponsoring a transaction can cost more than the network fee. A transaction can also create accounts that need rent, such as an Associated Token Account (ATA), and an attacker who can submit arbitrary transactions for sponsorship can use that to drain the sponsor, for example by creating many Associated Token Accounts (ATAs). When your server builds the transaction and checks it before requesting sponsorship, you control which instructions the sponsor ever pays for.
The example below uses the JavaScript client SDK to sign and broadcast and the Node server SDK to build and sponsor. It builds a swap from a LI.FI quote, so the transaction comes straight from the API and your server never assembles instructions by hand.

How it works

  1. Your backend builds the transaction, validates it and the user, and asks Dynamic to sponsor it on behalf of that user.
  2. Dynamic returns the transaction with the sponsor as fee payer and the sponsor’s signature already in place.
  3. The client signs the transaction as the user and broadcasts it.

1. Restrict sponsorship to your server

First, make sure SVM gas sponsorship is enabled for your environment. In the Dynamic Console, go to Sponsor Gas → Dynamic and enable Sponsor Network Fees (Solana), with Solana enabled in your embedded wallet chain configuration. Then, in the same card, turn on Restrict sponsorship to server-side requests. With it on, only your server can request sponsorship for Solana transactions. The change reaches end users the next time their app loads. While the setting is on, client SDKs stop requesting sponsorship, so a transaction your app sends without going through your backend is paid for by the user.

2. Build the transaction on your backend

Authenticate the Node SDK with your environment API token. Read the sponsor address with getSponsorAddress and pass it to LI.FI as svmSponsor. LI.FI then builds the transaction with the sponsor as fee payer, so the quote you get back is ready to sponsor as is. This example swaps 0.05 SOL for USDC. Both getSponsorAddress and the userId option of sponsorTransaction used later require @dynamic-labs-wallet/node-svm version 1.1.64 or later.
LI.FI accepts an API key in the x-lifi-api-key header for higher rate limits. You can create one on the LI.FI Partner Portal.

3. Validate on your backend

Before asking for sponsorship, apply your own rules to the user and to the transaction. The checks below are your business policy. Dynamic separately verifies that the wallet signing the transaction belongs to the userId you send, in your environment.
If your policy also inspects the accounts an instruction uses, resolve the transaction’s address lookup tables first, because LI.FI transactions reference most accounts through them.

4. Sponsor on behalf of the user

Authenticate the request, derive the user and wallet on the server, run your checks, and call sponsorTransaction with the user’s userId. Dynamic returns the transaction with the sponsor’s signature. The user’s signature slot stays empty.
The userId tells Dynamic which end user the transaction is for. The wallet that signs the transaction must belong to that user in your environment, and Dynamic rejects the request otherwise. Omit userId only when you sponsor transactions signed by your own server wallets.

5. Sign and broadcast on the client

The client requests the sponsored transaction from your API, signs it with the user’s wallet, and broadcasts it.
The function returns the transaction signature. Confirm it the way you confirm any Solana transaction.
Do not change the transaction after Dynamic sponsors it. The sponsor’s signature covers the whole message, including the blockhash, so any change invalidates it. The blockhash also expires, so the user must sign and broadcast within roughly 60 to 90 seconds of your server returning the transaction.
Last modified on November 5, 2026