Setting up native gas sponsorship allows your app to pay for all transaction fees, creating a
frictionless experience across all networks.
Getting started
Enable gas sponsorship in the dashboard
Go to the gas sponsorship tab in the Privy
Dashboard, and enable gas sponsorship for
your application.
Configure chains
Select which chains you want to enable sponsorship for. Sponsored requests
may only come from the chains that you have configured. Want support for more networks? Reach out to us! Send transaction requests
Apps must use TEE execution in order to use our native gas sponsorship feature. Learn how to migrate here! Ethereum (React)
Solana (React)
Ethereum (REST API)
Ethereum (Rust SDK)
Solana (REST API)
Solana (Rust SDK)
With the React SDK, use the useSendTransaction hook with sponsor: true:import {useSendTransaction} from '@privy-io/react-auth';
const {sendTransaction} = useSendTransaction();
const {wallets} = useWallets();
sendTransaction(
{
to: '0xE3070d3e4309afA3bC9a6b057685743CF42da77C',
value: 100000
},
{
sponsor: true // Enable gas sponsorship
}
);
Certain flows that require on-chain ECDSA signature verification such as Permit2 are not supported
by EIP-7702 upgraded wallets. We recommend using an approval based flow where possible.
Security recommendations
When implementing gas sponsorship, it’s critical to protect your application from abuse to prevent drainage of your gas sponsorship balance.
Privy natively offers controls to limit total spend and set logic for when to sponsor conditionally.
Rate limiting
To protect against abuse, we recommend:
- Implement strict rate limits: Set per-user and per-wallet transaction limits appropriate for your use case
- Monitor spending patterns: Track unusual activity and implement automatic circuit breakers for suspicious behavior
- Set maximum sponsorship amounts: Configure spending caps to limit potential losses from exploitation
- Send transactions from your backend: Privy aggressively rate limits transactions sent from the client. In order to get more granular control
over limiting, you can relay the transaction from your server.
Example threat models
Solana Rent Refund Vulnerability: On Solana, when Associated Token Accounts (ATAs) are created
during sponsored transactions, the rent deposit refund upon account closure goes to the account
owner, not the fee payer. This creates a potential exploitation vector where users can profit from
the rent refunds while your application pays the creation fees. For example, a user swapping USDC
to SOL could gain ~$0.40 per transaction from the rent refund, effectively draining your gas
sponsorship funds.
Some APIs (like Jupiter) will automatically include the CloseAccount instruction for transfers that will close
the ATA and refund the rent to the user. If your application plans to reuse a limited set of tokens, you should
strip the CloseAccount instruction from transactions to prevent users from profiting off the rent refunds.
Here’s an example of how to remove the CloseAccount instruction from a Solana transaction:
import {Transaction, TransactionInstruction} from '@solana/web3.js';
function stripCloseAccountInstruction(transaction) {
// Filter out any CloseAccount instructions from the transaction
const filteredInstructions = transaction.instructions.filter((instruction) => {
// CloseAccount instruction has discriminator 0x0a (10 in decimal)
const discriminator = instruction.data[0];
return discriminator !== 0x0a;
});
// Create a new transaction with the filtered instructions
const newTransaction = new Transaction();
for (const instruction of filteredInstructions) {
newTransaction.add(instruction);
}
// Copy signers from original transaction
newTransaction.feePayer = transaction.feePayer;
newTransaction.recentBlockhash = transaction.recentBlockhash;
return newTransaction;
}
